Comment by zelphirkalt
20 hours ago
I have not run into cross-browser differences in a long time. That is differences, that actually mattered and for which I would have had to build any workaround. I have built several websites recently, using vanilla HTML and CSS and solved everything using server-side rendering.
What problems specifically do you see with server-side rendering?
From a security perspective I greatly prefer a client-server approach: you have an unsafe frontend where you care about ergonomy and aesthetics, and a backend which provides an API which handles the security.
Two different worlds and often two different kinds of developpers
I think we actually don't disagree there, but we have a different understanding of the term "server-side". Anything related to security must happen on the server since safety measures in scripts running client-side can be defeated.
SSR (Server Side Rendering) provides the browser with a page that is created on the server (and possibly enhanced/hydrated on the client).
Having a separate backed and frontend allows for separation of duties: the client is responsible for the user-facing content and the backend deals exclusively with data flows. This allows to have several independent clients, machine to machine connections etc.
Whatever arrives to the server is untrusted, and the API (or other interfaces) only verify raw data (a JSON for instance) and there are excellent (backend) frameworks for that.
Mixing the visual content with the data is possible (Django does that for instance) but from a security perspective less efficient (again - separation of duties). It also requires to possible double the work to have an independent API.
In other words, if you separate the two you do not care about security on the front at all, and the one who builds the back can focus on their expertise.