People will roll a gigantic create-react-app mess for the tiniest of frontend projects. Yes, it's an instant codebase! But that's all code you have to maintain. Stuff like hotwire and htmx can't come fast enough.
People will roll a gigantic create-react-app mess for the tiniest of frontend projects. Yes, it's an instant codebase! But that's all code you have to maintain. Stuff like hotwire and htmx can't come fast enough.
It is still SSR but it's much much more than just going back to 2005. Combining the lessons of the last 15yrs with the as much of the past SSR world as possible. It's not simply throwing it away and regressing to the old ways.
There's a clear trend back to the server to some degree, so on the margin what I'm saying seems to have some basis in many people's experience, where the sweet spot of many apps does not require the added complexity of SPA's or lack of expressiveness of writing so much app code in javascript, building distributed systems, or having to use Firebase style non-relational database services. Moving much of this to the server reduces some of this complexity often with productivity gains.
???
Modern SPAs are typically written in TypeScript which is very expressive and using frameworks to structure them.
One may like or not like the tooling around it, but the language and code is just as robust and clean as any backend code.
That reason alone is why I prefer having the server doing the bulk of the heavy lifting. It reduces variables in the most functional parts of the app and reduces my need to try to herd users into using particular browsers.