3 ms·

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.

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.