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.
Blazor suffers from needing to lift the entire .net runtime into wasm. So first you download a gazillion resources that reimplement .net core/runtime/memory/garbage collector/whatever into the page. An eternity later your hello world can finally run.
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
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...
> 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
Why is it that people critizing HTMX always end up slapping abstractions on top of it. It always feels like they are missing the point why htmx is endearing for some of us.
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.
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!
I had a similar experience. There was a point where my expectations became greater than my skill. Whatever simplicity I started with, I kept wanting more interactivity. I kept having to ask myself, "ok, now am I going to implement THAT in HTMX?" and I'd figure out some clever solution that worked... but only just.
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.
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.
innerHTML was the default of htmx for historical reasons, Alex pointed out that anything that can be achieved with innerHTML (or the other swap styles) can also be achieved with outerHTML (albeit with more violence to the DOM) so we felt that was the simplest option for a more general proposal.
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.
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.
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.
The concept of MESH sits somewhere between course grain components and server islands.
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.
I have been using the Umbraco CMS since 2013, and they moved from AngularJS 1.x to Lit for the backend technology. While it was frustrating at first, due to a lack of documentation around the specific CMS APIs, I can see that it was a great choice to move towards a more "standard" technology that is somewhat agnostic of a full library. Working with web components makes so much more sense to me than the way AngularJS works, as well as the React and Vue tutorials I've followed. If I found a killer feature implemented in React or Vue, I could still make use of my Lit web components without having to toss out everything and rebuild.
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):
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.
No, fameworks are relatively opinionated towards the goal the creator had, which is usually in a README.
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
In a similar vein, I consumed some content from DHH talking about how 37Signals went no-build for Hey or something, then figured I'd play with that idea for a bit and see what its like developing a no-build site.
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.
> The immediate problem I hit was that tailwind essentially requires a build;
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.
I've been doing no-build apps for a couple years now and it's been a great ride. The thing is you need to stick to the basics of the web, which tailwind isn't.
That's just my $0.02, some upsides, some downsides, it may not work for everyone.
> 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?
53 comments
[ 3.7 ms ] story [ 113 ms ] threadAlso, i don't see much htmx in the post, but what do I know.
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.
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
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...
[1]:https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
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.
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.
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/
Might be beneficial to think the other way around, and rather think htmx was not a good fit for the app.
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.
[1] https://github.com/cookiengineer/gooey
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:
https://htmx.org/essays/when-to-use-hypermedia/
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.
> 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.
I tried to go pure JavaScript but ended up with web components with lit and really could not be happier.
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...
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.
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
https://e-html.org/
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.
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.
That's just my $0.02, some upsides, some downsides, it may not work for everyone.
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?