Hacker News Reader

Comment by sublinear | Hacker News Reader

So you drink weak coffee and insist on server-side rendering in 2026?

In 2026, everything is server side. Serve your DOM updates encoded in JSON if you want. Personally, I find serving them in HTML to be less of a hassle.

The server SHOULD do the rendering. It's a SERVER, not a give-me-a-bunch-of-bloated-junk-and-make-me-do-it-myself-er.

I mean a radically different view is that the SERVER should just give you the data and process your requests, without necessarily caring much about what you are - a browser or some other automated system, or a desktop client, where each has vastly different preferences on how the content might get displayed or used.

With that approach, a clear API in the middle and a SPA on the client side makes a bunch of sense (as long as you don't make some chimera of hydration and pre-rendering and server-side components while pretending that it's still a SPA and it "just works" while your server is coupled to the client).

Of course, what you actually need depends on your circumstances and sometimes even preferences. For a bunch of internal or personal stuff, SSR can be really nice and simple!

You're correct that it's a matter of the developer's view, or philosophy. The issue I have with "just give you the data" is that requires the server to encode the raw data somehow, most often JSON, send it down the wire just to have the client un-encode it, store it, and populate HTML elements with it. Meanwhile server-based templating is exceptionally lightweight and fast (especially when compiled) and so converting the raw data directly to HTML on the server via templates tends to be faster and lighter and cleaner, as "state" (not counting ephemeral or stylistic attributes) is maintained in a single place.

You make a good point that different clients may represent the data differently, although again that's easy to handle on the server by using a header or other identifier of the client, and using the appropriate template.

There isnt a definitive right or wrong, both approaches can work but the reason HTMX has found a following is that lots of developers are tired of the complications and difficulties that SPA frameworks seem to introduce, and reverting back to a server-based philosophy is allowing them to be more productive.

> There isnt a definitive right or wrong

As someone who struggled with the downright problematic lifecycle of complex JSF/PrimeFaces apps and now is in a year-long-with-no-end-in-sight migration to a SPA, I will say that the SPA wins out in quite a few development/maintenance/convenience facets, second order system effect or not. As with all migrations, it's slower than you'd expect but the pace of creating new stuff is far more promising (especially if you fight off pixel pushers) and the experience of maintaining SPAs has been good in other projects, especially given that the old JSF/PrimeFaces setup has been around for like a decade (and performed poorly throughout that time, with plenty of footguns that a wide roster of developers kept tripping over).

On the other hand, I will completely admit that SPA can bring additional complexity (especially if you end up with one of those needlessly complex solutions like Next.js or Vuex, when all you need is under 100 components across maybe a number of views on the same order of magnitude), but one also has to consider that some of the traditionally SSR solutions eventually strive to have more reactivity and often create mechanisms for partial updates, except across the board they end up being harder to debug and customize compared to some JS/TS calling a vaguely RESTful API over HTTP(S).

I unironically liked it way more when "web app" meant some PHP returning pages with forms and some Bootstrap on top, even some light jQuery (but we all know how badly the "light" bit held up).

Reply on news.ycombinator.com