5 ms·

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 th

by zadler 3y ago

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.

zadler 2y ago
Htmx: I feel sorry for you React: I don’t think about you at all
selfie 2y ago
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.
- zadler 2y ago
  But you're still doing the work. With React, you render in the client. With HTMX, you split rendering between client and server.
  - kolme 2y ago
    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.
    - SJC_Hacker 2y ago
      > 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.
  - selfie 2y ago
    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.
    - zadler 2y ago
      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.
naasking 2y ago
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.
- storafrid 2y ago
  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.

by zadler 3y ago

zadler 2y ago

Htmx: I feel sorry for you React: I don’t think about you at all

selfie 2y ago

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.

zadler 2y ago
But you're still doing the work. With React, you render in the client. With HTMX, you split rendering between client and server.
- kolme 2y ago
  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.
  - SJC_Hacker 2y ago
    > 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.
- selfie 2y ago
  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.
  - zadler 2y ago
    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.

naasking 2y ago

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.

storafrid 2y ago
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.