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

81–88 of 88 posts

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

#81

Post by yawaramin »

SahAssar wrote: post #55
_heimdall wrote: post #52

Earlier quoted context omitted.

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.

Go to https://htmx.org/reference/#events and find in page 'error'. You will see all the different error events that htmx lets you hook into and handle. Don't be fooled by its apparent simplicity. It's very carefully designed.

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

#82

Post by yawaramin »

sesm wrote: post #42
joegibbs wrote: post #11

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.

Actually someone is already doing this. React components on the backend, rendered to static markup, sent over the wire to the frontend, which uses htmx. Someone tweeted about this recently.

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

#83

Post by throwitaway1123 »

throwitaway1123 wrote: post #45
levkk wrote: 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

Correction: the empty interface is actually analogous to TypeScript's unknown type rather than the any type.

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

#84

Post by sesm »

recursive wrote: post #53
sesm wrote: post #39

Earlier quoted context omitted.

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.

Before switching to React in 2015 I worked with ExtJS and Backbone, and both of them were much harder to reason about. Oh, and GWT too, that was a nightmare.

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

#85

Post by whizzter »

recursive wrote: post #51
whizzter wrote: post #37

Earlier quoted context omitted.

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.

Not sure username checks out? :P

Joking aside, you're right, often it's almost easier in recursive cases to just go with flat object lists and keeping identities on objects and keep parent id's around.

In my view, React is a theoretically beautiful piece of software, and if you're planning on building a synchronized networked system keeping in line with what makes it beautiful will give you it almost for free.

For many practical cases (especially smaller SPA's/pages) however it's probably better to just go with Vue or similar and mutate away and let the system handle all update checks for you instead.

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

#86

Post by kreetx »

andai wrote: post #7
pier25 wrote: post #6

React weight 6.4 kB? In which universe? React-dom alone is 42kB gzip. https://bundlephobia.com/package/react-dom

Preact is 3kb and works as a drop in replacement for React (most of the time). It's also way faster.

Is there a reason to use the original react, or will most libraries also work with preact, which is both faster and smaller?

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

#87

Post by recursive »

sesm wrote: post #84
recursive wrote: post #53

Earlier quoted context omitted.

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.

Before switching to React in 2015 I worked with ExtJS and Backbone, and both of them were much harder to reason about. Oh, and GWT too, that was a nightmare.

I guess different people have different affinity and skills for reasoning about different things. If I knew I'd have to work on react for the rest of my career, I'd find a different line of work, specifically because of how difficult it is for me. Things I've found easier to understand than React include AlpineJS, Solid, Vue, Knockout, and vanilla imperative JS. The only thing I recall ever finding more mind-boggling than React has been Sharepoint-as-an-application-platform.

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

#88

Post by wrapperup »

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.

Agree on the first point, I think using JS makes more sense when you need to update some client state, like a dropdown or even that edit example. But htmx makes a lot more sense when you need to render some data from a server. In a SPA, you receive JSON, only to transform it back into HTML to render, so why not skip that middle step?

You might find https://data-star.dev/ interesting, it takes some of the modern approaches (signals, etc) and mixes it with the efficiency of sending straight-up HTML, htmx style. It's very similar to using Alpine + htmx together.

Post reply on HN