Mesh: I tried Htmx, then ditched it
ajmoon.com
ajmoon.com
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:
Super excited about triptych too! Thanks for pushing that.
The pro stuff is mostly a collection of foot guns you shouldn't use and are a support burden for the core team. In some niche corporate context they are useful. You can also implement your own plugins with the same functionality if you want it's just going to cost you time in instead of money.
I find devs complaining about paying for things never gets old. A one off life time license? How scandalous! Sustainable open source? Disgusting. Oh a proprietary AI model that is built on others work without their concent and steals my data? Only 100$ a month? Take my money!
Alpine does have a "pro" version as well, but it's just copy&paste code examples. I am not complaining about Alpine, and I even got my employer to pay the maintainer more than what the datastart guys are charging for their pro version. So again, this is not about money.
That right there is the problem, it's maintainer lock-in, I cannot share my improvements with anyone else or benefit from other people's improvements.
[1] https://andersmurphy.com/2025/04/07/clojure-realtime-collabo...
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.
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.
I would love to see cross browser support for forms encoded as application/json instead of url encoded. Additionally making name attributes in forms a query path selector to be able to nest JSON data structures would go a very long way.
Regarding web components and htmx: I kind of disagree with the server sided rendering approach there because I believe in local first web apps that use JSON or other data formats to communicate, but I'm pretty stubborn like that.
Don't have much to prove it yet, but I'm working on gooey, my bindings and components library for WebASM. Hopefully I'll get there in the next months, though Go has a couple of limitations due to how the type system works.
This would be simply amazing. Would so drastically reduce the JavaScript truly needed for basic CRUD stuff. Could even eliminate it if you don’t need variable-length arrays. Just the simplicity of POSTing forms…
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.
Just like what the htmx author did, react can also have an on the other hand section
https://htmx.org/examples/sortable/
But if you really want a component-based system then htmx can be a battle.
I outline when I think htmx is a good fit here:
Might be beneficial to think the other way around, and rather think htmx was not a good fit for the app.
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?
Yeah, I immediately could tell this is where the idea and HTMX collided.
In the worldview where HTMX shines, every page is just a document. HTMX is just a small library to add some capabilities for better interactivity. The goal is precisely to avoid what the author wanted.
Now? No one knows or can tell you what they are for (except leaf components and HTML Web Components maybe)
Somewhere between "React components" and "Microfrontends."
They can still be small, but often you will want many fewer than React components.
Right place, right time.
React, the darling of web dev, has become huge and unwieldy and complex. The newcomers haven't been able to unseat it due to sheer ecosystem advantage. And then comes HTMX with quirky marketing hitting all the right notes (and having some actual good ideas underneath all that).
Huge as in the library ecosystem? - yes it is huge.
Huge as in its a massive dependency? - yes it is huge.
I couldn't understand why React was so popular till I read a comment where someone explained that Tailwind and React in a large company allows the 1000s of devs to work in tiny little components without conflicting with others, and all of a sudden it makes sense why people make themselves suffer using React. Then everyone else is just following the large companies because "well X/Y/Z use it so we should too!!!"
Htmx is 59.9kb minified.
So it’s not huge in at least one dimension: file size.
https://bundlephobia.com/package/react@19.1.1
So, while yes the very latest version of react is *finally* as slim as competitors like preact, don't act like all the legacy projects where a migration is off the table due to time or money just don't exist.
function App() { return <div>Hello world</div> }
Publish it as if it would be deployed to prod. ~185kb
We don't need such comments here.
The commenter above first couldn't understand, then read some comment, then understood something completely out-of-point throwing a bunch of generalisms touching me like "people make themselves suffer" and "everyone else is just following" and decided to dump it here? I can't just leave it untouched since I have actual experience with React.
https://news.ycombinator.com/newsguidelines.html
> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
> Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Try to argue without being personal.
>miroljub 3 hours ago | parent | next [–]
>
>We don't need such comments here.
Is it kind? Is it curious? Thoughtful? Substantive?
Compare the current React API to original React API. There are 18 hooks, Suspense, hydration, transitions, contexts, "user client"/"user server" etc.
React is both bigger (in terms of bytes) and more complex than Angular.
So, to answer your question, React is more complex than just about everything. I’d like to see you find a more complex framework.
We can run other executables on our local. The web itself is the problem and what needs to die to give way to something new.
But something like Figma, Slack is indead a huge hack in terms of technology, but it would be way less code and more performance to just have native desktop apps.
I genuinely don't understand how Angular is considered simpler than React.
Both have a build step. React hasn't needed a "generator" for years now (if you mean stuff like CRA). With tools like Vite or RSBuild, it's like 2 lines. Yeah, the JSX needs to be compiled, but so do templates, custom CSS dialect, and TS's old/non-standard decorators in Angular.
Angular has way more quirks and reactivity foot guns than React. I think major React adoption painpoint is hooks, but while they are clunky, they're way "easier to hold" than most Angular tools.
Same when it comes to state management libraries in angular, but I digress.
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)
Spoiler: HTMX does not deliver under artificial constraints.
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.
It's extremely messy. Hostile to debugging. Hostile to testing. Bad HMR. All this to offer us RPC and filesystem based routing (neither of which I even want in a framework).
They're all tools that need more context to decide on when you use them.
For example, in my use case (SaaS) I focus on something that makes refactoring a breeze. Type-safe end-to-end is important there, so I use orpc+react for most projects. If you don't like contract-first APIs you're going to hate this, but it makes me think out what I actually want in my frontend before I write the database. This kind of [mocking -> real data] way of coding makes you proactive when designing the app
> 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.
React is for fine grain components and HTMX is for lightweight interactivity — update part of a page.
The classic React use case is an editable, filterable drop down. The classic HTMX use case is click a button and load some text.
The overlap comes in the middle, with a simple form validation. React says make each field a component that handles its own validation and error messages. HTMX says just return a re-rendered form with the error messages. MESH says make the form a component with its own endpoint.
HTMX can do the same thing: you can do `hx-trigger="changed delay:500ms"`, and make an endpoint for that component that will do validation, update an error message status area (adding or removing an error as appropriate), and even potentially enable / disable the "submit" button.
It seems to me that the main difference in approach is whether the "source of truth" for the state of the page is on the client or the server. HTMX is designed to be flexible (which is one of TFA's complaints actually), but its primary vision is HATEOAS (Hypertext as the Engine of Application State); which to my understanding of reading HTMX's documentation, is meant to mean that everything important about the client state should be kept on the client; the server should be able to be entirely reactive. What I see skimming through MESH (and data-star.dev) is that the "source of truth" is on the server.
Not an authority in this area, so happy to be corrected on all those points. But I am in the middle of building a dynamic query form using HTMX, trying to design it with HATEOAS principles, so it is something fresh in my mind at any rate.
Well, the thing about HATEOAS is that it's REST, REpresentational State Transfer. And nothing in REST says "you should store client state on the client". You store state where it's convenient (in reality, mostly on the server for lightweight interactive apps, mostly on the client for SPA-like apps), and exchange representations of it between the server and the client (as long as both understand the data format being exchanged)
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.
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.
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.
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?
There's relatively recent AOT for Blazor, but even that has to ship all the managed DLLs and part of runtime for the runtime reflection / metadata support.
Basically anything isn't an in-house tool. Captive users don't have much of an alternative.
Blazor is specially bad for anything that is public and/or needs to run on mobile.
> This strikes me as a premature optimization
Avoiding shipping 10-20MB of WASM code is not premature optimization... it's just common sense.
I can agree that for C# teams it might be better to use Blazor but objectively JS/TS solutions are just better. Again, look at the objective hard data:
https://krausest.github.io/js-framework-benchmark/current.ht...
Blazor uses 45x the memory compared to vanilla JS and up to 3000x the KBs.
> Avoiding shipping 10-20MB of WASM code
Do you have examples of this? I'm seeing more like 1-2 MB, and most of that is the runtime, which will be cached. This is very comparable to any other framework.
> Blazor uses 45x the memory compared to vanilla JS and up to 3000x the KBs.
Which doesn't matter unless it actually affects outcomes.
So you think a priori it's fine to shove MBs of code to a mobile user?
And, if you get into that situation with Blazor, what's the plan for solving the problem? Other than moving features to JS.
> Do you have examples of this?
I don't have any links at hand but the JS benchmarks I linked uses 4MB of uncompressed code (12MB with the AOT version) just for displaying a table and changing the data.
Here's a demo that's sending like 2MB of Blazor code for a button that updates some text:
https://blazor-demo.github.io/Counter
Here's someone using dotnet 9 reporting a 17MB download and 67MB with AOT:
https://www.reddit.com/r/Blazor/comments/1kse00c/blazor_wasm...
I think we have to consider whether or not that matters.
> Here's a demo that's sending like 2MB of Blazor code for a button that updates some text:
Okay, but then what is the size increase if you have a full app? Is it 2MB per button (obviously not).
My point is you are so focused on things that may or may not matter. So saying its useless for most usecases is a terrible position.
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!
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.
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-...
They have a pretty extensive history of encouraging everyone to get on the wagon only to drive it straight into the nearest ditch. You can't trust a company that competes with its own customers.
Silverlight was proprietary, Blazor is MIT licensed and using open web technologies that are NOT going anywhere any time soon. We just had another major upgrade to Web Assembly's spec not that long ago.
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.
A bit hyperbolic, if you use a modern linter like biome or eslint it can warn you of the few that may cause issues.
Additionally, our agency is polyglot, and in no way frontend teams are going to start doing Blazor instead of their favourite framework of the month.
I've had more success with Phoenix/LiveView.
Though they did manage to really shave the runtime off somehow. It used to load megabytes and megabytes of data.
> numerous web frameworks should they invest in tech similar to Blazor. Phoenix's LiveView also comes to mind.
Phoenix live view sends minimal diffs that get applied to the DOM. It doesn't have "components that run in the client and on the server". Everything is done on the server, with very specific extension points into JS
I want to stay flexible, a completely independent frontend and a completely independent backend.
I tried Phoenix for about 7 months this year and ultimately quit due to it feeling clunky and unintuitive, same with Livewire or any other SSR templating solution I've found.
If there's SSR templating that is actually enjoyable to work with (from a DX perspective), I'd happily try it. Sadly nothing feels as good as just building web components.
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...
To handle errors in HTMX, I like to use config from [0] to swap responses into error dialogs and `hx-on-htmx-send-error` [1] and `hx-on-htmx-response-error` [2] to show the dialogs. For some components, I also use an `on-htmx-error` attribute handler:
// https://htmx.org/events/
document.body.addEventListener('htmx:error', function (event: any) {
const elt = event.detail.elt as HTMLElement
const handlerString = elt.getAttribute('on-htmx-error')
console.log('htmx:error evt.detail.elt.id=' + elt.getAttribute('id') + ' handler=' + handlerString)
if (handlerString) {
eval(handlerString)
}
});
[0]: https://htmx.org/quirks/#by-default-4xx-5xx-responses-do-not...
And while there are decent component libraries in plain JS, the top talent is building in React.
- 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.
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...
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.
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!
I also could never quickly refactor or move things around without a headache. Skill issue, possibly...
So I ended up rewriting in React, which overall has been just better to meet the ever increasing interactivity requirements of my site and also my preferred workflow.
Maybe 10 lines of code.
Then you can go as simple or as complex as you want without having to awkwardly rig it up to another UI system.
And then suddenly you need to be aware of the quirks: https://htmx.org/quirks/
And then you need your backend to handle all the weird new headers: https://htmx.org/reference/#request_headers
And then you need to learn completely non-HTML things like "attribute inheritance" https://htmx.org/docs/#inheritance
And then you need to learn a whole new DSL https://htmx.org/docs/#trigger-modifiers
HTMX probably has more concepts than react at this point in time.
I do think it is a bit overengineered however, though there are other implementations of the idea.
What you call "monstrosity" is just as trivial and rare.
See how this works?
You claimed that HTMX doesn't require learning new paradigms. When it's actually a new paradigm replete with multiple different requirements, custom DSLs, new behaviors etc.
Htmx is an order of magnitude easier to get started with for a person who already knows html, ask me how I know.
I tried to go pure JavaScript but ended up with web components with lit and really could not be happier.
<mesh-card id="card-123" hx-swap-oob="true">
<template shadowrootmode="open">
<link rel="stylesheet" href="/static/css/components/card.css" />
<div class="card">
<div class="card-header">
<h3>Updated Card Title</h3>
</div>
<div class="card-content">
Updated card description here.
</div>
<div class="actions">
<button type="button">Edit</button>
</div>
</div>
</template>
</mesh-card>
class MeshCard extends HTMLElement {
connectedCallback() {
if (!this.shadowRoot) {
const tmpl = this.querySelector('template[shadowrootmode="open"]');
if (tmpl) {
this.attachShadow({mode: 'open'})
.appendChild(tmpl.content.cloneNode(true));
}
}
}
}
customElements.define('mesh-card', MeshCard);Your average person building a webpage early on wasn't concerned about markup. I've never met anyone that isn't a LaTeX user or software developer that cared about markup. We cared about how the page would look and how it behaved (how it was, "animated.") Fundamentally there's a lack of appreciation for, "web design as a painterly exercise" and that to me creates the crisis. The humane discipline of designing a webpage is in most respects divorced from the act of coding a website. It's fundamentally a question of ethics and aesthetics; of, "whys."
https://html.spec.whatwg.org/multipage/text-level-semantics....
I think you’ll find that most people who love HTMX don’t ever want something that feels like writing an SPA.
There's no integration with routers, state stores, or rpc handlers. There are no DTOs shared between the frontend and backend. It has low coupling.
High cohesion and low coupling bring benefits in engineering productivity.
In other words: It has a steeper complexity gradient, albeit with a lower complexity floor.
If you really need to make a web _application_ with lots of reactive interdependent elements, HTMX is not the tool for the job.
At this point you're better off using something like SolidStart
[1]:https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
The immediate problem I hit was that tailwind essentially requires a build; at the most basic level because you don't want to bundle properties that your app isn't using, but at a more sophisticated level, because properties like `md:flex` or `max-w-[100px]` intrinsically demand some amount of dynamism in their generation. I played around with re-creating a functional no-build subset of tailwind, but it quickly hit many-many dozens of kilobytes while being unable to cover even a small subset of Tailwind's capability.
So, no tailwind, which I feel is a major loss in productivity. I didn't end up pursuing the dream further; a hyper-minimal vite app, even just using basic HTML & CSS, feels to me a very small price to pay given all the benefits it carries.
That's just my $0.02, some upsides, some downsides, it may not work for everyone.
1. If you don't want to build something, you don't need Tailwind. https://every-layout.dev/ will get you very far (well, it will get you very far regardless of what you use for CSS)
2. "No build" is a mantra and a cult. There's nothing bad about building your final app. The problem is that the web made it extremely complex.
but looking at your blog post i just thought "oh, they're showing us mesh", probably you're correct here though
Also, i don't see much htmx in the post, but what do I know.
IMHO this is already over-engineered as the frameworks being critisised; no simplification happening here.