>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.
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
This is what we are doing. The server-side web monstrosity is effectively 30+ independent modules that are nested inside a common template. All of these could be worked individually without anyone stepping on each other. Anything that needs to be truly common lives in the wrapper and is rarely changed.
The only part of our business that everyone absolutely has to agree upon is the SQL schema. As long as we are talking to the data in some common language, no one will get too far off track.
>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