Hacker News Reader

Comment by zadler | Hacker News Reader

There does seem to be a little sleight of hand going on, since much of the work that you do in react is rendering, and with HTMX you’re just shifting that to the server.

Is a lighter client and heavier server a good thing? Not always… look at Web3 for example, where many apps can be written against a blockchain and no server at all.

View on HN

A HTMX-y app will typically be a fetch-heavy app. Think TODO list, where each time you add a todo, you want that persisted on the server anyway. Yes you are sending more down the wire. I doubt rendering a partial HTML template is that much more work than formatting JSON but there is more crap to send down the line for sure.

Where the application is doing lots of micro-level stuff, like maybe you are drawing on a canvas and occasionally sending a payload of updates to a server, I think then HTMX would be much slower and clunkier, and that is when you dust off your React.

But you're still doing the work. With React, you render in the client. With HTMX, you split rendering between client and server.

Not really, all the rendering is done in the server.

All HTMX is doing is fetching HTML snippets from the backend and patching them onto the DOM.

> All HTMX is doing is fetching HTML snippets from the backend and patching them onto the DOM.

That's how it should work, although you can get easily get around that and tack on client side rendering.

Render is a different thing in both places. Server Renders is ... formatting a sequence of bytes. Hopefully your templating engine is optimized and it is a low cost operation. Rendering on the client is obviously more involved as it requires actual rendering on the screen using the graphics drivers.

On the other side of the scale, React has overheads like a virtual dom.

It is a complicated question as to what is most performant, who bares that cost, and so on.

I'm not talking about most performant. Neither HTMX nor React has a performance issue.

The issue is overhead and complexity for the developer, and maybe, server costs.

React comes out ahead in server costs, since doing work on the client is very cheap (provided there isn't a performance issue that turns users off, which there isn't).

And in terms of dev time, it depends, but you can't say "look, with HTMX you can avoid code" because you still do need to write code, but now it's in the server.

Htmx: I feel sorry for you

React: I don’t think about you at all

Server rendered content has had 25+ years of development and the approaches and constraints are well understood. Client-side rendering has arguably had less than 10 years of development and the approaches and constraints are still fragmented and poorly understood. The maturity and simplicity of server side rendering shouldn't be underestimated.

I was writing SPAs with jQuery in 2008. By then they were already well-established. We used UI component libraries (mostly custom) on frontend and AJAX for server updates in XML/JSON format. They were hard to build compared to today, but "less than 10 years" of SPA development is simply incorrect.

Reply on news.ycombinator.com