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

51–60 of 88 posts

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

#51

Post by recursive »

whizzter wrote: post #37
hankchinaski wrote: post #14

Earlier quoted context omitted.

i just struggle with hooks, data management, how data flows in between components etc etc

I did also, many coming from classic programming that hasn't touched upon functional ways of thinking usually struggle since they're prone to shortcuts whereas React really likes you to keep everything as transformations (or as some would call it functional style). Much React work these days is confined into components, people sadly over-do it also because they perceived Redux as overkill and try to shoehorn entire a…

Transforming mutations into react-compatible object creation is not always trivial, particularly with twisty object graphs. I once spent a week trying to untangle a reducer monstrosity that wished it could mutate. In the end, I don't think I totally fixed it. It can be hard.

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

#52

Post by _heimdall »

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…

How errors are handled is often pretty specific to each use case.

Sometimes it does make sense to send back an HTML fragment with an inline error message, or a fragment that gets injected as a toast notification. Other times you may want to redirect to an error page with a full page refresh. Depending on the HTTP request method used, you may be able to return an HTTP error response too.

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

#53

Post by recursive »

sesm wrote: post #39
hankchinaski wrote: post #8

As a backend engineer I Still haven’t managed to learn how react data management or JSX works. Every time I try to dive into it I get a strong migraine. I hope something easier comes popular before I would need to learn FE

Now imagine how bad pre-react era frameworks were if the main selling point of React was “your SPA is now easier to reason about”.

That was a selling point of all the prior (and subsequent) frameworks as well. In fact, that's the selling point of htmx over react too. Opinions vary about how well any of these things achieve that objective.

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

#54

Post by [deleted] »

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…

[deleted]

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

#55

Post by SahAssar »

_heimdall wrote: post #52
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…

How errors are handled is often pretty specific to each use case. Sometimes it does make sense to send back an HTML fragment with an inline error message, or a fragment that gets injected as a toast notification. Other times you may want to redirect to an error page with a full page refresh. Depending on the HTTP request method used, you may be able to return an HTTP error response too.

Absolutely. My point is that most or almost all HTMX examples/tutorials/tests show no error handling at all.

Sooner or later you need to handle these different errors, and I don't think HTMX has these sort of "non-happy" paths at mind.

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

#56

Post by jakelazaroff »

hellcow wrote: post #50
SahAssar wrote: post #38

Earlier quoted context omitted.

Yes, typescript allows you to do that. It is entirely voluntary and you can do untypesafe things in almost any typed language. I'm not sure how that makes typescript "not typed".

I think the parent is simply pointing out that “Typescript’s types are not sound.” That is, the types at runtime may not be what you assumed at compile-time. This happens very often at API boundaries because fetch returns `any`. Many languages do have sound type systems, and I would argue we should prefer those.

The fetch issue (and JSON.parse/localStorage.getItem/etc) can mostly be mitigated by using type guards to “parse” data at the point of ingress.

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

#57

Post by SahAssar »

hellcow wrote: post #50
SahAssar wrote: post #38

Earlier quoted context omitted.

Yes, typescript allows you to do that. It is entirely voluntary and you can do untypesafe things in almost any typed language. I'm not sure how that makes typescript "not typed".

I think the parent is simply pointing out that “Typescript’s types are not sound.” That is, the types at runtime may not be what you assumed at compile-time. This happens very often at API boundaries because fetch returns `any`. Many languages do have sound type systems, and I would argue we should prefer those.

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.

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

#58

Post by Karrot_Kream »

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?

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

#59

Post by throwanem »

SahAssar wrote: post #57
hellcow wrote: post #50

Earlier quoted context omitted.

I think the parent is simply pointing out that “Typescript’s types are not sound.” That is, the types at runtime may not be what you assumed at compile-time. This happens very often at API boundaries because fetch returns `any`. Many languages do have sound type systems, and I would argue we should prefer those.

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 of argument rather footless, in that blaming Typescript for something Rust also requires is incoherent.

Perhaps the originator of the claim under discussion will clarify his meaning.

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

#60

Post by depressedpanda »

hankchinaski wrote: post #8

As a backend engineer I Still haven’t managed to learn how react data management or JSX works. Every time I try to dive into it I get a strong migraine. I hope something easier comes popular before I would need to learn FE

> As a backend engineer I Still haven’t managed to learn how react data management or JSX works.

What are your specific pain points?

JSX is HTML-like syntactic sugar, just write normal html but put JS stuff in curly brackets.

Data management can be tricky at first, but as long as you remember that everything that isn't memoized (via e.g useState) is recomputed on every render pass, you're 90% there.

You can get into the reeds of it of course, but you really don't need to if all you want to do is just build a regular app.

Post reply on HN