Great article but at the same time the absolute horror of what "modern" frontend development is.
I do understand the need for React when building truly complex applications, like a spreadsheet or word processor app, but I wouldn't be surprised if the majority of projects using React could be solved with a simple template rendered in the backend.
From personal experience I can tell you that using a modern framework can be really worth the added complexity even in simple applications.
For one of my clients projects it started out in what seemed like a simple crud app and so I did the few reactive changes in pure java script. The thing is: requirements changed and now after a while I couldn't get around adding VueJS simply because the reactive changes kept piling up.
Even though the HN sentiment seems to be that all "modern" frameworks are just huge piles of code that you add to your project without understanding how any of this works, my personal opinion is that using something like nextjs with server side rendering is not all that different from using a server side php framework like laravel. You still generate the same html unless you need reactive changes and when you do, you are happy to have chosen that. And to play a bit the devil's advocate: Unless you write your own webserver and template rendering engine you are already using a bunch of code you don't really understand.
It is like questioning about backend using a spring boot in every single service even when it is only for a simple store and fetch json from mongoDB. If you have the know-how, why not? Jumping between Vanilla and React projects can be counterproductive. If things get more complex you are prepared, if not, nobody will mind.
It is not fair to compare SPA or big frontend frameworks with "pure JavaScript" or messy jQuery as some imply.
By putting 20% the effort we put nowadays with these big frameworks into well organized "sprinkles" it is a very viable alternatives. Tools such as Stimulus, unpoly, htmx,etc make this very approachable and maintainable.
To me, SPAs only make sense in two scenarios: 1) You have the requirement for the app to work offline, or on really bad network connections (subway, etc) or 2) You already have a team which only wants to do SPAs and everything else is uncool to them.
> I do understand the need for React when building truly complex applications, like a spreadsheet or word processor app
I am not sure about that. Look at Google. For their truly complex applications like a spreadsheet or word processor (Google docs) they seem to have given up on the DOM altogether and are reimplementing the whole UI in HTML5 canvas.
> I wouldn't be surprised if the majority of projects using React could be solved with a simple template rendered in the backend
Yes, Google and the rest of the folks who are pushing for web components believe they can be.
React is indeed a complex library. For simple apps where components are simple and stateless React is easy. When you have more complex apps where components manage their own state and you have to also update the stateful component from outside, that's when the complexity starts. If the data rendered by the component is large and can't be easily cloned then it gets even more complicated.
> solved with a simple template rendered in the backend
Or a simple template rendered in the frontend, see this demo, where no huge libs are used. Instead a 200-line lib is used to get the equivalent of stateless React components:
https://github.com/wisercoder/eureka
THIS. Server side templates and something like Unpoly is what 90% of projects need.
But here I am at work, doing CRUD forms with rxjs, epics, redux, websockets and a shitton of home made packages for doing validation, lazy translations, mixing microfrontends, etc, etc.
Unpoly looks really nice, something I need to investigate as a comparison against htmx.
Server Side Events (SSE) is better option to websockets IMHO, it is a much simpler protocol so you can implement in any backend of choice with a few lines because it just a HTTP request that is kept open for a longer period of time.
Websockets are bidirectional whereas SSE are unidirectional, but you rarely need the client to push huge data sets to the server.
And if you already have endpoints for fetching HTML fragments for rendering a components, SSE fits well as enhancement into that architecture to get a more live experience.
e.g.
model update in backend -> notify frontend with SSE that model changed -> component that renders model fetches new HTML fragment over HTTP.
This makes the messages over SSE tiny, only need to say that a model changed, not the entire model data. This means that you can turn off SSE and the applications still works, just without live updates thru push, e.g switch to timer based solution instead.
What is also nice by fetching HTML fragments over HTTP is that you use cache headers, if you already have the latest fragment that is just a 304 Not modified.
I think that SSR with dynamic updates of HTML fragments closer respects how the web was intended.
I worked on multiple webapps that used react and, in a way yes, you could do server-side rendering. But the real advantage of react (and most other framework for that matter) is to be able to easily program pages that don't need to fully reload everytime you click on something. Sure, you can still do the same with SSR, but framework make it that much more simple and help a lot with separation of concern.
Also, it make task splitting between frontend and backend engineer that much more easier.
It is definitely possible to do structured dynamic updates without page reloads with SSR because that is what we did 15 years ago before the JSON hype. I know because I worked with it then.
The need to separate the team into frontend & backend engineers is a direct consequence of the over complicated frontend frameworks.
That is another tragedy of this heavy frontend trend. We are undermining the team’s performance and makes it harder to finish deadlines.
Usually what happens is that the frontend & backend engineers get out of sync and starts working on other things until they can sync again.
When this happens too often there is push to put the backend and the frontend in different teams.
After the split the teams start evolving separate cultures and mindset how to solve things and soon enough both teams has their own build and deploy pipes.
Eventually the teams no longer feel that they share a mutual idea of common ownership and the project stagnates.
If we keep things nice & simple we can work as fullstack engineers together as a team.
I do understand the need for React when building truly complex applications, like a spreadsheet or word processor app, but I wouldn't be surprised if the majority of projects using React could be solved with a simple template rendered in the backend.