Most websites built as SPAs using React are slower, buggier and more expensive to maintain than if they had been built using mostly server-side rendered pages, like we did in the 90s.
The problem there isn't with React, it's with people who build websites out of a tool that's designed for huge applications.
Most websites shouldn't be built with React. Most single-story buildings shouldn't be built out of steel I beams. That doesn't make them a bad material, it just means you shouldn't use them if a simpler material will do.
> Most single-story buildings shouldn't be built out of steel I beams.
But many are! This is the issue. 10-50x the effort, complexity, hours, expense. Lots and lots of steel, everywhere, because managers heard that Megacorp uses steel and now insist on it.
Hey actually React has nothing to do with Megacorp at all. We adopted React in 2015 on a small team (less than 10 engineers) as did many other small startups at that time. The decision to use React on a small team is the same as it would be on a large team: It dramatically changes frontend development. It makes this career worth while. I did 5 years before React, and now still using React 7 years after with no competitor in sight.
I don't use React because I'm being forced to. We chose React!
Depends on the problem that small team is solving. I've used SPAs on several "small" teams (Angular*, Backbone.js) and they are very effective for solving the kind of problems that are otherwise solved by native applications (winforms and the like). When you have hundreds or thousands of forms / screens in a system then SPAs provide a large reduction in complexity.
For websites: we all like to dump on PHP but it was literally designed to build websites with relatively limited features / large reach - which covers a large swathe of the web.
So SPA: good for ERPs, CRMs etc but bad for webshops, social networks, TODO apps, news sites, Streaming sites, blogs etc.
[Why Angular? React is technically interesting, especially that it's build around the Rx pattern popularized in dotnet, however I have a deep-seated hate for Facebook for their key part in making Brexit happen which trumps any technical merit. Vue wasn't a thing back then]
This 1000x. Every nail looks like a React app. Most frameworks are overkill for most sites/apps. There are definitely ones that need that level of architecture, but that isn't most of the time.
I think it's using the right tool for the job. I thoroughly regret not using Vue or other major JS framework 5-6 years ago when building out our new application. While the server-side is solid the client-side is sort of a mess. A mix of a ton of different things, underscore templates, jquery, etc. It's not an SPA but any modern web application requires a ton of javascript.
We are slowly incorporating Vue into some aspects of the application and the code is just so much cleaner and legible, with better performance in a lot of cases.
SPA loading performance can be improved by splitting React app into multiple SPAs each rendered by its own smaller bundle. Additionally, for many websites, the landing/index page of a SPA can be prerendered at the build time. The result is the best performance ever achievable for many (but not all) websites.
Once SPA has been loaded, it switches to SPA internal pages faster than "like we did in the 90s" because for static pages there is no network round trip and no delay called TTFB. For dynamic pages, making API call and fetching API data (to use it for CSR) likely takes less network bandwidth than fetching HTML generated on the server (as a part of SSR).
Also server rendering uses server CPU and it's never totally free. Especially if server side needs to be scalable.
