Problems I no longer have by using Server-side rendering

[efortis]

As a frontend dev I give him the first point, API versioning, but none of the other. For example:

2. Validation

  > With Spring MVC, you add the validation annotations on the Java code and Thymeleaf can display them when something is wrong.

In the same way the backend can respond with the problems in a 4xx

3. Security

  > [In SSR], it is for instance trivial to not render a ‘delete’ button if the user is not an administrator.

Conditionally rendering a delete button has nothing to do with security.

4. Secured file downloads

  > With a SSR application, you can have a normal <a href=".."/> and the security aspect is handled on the server via the session.

An SPA can have normal links as well. But the main problem here is implying that you can handle that security on the client.

---

SSR for CRUD apps is fine, but this article critiquing SPAs with innacurate examples, and in cases equating them with bloated tech.

[PDFBolt]

Good read! SSR really helps with performance and SEO, but I’ve also found it useful in document automation. We use SSR-like techniques for generating PDFs from HTML on the server side, which helps maintain layout consistency and handle dynamic content better than client-side rendering. Curious have you run into any cases where SSR didn’t fully solve the problem, or do you think it’s the way forward for most apps?