Live data from Hacker News

Htmx vs. React: A Complete Comparison – Semaphore

semaphoreci.com

41–50 of 88 posts

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

#41

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…

Where is this promise on the htmx website?

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

#42

I think the list of features says it all. They're not exactly comparable, are they? I don't think there's even anything preventing you from using both with e.g. React on the backend and Htmx on the frontend to load in the HTML that React generates.

React on the backend + HTMX on the frontend would be hilarious. Someone should write a tutorial on this pretending to be serious.

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

#43

React and HTMX aren't addressing the same problem domain. This comparison is about as meaningful as any could be under that constraint.

Why is "dynamic web app without page reloads" not the same domain?

It's a little like comparing HTML and JavaScript, isn't it? React is a JavaScript library (in the sense that you write your own code that calls React functions). Whereas HTMX doesn't integrate with your application logic at all. It provides a mechanism for placing your application components on the screen.

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

#44

Earlier quoted context omitted.

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

Hooks making things complicated, before that it's actually simple, let's try to talk with class-based component. There's only two kinds of data inside a component (class-based), first is props. Props is, similar with html attribute, are given to the component by the caller / owner / parent. ` ` has type as the props key, and "password" as it's value. State is data that lives inside a component and cannot in any way a…

I just learned React/Nextjs for a take home coding interview assignment. I used useState a few times. Why would I need redux when there’s useState and useContext?

Other than being overly verbose, I think React is ok after building my website with Sveltekit. There just seems to be way more support for off the shelf react components and 99% of jobs ask for React.

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

#45
post #3

We've been using Turbo for over a year now (similar idea to Htmx). Pretty happy not to be using React anymore. Most of the complexity is offloaded to the backend where we can handle it better with a typed language system and no middle layer (e.g. GraphQL) between our app and the database. TypeScript is not typed fwiw, e.g. `as any`.

What about the empty interface type in Go?[0] Is that just as problematic for you?

[0] https://go.dev/tour/methods/14

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

#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.

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

#47
I’m sorry to be a naysayer… but you can’t say React is a better performant or higher scale when the user experience down right stinks. There are a few exceptions, but it is overused to the point of detriment of the entire web so some developer can scratch an over engineering itch.

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

#49
post #17

For web apps, you can't use react without react-dom. That adds 131kb. (for react-dom.production.min.js@18.2.0) Very misleading to say react is 6kb in weight.

Presumably they’re using preact for a fairer comparison.

Using preact seems like a fair way to compare preact to htmx. Using preact does not seem like a fair way of comparing htmx to react. That's notable, because that's the title.

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

#50
post #36

Earlier quoted context omitted.

You'd have to try very hard to override a type in Rust when that type comes directly from your database (see SQLx). Rust unsafe features don't allow you to override type safety, but you can directly manipulate raw pointers if you're so inclined. TypeScript really does let you bypass the type checking entirely and drop down to just JavaScript.

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.

Post reply on HN