Mesh: I tried Htmx, then ditched it
80 comments
·September 23, 2025recursivedoubts
alex-moon
Oh wow! This is a huge honour, thank you so much! I definitely started writing a "lol HTMX is shit" post, but it just wasn't honest. HTMX is incredibly powerful - I am a fan of what you all have done with it. This attempt on my part to try and write something server-side rendered wouldn't have happened without the kick up the butt HTMX gives me (and all of us).
recursivedoubts
No problem at all. There are aspects of htmx that are good and bad depending on context and experience, and I like having different perspectives on it available for people to read, so thank you for taking the time to put together an in depth essay on it.
stronglikedan
I can't help but to think "lol HTMX is shit" may have beat out "htmx sucks" for first place on that list!
andersmurphy
+1 for datastar. It lets you do really dumb push based streaming html stuff where HTMX isnt quite fast enough (great for multiplayer apps).[1]
Super excited about triptych too! Thanks for pushing that.
stepbeek
Your recent post on using datastar with SSE to power game of life [1] was excellent. Thanks for writing it!
[1] https://andersmurphy.com/2025/04/07/clojure-realtime-collabo...
andersmurphy
Thank you! I've been meaning to write one on the nitty gritty of virtual scroll, hopefully I'll find some time next month.
bccdee
Yeah, in my (limited) experience, htmx works best to grease the wheels of an oldschool multi-page app.
I tried building something with SPAish drag-and-drop interactivity using htmx, and my ultimate conclusion was that functionality like that should either be totally encapsulated as one big htmx swap unit or be written as js "islands" outside htmx.
all2
For my projects that require a distinct unit of functionality, I typically reach for a JS library that I can include as a payload (no npm, no deps, just a JS file). SortableJS is a good example, so is MarkdownJS if I want the browser to handle MD rendering.
This only goes so far, though. At some point, an app developer might want to integrate these distinct units of functionality, and I'm not sure how I would go about that. I haven't gotten to that point.
pabe
If only more people were like you <3
imiric
I find your honesty and pragmatism refreshing.
The first principles thinking of projects like htmx and Datastar is sorely needed in web development. The field has been led astray far too long by blindly following trends that were poorly designed to begin with.
nawgz
You're so right - React is overwhelmingly popular despite its horrid design of running things on the client. No one should ever do that. Make the server do all the work!
gloryjulio
Tbf, app vs server side website are distinct use cases. React is for apps. It's overkill for htmx use cases.
Just like what the htmx author did, react can also have an on the other hand section
xg15
> MESH is based on a simple principle: one component = one endpoint. This is a powerful idea - it allows us to write a HTML-first back-end in such a way that it feels like writing an SPA.
Gotta admit, I'm still not completely grasping the hype around HTMX, but I thought one of the core ideas was that it decidedly should not feel like writing an SPA, but more like old-style PHP or ASP scripts again. (In the sense that the front end is driven by the back end instead of the other way around)
So wouldn't this give you sort of the worst of both worlds? The modeling overhead of SPAs + the tight coupling of HTMX?
treve
Yeah this also reminds me of people getting burned by Web Components, because they use them with the same granularity as React components.
debo_
> With this little helper, I can now start building out a very simple Trello clone to prove the concept.
It's probably worth reading hypermedia.systems before using htmx. The book itself says that for more interactive components, you should go ahead and use JavaScript and whatever interactive framework you want to use on top of that.
I use htmx with Django when:
- I want to have some assurance that I will only have to minimally upgrade dependencies over the next few years
- I'm doing something bog-standard (dashboard / admin UI)
gwd
I feel like this would have been a bit better with some sort of "recap" at the end, to summarize where he got to. The README on the MESH page is a good summary:
> MESH is a fun project intending to demonstrate the kinds of concepts embodied by HTMX - without using HTMX. Specifically, we're rendering modular elements on the server, and hydrating them on the client, swapping them out as needed instead of reloading the whole page. Component updates are swapped in place. Out-of-band updates are sent to all connected clients via SSE (server-side events), meaning all users see updates in real time.
(To expand that for people not familiar with HTMX's out-of-band updates: Basically, in MESH, on the client you hook up something listening to updates sent from the server via SSE. What the server sends are basically snippets of HTML with an ID in them; the listener on the client replaces the HTML in the DOM with that ID with the HTML sent over the wire. This allows the server to arbitrarily update the client's UI.)
So it shares one of the mechanisms of HTMX, which is to do SSR with the ability to replace individual elements.
ezekiel68
I'm conflicted about this post. On the one hand, it's encouraging and cheerful. On the other hand, it pretends to evaluate HTMX by insisting on conventions which... have nothing to do with HTMX.
Spoiler: HTMX does not deliver under artificial constraints.
giancarlostoro
The hot one for me right now is C#'s Blazor, which is not too young, bout 8 years now? Basically you can either have it do all the back-end dynamic rendering with C# for your front-end (Server Blazor) or you can compile it to Web Assembly. I have not written any JS in over a year, and the UI is very similar to how Razor pages are made.
I'm of the opinion that this is the future of web development for numerous web frameworks should they invest in tech similar to Blazor. Phoenix's LiveView also comes to mind. I am hoping a brave soul builds something for Django (I've been meaning to try, but I have too many side projects going on atm) that is similar to Blazor.
pier25
> I'm of the opinion that this is the future of web development
Maybe but not with C#. Rust is a much better language for compiling to WASM. Leptos achieves something similar to Blazor with a fraction of the CPU and bytes.
Blazor is much slower client-side than even the worse JS solution. Scroll to the right to see it compares:
https://krausest.github.io/js-framework-benchmark/current.ht...
I would love to be able to handle all my web stack with C# but unfortunately the WASM bundles are too heavy for most use cases. Plus the DX for frontend is not even as good as it was with JS and Webpack like a decade ago. And these days the bar is much higher with Vite.
klaussilveira
Leptos is cool, but the lack of UI component libraries really hurts.
Same for on every WASM solution out there. I don't want to rewrite for the 1000th time a date picker, accordion, card, tab bar...
I just want to throw new Accordion() on my code and, optionally, override some CSS to make it match the customer palette and go solve hard problems.
bangaladore
> I would love to be able to handle all my web stack with C# but unfortunately the WASM bundles are too heavy for most use cases.
This strikes me as a premature optimization. Most use cases? I'm interested if you have any examples.
> Rust is a much better language for compiling to WASM.
Why's that?
OtomotO
Because Rust doesn't need a GC
bilekas
Why anyone would choose to use the Razor syntax at any time is beyond me, let alone for the web. There is no need to make it so complicated, HTML is interpreted.
As the article says :
> HTMX leaves it up to the developer to impose discipline on their code, however they see fit.
He said that like it's a bad thing. I really dislike those frameworks like Angular for example who simply say "You need to do it the Angular way". That just slows down innovation or clever ideas that solve little problems. Instead if there is a slow framework (looking at some peoples react implementations, Cloudflare recently [0]) Well you probably wont consider it or just see it as a "quirk" of the framework.
[0] https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-...
giancarlostoro
There is no "blazor" way as far as I can tell, we've been rewriting our logic and structure since when everyone started on this project nobody knew how to structure Blazor, moving forward we are following best practices from React projects to an extent in order to better organize and keep components tidier.
elcritch
At one company we had a contractor come in say I can totally build a simple IoT dashboard with a few buttons and wanted to use Blazor. I used Phoenix LiveView, on rpi3’s and later rpi4’s just fine. So Blazor sounded similar and figured it’d be fine.
However Blazor just totally tanked the RPi that had 4gb of ram. It took minutes to load a web page when it did load.
Of course that was years ago. Hopefully Blazor got better. Given that starting point I’d doubt it’ll ever match Elixir LiveView in efficiency.
IMHO, other systems will to struggle to replicate Elixir’s LiveView due to BEAMs design using preemptive actors. It’s not impossible, just that’d it’d take a lot of work to match the responsiveness and resource usage.
Currently I’m using Nim on backend and front end using a Karax SPA. It’s pretty nice sharing the same code on front end and backend!
giancarlostoro
> However Blazor just totally tanked the RPi that had 4gb of ram. It took minutes to load a web page when it did load.
Sounds like Blazor Server, if WASM was used, that shouldn't have been the case. I'm not very surprised considering how insanely efficient the BEAM is with memory.
sieep
Blazor and Phoenix both seem the most intuitive for me also, especially when building complex frontends that require a lot of business logic. Being able to ditch the JS for that kind of work is amazing.
codr7
Tried Blazor, but found it too complicated and heavy for my needs.
I've had more success with Phoenix/LiveView.
sieep
Blazor at work to keep the lights on, Phoenix at home to keep my sanity :D
alex-moon
Definitely - I think what's really interesting is that there is clearly a kind of "attractor" which all of these frameworks are pulled toward. That's kind of mainly what I was trying to aim at with the blog post - MESH isn't a solution at all, it's more I built it to show why it would go that way, i.e. the same way LiveView etc. and of course Blazor went. My question is: is there a form of this that could be merged back into the HTML spec itself and supported by the browsers? My gut says there isn't, by the way.
yxhuvud
There are definitely some parts that are common between these that it could be nice to propagate to the standard. https://alexanderpetros.com/triptych/ lists some of them but I'm not certain how specific to htmx it is or how much it apply to the different variants.
giancarlostoro
Yeah I wasn't trying to take away from what you wrote, just sharing my experience with a different framework. :) Please, use and work with what keeps you productive!
jzig
Alex where on god's green earth is your scroll bar?
pjmlp
Which is kind of return to WebForms, GWT and JSF ways of working, only the implementation is a bit different than on the 2000's.
We moved into MVC approach, because of the headaches that it used to be having to debug all the generated stuff from what the browser actually supports as built-in technology.
I don't see that bright future for Blazor, other than a few .NET shops that don't want to learn native browser technology.
giancarlostoro
The debugging experience and the lack of context shift when going from thinking about how C# works to JavaScript (and all its zillion quirks!) is insanely better. I can put a breakpoint for the front-end and debug it just fine withing VS. I do wish Microsoft would finally open source their debugger, since I've heard loads of complaints about it being proprietary still.
pjmlp
With VS, and it still doesn't do anything when it is something broken at the browser level, CSS, HTML, JavaScript, that the VS debugger provides zero information, just like with WebForms.
klysm
Blazor is fucking terrible. In principle it works in some use cases, the the library is designed horribly and it's very difficult to implement well behaved components. It's like a half-baked react 10 implementation.
causal
I like that people are experimenting with HTMX, so please keep it up. But I don't think MESH is one I would pick up for my projects:
- For complex apps, I love JSX for its ability to distill complexity into simple, discrete components.
- For simple apps, I love HTMX ability to make plain the relationship between raw HTML and API response.
In the MESH examples I see a lot of verbose code that doesn't seem to achieve the simplicity of JSX nor the transparency of HTMX. That said, I certainly don't grok MESH yet so perhaps in a project it would click for me.
nicr_22
Interesting direction, thanks for sharing.
If you're interested in this space it's worth looking at data-star.dev. who takes hypermedia in the opposite direction - one endpoint per page, then push updates to components over SSE.
My worry with MESH is that many endpoints might become a (sorry) mess...
alex-moon
I remember seeing this on the HN front page a while back! I subsequently forgot all about it, of course. Helps to see it again a second time, especially with the new context - I might give it a try next, see how I go. Thanks for the reminder!
andersmurphy
It does require a mind shift as generally you have one connection morphing in all your updates and do CQRS.
The connection per component model that mesh uses is fine until you have concerns that cross across components (this was an issue hotwire also ran into before they introduced morph/refresh).
Instead you have one endpoint per page re-render the whole page via morph on every change. You still have backend components they just send requests up and get their updates via the sse connection for that page. Kinda like view = f (state) just over the network.
leobg
Clickable: https://data-star.dev/
endymion-light
As someone that dabbles in stuff, I found htmx to be amazing up to the point where I need to find out why a specific logic loop isn't working, or need to do something that's slightly off-piste.
Which is to say it's incredibly useful for simpler websites but difficult for anything past 1000 lines. but i may just be using it wrong!
recursivedoubts
One other comment, if you want to experiment w/different behaviors and defaults around the general concept of htmx (generalized hypemedia controls in HTML) you can fork fixi.js which is 89 lines of code (and uses `outerHTML` as the default swap strategy):
https://github.com/bigskysoftware/fixi/blob/master/fixi.js
i created it as an experiment in minimalism:
https://github.com/bigskysoftware/fixi#-fixijs---it-aint-muc...
dkyc
From "framework fatigue" to "new framework" in five paragraphs.
Personally, I find all these minimalist, back-to-the-basics frameworks a bit misguided. It's always reeks a bit of "well my farts don't smell" – other developers' frameworks are bloated, dependency-overloaded and too complex. My new framework is simple, based on a powerful idea, and just right.
Imo, the best way to build a truly good web app in 2025 is to embrace both server-side rendering and client-side rendering, by sharing the same rendering logic between client and server, like e.g. SvelteKit, Next.js and others do.
wry_discontent
Using Next.js is malpractice. I've never had a worse experience with a web framework (and I'm using that word extremely loosely here).
ahallock
While these technologies are interesting, React has built a moat with its component ecosystem. It doesn't matter how intuitive or simple your new frontend solution is when I can `bunx add` a component from shadcn/ui and be instantly productive. Not to mention most companies with frontend integrations are shipping their own React components. You get composability and familiarity.
And while there are decent component libraries in plain JS, the top talent is building in React.
Sounds like this app wasn't a good fit for htmx. I have added it to the "On The Other Hand" section on the htmx website:
https://htmx.org/essays/#on-the-other-hand
Regarding the default swap behavior of "innerHTML":
https://htmx.org/quirks/#the-default-swap-strategy-is-innerh...
Our proposal to merge htmx functionality into the HTML spec uses outerHTML:
https://alexanderpetros.com/triptych/
Also consider datastar, it was written from an SSE-first perspective by a go engineer:
https://data-star.dev/