[daguar]

> But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are optimizations to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.

I think this is at the root of it — most web devs today don't see that some plurality or small majority of web app use cases these days just don't require the tradeoffs of SPAs.

But there's a generation of devs who've come up exclusively on JS tooling (Node, Express, React/Redux or Angular) and the crowding effect has therefore made those the default choices, if only because the labor pool is big.

My honest belief is you can more quickly build most functionality needed for most businesses with a plain-old full stack framework like Rails or Django these days.

But the real value of those frameworks doesn't show in the initial speed to build (though it's there!) — it really shows up in how much common functionality (logins, file uploads, etc.) you get for free 6-12 months in, and how low your cost of change stays over time as a comparable SPA app becomes a pain in the butt to add new features to.

[torben-friis]

Speaking as a young(ish) dev, I think the issue with SPAs is that it's that its use has been conflated with separation of concerns and agnostic backend dev.

What I mean by that is that the way we learned is that the old/wrong way (php style templates) mix front end and backend development, and data with formatting. It's better to have data available through rest APIs and then consume it from something. Which is mostly true if you plan on being available in a reasonable way from smartphone apps, etc. but of course that means that your website should also be a client capable of working as similarly as possible to a mobile app - there you go, SPAs.

We need to find a way to keep those benefits without the bulk of current SPAs. But SPAs appeared for a reason, and it would be wrong to ignore why it happened. Being able to have front and backend devs working in parallel is a benefit, being able to server your content to several frontends is a benefit, etc.

(And if you're thinking "these people don't need apps anyway", the reality is that clients demand to have them - even if it's only so they can bother users with push notifications or collect data, they do ask for them).

[theonething]

I agree with this. In my experience, adding React or friends doubles the size and complexity of your application and in a lot of cases, the benefits accrued are not worth it. You essentially end up having two applications to maintain and therefore two places to manage state and make sure they sync correctly.

I commented below that I hope frameworks like Phoenix LiveView will be the future. Seems like the best of both worlds, the simplicity of server side html rendering with SPAlike interactivity. Of course not perfectly. There are tradeoffs no matter what decisions you make.

[Scarbutt]

mostly-CRUD-and-forms-websites.

There's no thin line for this, CRUD-FORM can be really complex or really simple. A thoughtful design choice must be made here between server-side-rendered html with some JS and a SPA.