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.
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.
I've had more success with Phoenix/LiveView.
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-...
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.
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.
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.
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.
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.
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?
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.
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.
[1]:https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
but looking at your blog post i just thought "oh, they're showing us mesh", probably you're correct here though
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)
In other words: It has a steeper complexity gradient, albeit with a lower complexity floor.
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!
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:
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.
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
Super excited about triptych too! Thanks for pushing that.
[1] https://andersmurphy.com/2025/04/07/clojure-realtime-collabo...
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.
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.
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.
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?
worthless-trash•6h ago
Also, i don't see much htmx in the post, but what do I know.