Read on Twitter
Web apps are too complex. This is how we can simplify them.
a thread
(17 tweets)
#javascript #webdevelopment
a thread
(17 tweets)#javascript #webdevelopment
I believe that we can do a better job of managing the complexity of our apps.
I don't think many of us are aware of the second-order effects of our decisions.
I don't think many of us are aware of the second-order effects of our decisions.
Let's go back in time and look at how, on a high-level, web apps were architected.
Essentially there were 3 layers. You could have one programmer, tester and a designer in a team and do very well. Business logic can be easily tested on integration level and views via browser testing.
Then AJAX happened. Now you had at least two languages to appeal to possibilities that JavaScript brings. Now you needed someone who is capable of writing JavaScript for your app.
Complexity grows and people expect more dynamic interaction.
Complexity grows and people expect more dynamic interaction.
And now welcome to the Single-page era where tons of complexity has been moved from backend to frontend. Now we have essentially two apps that are tightly coupled which make orchestration problematic, require more code than ever, more tooling and more testing on multiple levels.
Now your components need mocks to be properly tested. This creates a lot of overlap with end to end tests. SEO becomes problematic but can be managed through SSR.
Good patterns have emerged too. UX became better and more creative. We are finally capable of defining client-side logic in a manageable and scalable way.
We all know now that we want to have components and avoid excessive side effects, together with uncontrollable state mutation
We all know now that we want to have components and avoid excessive side effects, together with uncontrollable state mutation
But we had to pay for all of this with complexity.
This complexity requires us to spend more money on people to maintain it, write more code than ever, spend time on automation than ever, spend more time orchestrating rather than putting more effort into products that we are trying to create.
Thankfully there is an opportunity to reduce it. We have to consider either embracing the innovation in the frameworks outside of the JS ecosystem or putting effort into the next generation of JS frameworks that try to unify the developer experience.
Ruby on Rails and Laravel are relevant.
Take a look at Laravel’s components or RoR’s Hotwire!
https://laravel.com/docs/8.x/blade#components
https://hotwire.dev/
Take a look at Laravel’s components or RoR’s Hotwire!
https://laravel.com/docs/8.x/blade#components
https://hotwire.dev/
https://nextjs.org/ by @vercel started a good trend of putting client and server-side code next to each other while solving many common problems with modern web apps.
https://blitzjs.com/ by @flybayer
Built on top of Next.js. Blitz is a great contender to be a Ruby on Rails equivalent in the JS ecosystem.
Using it feels like cheating. You don't think about server or client code. You write mutations, queries and components. Try it.
Built on top of Next.js. Blitz is a great contender to be a Ruby on Rails equivalent in the JS ecosystem.
Using it feels like cheating. You don't think about server or client code. You write mutations, queries and components. Try it.
http://remix.run by @mjackson and @ryanflorence
A completely fresh take on the problem domain while bringing back good forgotten patterns. Explaining it would require another thread. The website explains its concepts very well.
A completely fresh take on the problem domain while bringing back good forgotten patterns. Explaining it would require another thread. The website explains its concepts very well.
@reactjs Server components can be a real game-changer.
https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html
If the frameworks mentioned earlier embrace them then we might end up in the best-case scenario situation where apps will be dynamic only in places that require it without thinking client vs server.
https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html
If the frameworks mentioned earlier embrace them then we might end up in the best-case scenario situation where apps will be dynamic only in places that require it without thinking client vs server.
I've expanded on some of the points a little bit more here: https://michalpietraszko.com/web-apps-are-too-complex-this-is-how-we-can-simplify-them/
Please consider RT or following. Thank you 
You can also read on http://dev.to
https://dev.to/pietmichal/web-apps-are-too-complex-this-is-how-we-can-simplify-them-3ala
... and hashnode!
https://michalpietraszko.hashnode.dev/web-apps-are-too-complex-this-is-how-we-can-simplify-them
You can also read on http://dev.to
https://dev.to/pietmichal/web-apps-are-too-complex-this-is-how-we-can-simplify-them-3ala
... and hashnode!
https://michalpietraszko.hashnode.dev/web-apps-are-too-complex-this-is-how-we-can-simplify-them
