| For the record: a PWA can also be served by a single request, it's called hydration. My issue with these kinds of discussions is that they're inevitably using outright false arguments. You can make a well performing website through SSR and a backend templating language, yes. However , In a business setting with lots of developers this usually becomes an abhorrently performing website despite the SSR with the same templating language. You can make a pwa with any of the usual frameworks and it's going to perform wonderfully... The bad performance begins when people start to write terrible code or just keep adding dependencies to cyberstalk their users. But doing the same in the backend puts you into the same position wrt poor performance, so it's just not an argument for or against SPAs. It's totally fine if you decide to write your website with a SSR stack however, and it could very well be the better choice for you, depending on how your skillset is aligned with the technology. |
>However , In a business setting with lots of developers this usually becomes an abhorrently performing website despite the SSR with the same templating language.
I'm not sure this follows. It's harder to do client side rendering because your data is across a slow HTTP barrier. And the client is maintaining state which is harder than stateless.
The problem with SSR is that it's usually tied with single applications which are usually monoliths. But neither of these are requirements for SSR. If you break up your monolith into modules and/or SOA you get the best of both worlds.
But for reasons I don't understand nobody does it this way. It's either monolith + SSR or microservices + client rendering