17 ms·

Yes. Something HTMX evangelists always forget to mention is that HTMX is not a replacement for React -- HTMX + a backend is. This introduces a whole new layer o

Yes. Something HTMX evangelists always forget to mention is that HTMX is not a replacement for React -- HTMX + a backend is. This introduces a whole new layer of complexity; it's a total tradeoff. That is to say there are probably React apps that would be better as HTMX apps.

exceptione 2y ago
Also, does that currently mean that the backend will be Javascript? In the browser we have no choice, but I prefer to prevent that accident from spreading to my servers.
- toastercat 2y ago
  No. Backend can be anything.
thunky 2y ago
> HTMX is not a replacement for React -- HTMX + a backend is Most React apps need a backend too.
- toastercat 2y ago
  False equivalence, and a disingenous one at that. You can build single-page applications with React, you cannot with HTMX.
  - thunky 2y ago
    > You can build single-page applications with React, you cannot with HTMX. Irrelevant to the conversation. GP said: HTMX is not a replacement for React -- HTMX + a backend is So if you think that's not true because React can build SPAs and HTMX cannot, take it up with them (maybe you replied to the wrong comment?).
    - toastercat 2y ago
      GP was from me :) You stated: "Most React apps need a backend too." But in reality this is irrelevant to the conversation, because the top post was asking if comparing HTMX to React is like apples to oranges, which it is, because both tools accomplish different things with completely different feature-sets. A good example of this is the implementation of TodoMVC. [1] React's implementation can live completely in the browser, and even be stateful. [2] An implementation with HTMX requires a server to handle templating/rendering. [3] [1] https://todomvc.com/ https://todomvc.com/ [2] https://github.com/tastejs/todomvc/tree/master/examples/react https://github.com/tastejs/todomvc/tree/master/examples/reac... [3] https://github.com/rajasegar/todomvc-htmx https://github.com/rajasegar/todomvc-htmx
      - recursivedoubts 2y ago
        the vast majority of (non-native) react applications require a back-end, at the very least to deliver them to users htmx-powered applications can be local-only via service workers[1] i think there is a sense in which htmx vs. react is apples to apples, in that in the common case they are used to build web applications that talk in some manner to a back-end system. On the other hand, it is true that react does require additional support code in order to do that communication. Regardless of that latter fact, and the fact that htmx does not require a server, there is a large overlap in practical applications that might be built with either, so it is good to know the strengths and weaknesses of both for comparison. [1] - https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
        toastercat 2y ago
        > the vast majority of (non-native) react applications require a back-end, at the very least to deliver them to users I mean, I guess if you consider me opening an index.html file in my browser requiring a backend in that my desktop operating system is the "backend server", then yes, but that's not what I was referring to. I don't think most folks would consider a CDN to serve static assets to mean "your React app requires a backend" in the traditional sense -- but that's a game of semantics. > htmx-powered applications can be local-only via service workers Do you have any examples of an HTMX app running completely client-side using service workers? Funny enough, the only example I found online ends up using Preact to render templates in the SW, but as a whole, this looks less ergonomic than simply using <insert JS library here> to build a SPA: https://joshi.monster/posts/serverless-htmx/ https://joshi.monster/posts/serverless-htmx/ > there is a large overlap in practical applications that might be built with either, so it is good to know the strengths and weaknesses of both for comparison. I could agree with this. I only care that people understand there are tradeoffs.
- lyu07282 2y ago
  Wouldn't the equivalent be more like server components in react? Or do people literally let their backend render presentational html (including tailwind css or whatever)? Like do htmlx people render html from database resultsets in their backends?
  - poncho_romero 2y ago
    Why is it surprising that a backend returns HTML when it receives an HTTP request? That is the web
    - lyu07282 2y ago
      > Why is it surprising that a backend returns HTML when it receives an HTTP request? That is the web We did that for a long time with Perl/PHP/ASP/JSP I wonder why we stopped doing that? I'll just wait a few decades of your FE with this until you figure it out scnr
      - poncho_romero 2y ago
        I don't understand what you are trying to say here. Serving HTML directly from the backend works wonderfully for almost all websites and web apps. The growing popularity of solutions like HTMX, Hotwire, and Phoenix LiveView is proof that React is not the panacea that was promised. Why prepare JSON on the backend, send it over the wire, and have the frontend transform that data into HTML when the backend could just send HTML in the first place?
        least 2y ago
        > The growing popularity of solutions like HTMX, Hotwire, and Phoenix LiveView is proof that React is not the panacea that was promised. Does it? To me, it seems more proof that software development trends are cyclical. It's also just not all that apparent that things like HTMX are all that popular. React is much more popular than any of them, and then JQuery remains even more popular than React, at least in terms of finding it on the web. Working with XHR sending full HTML responses, it's pretty clear to me that there's some major tradeoffs to this approach. The payload sizes are larger and interactivity is dependent on round trips to the server. so you're increasing server load and are increasing payload sizes to save on client side processing. If your views are data driven, then there's plenty of cases where you may want to have interactivity. filtering or sorting results, for example. So you click a column header, then you're sending another request to the server, asking for a new table with the newly sorted rows, it renders it, sends it back to the client, and then replaced the entirety of the table contents with the new contents. and then htmx does some magic to make it behave closer to native HTML (like enabling css transitions on replaced elements, for example). Storing the state client side, you can perform a lot of these transformations without talking to the server again until you want to actually change data. I'm all for sending plain html from the server. If your views are static and largely unchanging, then sure, by all means, send it over. You don't need a JSON response to render a blog post on the frontend. But as soon as you want any sort of interactivity in your forms or data views, then you probably don't want to make every interaction a round trip to the server and then you're back at having to think about state on the client, at which point objects in JS are just going to facilitate your needs better than html elements.

