Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx vs. React: A Complete Comparison – Semaphore

semaphoreci.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: Htmx vs. React: A Complete Comparison – Semaphore

#61

Post by jddj »

lxe wrote: post #46

HTMX relying on a server request to make even minor UI changes (e.g. their first example https://htmx.org/examples/click-to-edit/ ) is wild to me. You might remember when a thing called DHTML revolutionized how JavaScript could be used to build interactive UIs on the web... why go back to pre-2001 era? I get it, SPAs are overkill, but swinging the pendulum all the way back is very strange.

I've been seeing more lately that the stack is being mentioned as htmx+alpinejs.

Not sure how long it'll be until the htmx part gets rationalised out in those instances. Maybe it won't, and people will keep shipping both. Stranger things have happened

Re: Htmx vs. React: A Complete Comparison – Semaphore

#62

Post by lxe »

Karrot_Kream wrote: post #58
lxe wrote: post #46

HTMX relying on a server request to make even minor UI changes (e.g. their first example https://htmx.org/examples/click-to-edit/ ) is wild to me. You might remember when a thing called DHTML revolutionized how JavaScript could be used to build interactive UIs on the web... why go back to pre-2001 era? I get it, SPAs are overkill, but swinging the pendulum all the way back is very strange.

What's a good middle ground for you? I don't intend to be combative at all, I just mostly hack on backend professionally and for fun so when it comes to evaluating frontend technologies I'm useless. Is it preact? Svelte?

You can make a reasonable interactive app with htmx + javascript, but tings will be rather barebones -- you'll need to invent some patterns outside of what HTMX prescribes.

With react you get somewhat prescriptive low-level patterns when it comes to "managing data flow", so I would probably use react to keep things consistent.

Re: Htmx vs. React: A Complete Comparison – Semaphore

#63

Post by SahAssar »

throwanem wrote: post #59
SahAssar wrote: post #57

Earlier quoted context omitted.

That is certainly one interpretation, but even then within most compile-time but not runtime-checked languages you can usually perform runtime checks. For example I've used Zod ( https://zod.dev/ ) quite a bit in typescript to do runtime typechecks at the boundaries.

I don't know much about Rust, but it has the same problem, doesn't it? As I understand it this is something the serde crate (at least) is often used to solve. This is reasonable, given that untyped data received at a system boundary is going to need some kind of type checking no matter what the language or type system; I'm not sure that can even be fairly called a 'problem'. But it also would leave the putative line…

I think we agree, or maybe you misunderstood what I meant?

Re: Htmx vs. React: A Complete Comparison – Semaphore

#65

Post by alexpetros »

SahAssar wrote: post #31

Any time someone shows only HTMX examples without error handling I feel like they have not tried it in an actual use case. To me it feels non-obvious how to handle these non-happy-path things without having to write client-side code which is what I understood HTMX promised to do away with. In the traditional browser model that HTMX espouses to emulate and improve on we have form resubmitting (with a warning that it w…

I think it's a little more accurate to say that htmx lets you handle the common cases with client-side attributes, so that you only have to bust out the client-side scripting in rarer cases.

You're definitely correct that the htmx documentation and tutorials and such don't talk about error-handling as much, and that should change! This is partly a function of how relatively young htmx is, and how long its been since the industry focused on hypermedia-related error handling patterns, so I'm optimistic this won't be the case for too much longer.

In the meantime, what I usually do is write a tiny htmx config snippet that intercepts 4xx or 5xx responses, and inserts them as a modal/popup/alert in the DOM. You can also do the opposite, and hook into an event from before the request, and do something with it if the requests fails for other reasons. Another common pattern is to return an error modal from the server and target the "error" spot in the DOM. There are also extensions for handling different response codes differently.

But again, while it's very do-able and I think reasonably intuitive once you start building larger apps with htmx, it's still an undeveloped aspect of the educational materials :)

Re: Htmx vs. React: A Complete Comparison – Semaphore

#66

Post by KatrinaKitten »

SahAssar wrote: post #31

Any time someone shows only HTMX examples without error handling I feel like they have not tried it in an actual use case. To me it feels non-obvious how to handle these non-happy-path things without having to write client-side code which is what I understood HTMX promised to do away with. In the traditional browser model that HTMX espouses to emulate and improve on we have form resubmitting (with a warning that it w…

HTMX does not promise to "do away with" client-side code. In many cases, you don't need or need significantly less JavaScript in an HTMX codebase than in other alternatives, but the point is not to use no JavaScript, but rather to extend HTML to do what JavaScript shouldn't be needed for. Its error handling story could be better in a number of ways, but it isn't a promise break.

Re: Htmx vs. React: A Complete Comparison – Semaphore

#67

Post by [deleted] »

lxe wrote: post #46

HTMX relying on a server request to make even minor UI changes (e.g. their first example https://htmx.org/examples/click-to-edit/ ) is wild to me. You might remember when a thing called DHTML revolutionized how JavaScript could be used to build interactive UIs on the web... why go back to pre-2001 era? I get it, SPAs are overkill, but swinging the pendulum all the way back is very strange.

[deleted]

Re: Htmx vs. React: A Complete Comparison – Semaphore

#68

Post by KatrinaKitten »

recursivedoubts wrote: post #64

htmx is not 2k, sadly it is 15k: https://bundlephobia.com/package/htmx.org@1.9.10 the authors are confusing it with another package: https://bundlephobia.com/package/htmx@0.0.2

React is also not 6.4kb, it's 316kb for base React + 4.5mb for React DOM + who knows how much for any other library you decide to use.

Re: Htmx vs. React: A Complete Comparison – Semaphore

#69

Post by recursivedoubts »

lxe wrote: post #46

HTMX relying on a server request to make even minor UI changes (e.g. their first example https://htmx.org/examples/click-to-edit/ ) is wild to me. You might remember when a thing called DHTML revolutionized how JavaScript could be used to build interactive UIs on the web... why go back to pre-2001 era? I get it, SPAs are overkill, but swinging the pendulum all the way back is very strange.

https://htmx.org/essays/hypermedia-friendly-scripting/

https://hypermedia.systems/client-side-scripting/

I can understand the objection to the first request but the second is necessary to update state on the server. You could avoid the first request via scripting but the complexity, in my opinion in most cases, would not be worth it.

Re: Htmx vs. React: A Complete Comparison – Semaphore

#70

Post by yawaramin »

lxe wrote: post #46

HTMX relying on a server request to make even minor UI changes (e.g. their first example https://htmx.org/examples/click-to-edit/ ) is wild to me. You might remember when a thing called DHTML revolutionized how JavaScript could be used to build interactive UIs on the web... why go back to pre-2001 era? I get it, SPAs are overkill, but swinging the pendulum all the way back is very strange.

htmx doesn't require you to make a request for UI changes. You can express your UI in terms of components which have built-in interactivity, eg dropdowns, inputs, details/summary tags, etc. You can go pretty far with those before you need to make a request.
Post reply on HN