React vs HTMX - A Fascinating War

HTMX, React, Solid. HATEOAS, Server Components, Signals. So much going on right now, and this blog post does a great job of encouraging us to all think deeply about it

This blog post was SO GOOD

Check out the author on Twitter

S/O Ph4se0n3 for the awesome edit 🙏

[KangoV]

We have multiple internal web apps for our internal services. All are being converted to HTMX. We're moving quicker, with better support as devs know all of the code. This is where HTMX is going to excel. React will still be used for the very complex web apps. We've estimated that HTMX gets us 90% there. That last 10% is what you would need for a public facing all singing, all dancing UX experience (and I'm talking polished). But mix in HyperScript and maybe you don't need React at all.

[DarenC]

I wouldn't say I'm betting on htmx, but I do hope it takes off. But I'm just one old-school dev who started Web in 1995 and has never really embraced JS. In my mind it's more of a necessary annoyance than something I want to deal with, and discovering htmx as a way of moving back to a more HATEOAS world has me excited

[EXPLAIN_TO_YOURSELF]

as a backend dev, the HtmX helped me too much to develop the first production version of my projects for the clients without any bad experience

[orterves]

8:37 there's a difference between simplicity vs hidden complexity

[orterves]

Client side interactivity with HTMX is simple - just ship the webserver in WASM

[jenreiss]

tbh theo's takes on client side stuff are solid (js), but he's unwilling to consider when writing your own backend is a worthwhile effort, because he's sponsored by people who make their money when dev's dont write their own backends

[theclockworkcadaver]

"Chasm" is pronounced "kazm".

[nickwoodward]

I feel like "clear" is a better term than "simple"

[BenCochrane]

i had the misfortune of not just shipping relay, but forking it and maintaining a fork to integrate graphql subscriptions back in “relay classic” days before subscriptions were implemented anywhere. we built our graphql server on the reference graphql 0.2.0 package and it was ROUGH

[ericka.montanez]

This video was great. As someone fully focused on react and next, knowing I can rely on you to get a view on the outside status of other frameworks is refreshing.

[bioburden]

Any thoughts on utilising Hyperscript with HTMX to bridge that last gap you showed for HTMX? I've shipped Intercooler, HTMX and React to prod - funnily enough, some people seem to struggle more with understanding HTMX vs Next (and by extension, React + supporting libraries) which is simply nuts to me.

[jonathanballona]

@Theo why is your arc browser logo some platinum color? How did you make it look like that?

[stroiman.development]

Just getting to the "simplicity over ease of use" part. Rich Hickey has an entire talk on that topic, "Simple made easy".

[planetchubby]

After falling into the Next.js trap, I've switched to Go with HTMX and Alpine.js. Not looking back. Having fun again.

[Kwazzaaap]

Praying every day HTMX gets native browser support, imagine the frameworks you could build then.

[VivBrodock]

As someone who doesn't need the interactivity of full react, I just need to send a colleague a basic Django web app with a bit of interactivity. htmx has saved me probably hundreds of hours. (Both in terms of how much JS I need to learn (because it's not none, some JS is needed for complex use cases) and not needing to learn a bunch of JS frameworks)

I think the future however is something like the BETH stack, where htmx becomes another piece of a larger tech stack, and not a wholely separate thing all the time like in can be.

[gbjbaanb]

Of course htmx is taking off in popularity. The problem with react and others is that it's built on a false premise: that JavaScript is good.

Js is the problem child that everyone is pretending it's fine, building ever more complex frameworks to hide the problems and adding new ones on there. Web apps are 2 parts: display and comms, stuff when you start to hide the comms bit because you want it to look like it's all js client side code, you will end up with convoluted and often badly performing apps.

Htmx is honest about being the comms party only, handing off display to the browser via dom manipulation and that means it does it really well, really simply to understand, and fits in with the model of browser based HTML.

[ISKLEMMI]

Great video! The article also slaps.
Yeah, if you're building an app that requires greater interactivity on the front end, even Carson Gross himself acknowledges you'll need to use an additional library (or write you're own TS/JS) to achieve that. Web components? Alpine.js? Perhaps even Carson's own (completely batshoot crazy) _hyperscript? Something.

[axMfqTI]

Think most underestimate AlpineJS. That library, compared to React is a so much nicer to use when it come to creating interactivity on the client-site. It's true that the HTMX site points out the limitations that where mentioned in this video. But it also says that you can use a scripting language on the client-side. The site advocated for vanilla JS AlpineJS and Hyperscript. HTMX is not anti-JS like people keep saying. It wants to put the emphasis less on the scripting langue. So instead of using some JS framework to build the whole thing use a little bit of scripting here and there to better the user experience.

[patricknelson]

By the way: HTMX likely pairs _quite nicely_ with web components (custom elements), particularly if you’re using the shadow DOM (since I’ve seen some weirdness with it tampering with the light DOM inside of the elements). Anyway, that said: There are ways to roll your favorite frameworks as custom elements too (shameless plug: mine is svelte-retag). So in a way you can get the best of both worlds.

Plus, there are solutions coming out like Enhance WASM coming out with the goal to make it super easy to SSR web components in PHP, Java, Ruby, Go, etc… thanks to web assembly. Pretty interesting stuff going on right now.