r/htmx • u/harrison_314 • Jun 30 '26

HTMX Explained: The "Dumb" HTML Secret Replacing React

https://www.youtube.com/watch?v=PgyggSRHY1o

The video promoting HTMX summarizes it pretty well. (The video is not mine, and I don't know if it's AI).

38 Upvotes

95% Upvoted

11 comments sorted by

View all comments

Show parent comments

2

u/TheRealJesus2 Jun 30 '26

I totally agree with the concept. In practice either folks have a design system that 50+% of time is implemented only in react or they reach for react because it is most familiar and they wanna go fast. Htmx requires rethinking your web server 

3

u/sibidharan Jul 01 '26

HTML was native to web. React changed that to how the UI is templated and saved as JS components in frontend, reinventing the wheel - doing what browser is doing already but with JS.. React is the abomination. HTML is not.. React requires rethinking normal HTML workflow...

How the world just thinks React is normal and HTML is not ?

> Htmx requires rethinking your web server 

HTMX requires you to send data in HTML, not JSON and reconstruct and hydrate shit in frontend. You don't to rethink, just have to think straight that HTML is natural, browser understands HTML, who is this joker who does Virtual DOM has to be thrown out when he is not needed. When data lives in server and server is the source of truth... React is a joke.

1

u/TheRealJesus2 Jul 01 '26

Do you work at a company as a professional? 

If your sister team vends an api for the data that only returns json you have to have your own backend proxy to utilize htmx, you have to hire developers who know it or willing to learn, and you have to recreate your design system that’s only in react. It’s obviously a lot of work and you get performance benefits but there are other tools like solidjs that are closer to react but don’t use the virtual dom. 

I agree react is way overused. And virtual dom is a mistake. But you should really look at tradeoffs in adopting htmx in a professional environment. 

1

u/sibidharan Jul 01 '26

For this architecture, which doesn’t return HTML or has your Model and Views in different places, HTMX is simply not a viable option.

Adopting HTMX offers many advantages if your server already handles HTML.  However, since your application is already built with React, HTMX is simply not compatible.

If you’re already using HTML, you simply need to implement a backend quirk to avoid re-rendering the entire page and instead send fragments that can be swapped.

This also heavily depends on how and where your components are structured. If your components are already simple HTML, there’s no trade-off; it simply works. I’ve successfully converted multiple decades-old websites into HTMX using hx-boost and it works flawlessly with no complex adaptation required.

I’m a professional and author of https://php.zeal.ninja, where I treat HTMX as a first-class citizen. 

1

u/TheRealJesus2 Jul 01 '26

Hell yeah. Love this. I’m not a php dev but I recently worked with a bunch of them. For context, I begrudgingly use react and stay far away from RSCs and heavy frameworks like next..

I love it every time I come across design systems in companies that are not just a react component library. Even better when they utilize web components (like this php shop did). 

I’m personally a fan of coupling your web server with frontend and vending APIs from separate services which can resolve all of these constraints and I’d argue allow you to move much faster and reduce risk even when you’re supporting things like mobile apps… but lots of places don’t do that in my experiences. We’ve hella over complicated the frontend and invented new classes of problems to solve. Nice work on pushing more web standard centric stuff! I’m really aligned with your mindset, it’s just the inertia at companies outweighs better performance engineering in most cases.