I think there's a lot of truth in what you're saying and the core problem is that we somehow decided there was one correct way to make a web site, and that was to use React.
Are you creating a complex webapp? Use React. Go nuts! But are you making a mostly static page (blog, marketing site, whatever)? Then don't use React. It adds entirely unnecessary bloat and complication.
The industry has gone back and forth here forever between thick and thin clients, and I view this as an extension. Largely we all use thick clients now (PCs, phones, and things with way too much compute power), and the move to chrome or chromium based browsers made the behavior predictable. The pendulum swinging back is really an acknowledgement that the advantages provided client side rendering, don't always outweigh the networking costs. Data visualization is one of these areas I wonder if the
javascript methods provide a real advantage vs server side rendering.
If I only evaluated our tech stack on a pure “what’s the most efficient way to deliver HTML to the user” I’d not choose React, but I don’t know of any other framework that ticks the other boxes required in a large organization.
- Code sharing - how do you share reusable snippets of code that includes both the SSR logic and the JS that is also required on the frontend. React’s component model is fantastic where a team can develop a component independently
- Skill set - getting 50 React developers to write HTML and JS should be fine if other problems were solved, but often the suggested solution is obscure things like Elm or Elixir
- Even if most of what a company builds is static marketing content, other parts can be more app-like and having developers be able to share code and use the same basic technology is a great productivity booster
Are you creating a complex webapp? Use React. Go nuts! But are you making a mostly static page (blog, marketing site, whatever)? Then don't use React. It adds entirely unnecessary bloat and complication.