4 ms·
Is discussing React vs. HTMX like comparing apples to oranges?
by wslh 2y ago
Is discussing React vs. HTMX like comparing apples to oranges?
- recursive 2y agoMaybe, but it may be reasonable to do that sometimes. What fruit should we bring to the picnic?
- wslh 2y agoYes, my comment was not pedantic at all it is great to discuss intersections and symmetric differences. In this specific case. Just I thought that the intersection was small while the symmetric difference is much bigger. The picnic example would be more like mixing them up though ;-)
- Tade0 2y agoOr what goes well with milk.
- toastercat 2y agoYes. 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 agoAlso, 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 agoNo. 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 agoFalse 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 agoGP 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 agothe 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...
- math_dandy 2y agoCorrect. HTMX doesn’t deal with client-side state and updating UI in response to client-side interactions. React, on the other hand, is all about that stuff.