exceptione 2y ago

Also, does that currently mean that the backend will be Javascript? In the browser we have no choice, but I prefer to prevent that accident from spreading to my servers.

toastercat 2y ago
No. Backend can be anything.

thunky 2y ago

> HTMX is not a replacement for React -- HTMX + a backend is Most React apps need a backend too.

toastercat 2y ago
False equivalence, and a disingenous one at that. You can build single-page applications with React, you cannot with HTMX.
- thunky 2y ago
  > You can build single-page applications with React, you cannot with HTMX. Irrelevant to the conversation. GP said: HTMX is not a replacement for React -- HTMX + a backend is So if you think that's not true because React can build SPAs and HTMX cannot, take it up with them (maybe you replied to the wrong comment?).
  - toastercat 2y ago
    GP was from me :) You stated: "Most React apps need a backend too." But in reality this is irrelevant to the conversation, because the top post was asking if comparing HTMX to React is like apples to oranges, which it is, because both tools accomplish different things with completely different feature-sets. A good example of this is the implementation of TodoMVC. [1] React's implementation can live completely in the browser, and even be stateful. [2] An implementation with HTMX requires a server to handle templating/rendering. [3] [1] https://todomvc.com/ https://todomvc.com/ [2] https://github.com/tastejs/todomvc/tree/master/examples/react https://github.com/tastejs/todomvc/tree/master/examples/reac... [3] https://github.com/rajasegar/todomvc-htmx https://github.com/rajasegar/todomvc-htmx
    - recursivedoubts 2y ago
      the vast majority of (non-native) react applications require a back-end, at the very least to deliver them to users htmx-powered applications can be local-only via service workers[1] i think there is a sense in which htmx vs. react is apples to apples, in that in the common case they are used to build web applications that talk in some manner to a back-end system. On the other hand, it is true that react does require additional support code in order to do that communication. Regardless of that latter fact, and the fact that htmx does not require a server, there is a large overlap in practical applications that might be built with either, so it is good to know the strengths and weaknesses of both for comparison. [1] - https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
      - toastercat 2y ago
        > the vast majority of (non-native) react applications require a back-end, at the very least to deliver them to users I mean, I guess if you consider me opening an index.html file in my browser requiring a backend in that my desktop operating system is the "backend server", then yes, but that's not what I was referring to. I don't think most folks would consider a CDN to serve static assets to mean "your React app requires a backend" in the traditional sense -- but that's a game of semantics. > htmx-powered applications can be local-only via service workers Do you have any examples of an HTMX app running completely client-side using service workers? Funny enough, the only example I found online ends up using Preact to render templates in the SW, but as a whole, this looks less ergonomic than simply using <insert JS library here> to build a SPA: https://joshi.monster/posts/serverless-htmx/ https://joshi.monster/posts/serverless-htmx/ > there is a large overlap in practical applications that might be built with either, so it is good to know the strengths and weaknesses of both for comparison. I could agree with this. I only care that people understand there are tradeoffs.
lyu07282 2y ago
Wouldn't the equivalent be more like server components in react? Or do people literally let their backend render presentational html (including tailwind css or whatever)? Like do htmlx people render html from database resultsets in their backends?
- poncho_romero 2y ago
  Why is it surprising that a backend returns HTML when it receives an HTTP request? That is the web
  - lyu07282 2y ago
    > Why is it surprising that a backend returns HTML when it receives an HTTP request? That is the web We did that for a long time with Perl/PHP/ASP/JSP I wonder why we stopped doing that? I'll just wait a few decades of your FE with this until you figure it out scnr
    - poncho_romero 2y ago
      I don't understand what you are trying to say here. Serving HTML directly from the backend works wonderfully for almost all websites and web apps. The growing popularity of solutions like HTMX, Hotwire, and Phoenix LiveView is proof that React is not the panacea that was promised. Why prepare JSON on the backend, send it over the wire, and have the frontend transform that data into HTML when the backend could just send HTML in the first place?
      - least 2y ago
        > The growing popularity of solutions like HTMX, Hotwire, and Phoenix LiveView is proof that React is not the panacea that was promised. Does it? To me, it seems more proof that software development trends are cyclical. It's also just not all that apparent that things like HTMX are all that popular. React is much more popular than any of them, and then JQuery remains even more popular than React, at least in terms of finding it on the web. Working with XHR sending full HTML responses, it's pretty clear to me that there's some major tradeoffs to this approach. The payload sizes are larger and interactivity is dependent on round trips to the server. so you're increasing server load and are increasing payload sizes to save on client side processing. If your views are data driven, then there's plenty of cases where you may want to have interactivity. filtering or sorting results, for example. So you click a column header, then you're sending another request to the server, asking for a new table with the newly sorted rows, it renders it, sends it back to the client, and then replaced the entirety of the table contents with the new contents. and then htmx does some magic to make it behave closer to native HTML (like enabling css transitions on replaced elements, for example). Storing the state client side, you can perform a lot of these transformations without talking to the server again until you want to actually change data. I'm all for sending plain html from the server. If your views are static and largely unchanging, then sure, by all means, send it over. You don't need a JSON response to render a blog post on the frontend. But as soon as you want any sort of interactivity in your forms or data views, then you probably don't want to make every interaction a round trip to the server and then you're back at having to think about state on the client, at which point objects in JS are just going to facilitate your needs better than html elements.