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).
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.
I was quite excited for Datastart until I saw that they keep a good chunk of the functionality behind a proprietary license [1]. It's not even about the price (it is a bit steep though, but I guess if you use it in a commercial project it will pay for itself), it's the proprietary part.
A "good chunk of functionality" is a mischaracterisation. I don't use anything from pro and I use datastar at work. I do believe in making open source maintainable though so bought the license.
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!
Datastar uses SSE. In practice you almost always want SSE rather than websockets or your own UDP protocol. Websockets are an operational nightmare once you get off the happy path.
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.
> 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.
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…
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.
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.
I think I'd try a lightweight framework like preact or vue that I can use without a build step. Keep components as separate & stateless as possible; let them live as little islands of javascript, notifying other parts of the frontend of updates through custom DOM events and talking to the server directly with fetches.
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.
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!
I've been doing IT for decades. Many times I've come across something that seems stupid yet also has a non-trivial number of supporters. When this happens (and it will many times), don't just continue to think it's stupid. Question if you are stuck on some paradigm or mindset that makes the thing seem stupid to you. That might call for a good head shake, a walk in the park, or a weekend-long bender to open your mind to new ideas. You don't have to jump on their bandwagon, but at least you'll increase your understanding and strengthen your position.
Just reacting to the executive summary: where are the tradeoffs? The port decreased memory usage on the client significantly, by how much did the server's burden increase? How have their hosting costs changed now that less work is being offloaded to the clients?
idk they didn’t say, but the server side delta of JSON generation vs HTML generation is small in the overall scheme of things and HTML-style apps tend to be less chatty because they push you towards the one-request-per-view ideal
Right? Someone show this kid how we used to make web apps back in the day, using hardware 1/100th as powerful. Turns out you don't need to send megabytes of JS to the client to have it render a table
> 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?
> 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.
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.
> Gotta admit, I'm still not completely grasping the hype around HTMX
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!!!"
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.
Your level of understanding is not very huge. React is an absolute pleasure to use, and we do enjoy it - that is why it became the most popular library and a revolution in web dev.
Why do you speak for someone else? Those "We" are in the same room with us?
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.
> 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."
React is not huge. It’s just a library that converts strings to tags.
Oh you want to use React? You want JSX — the only use case for the React library? You want routing and URLs and history and state management and … ok you don’t want a virtual DOM but you need it. And you need Babel and a build tool and a generator framework (because piecing it all together is too hard) and tree shaking and CSS (in JS!) and lots of weird and complex lifecycle hooks.
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.
Sometimes it feels like those who would develop the next React should really just try to develop the next web browser. Why spend all this time and effort building what is essentially a massive wad of chewing gum and paperclips to take what is essentially a glorified document reader and make it into an application platform?
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.
A lot of those “apps” are just dynamic documents and forms that still fits the web model. It’s just that SPA is a bad architecture for them. Why push rendering to the client if all the data comes from the backend or need a round trip through there?
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.
The honest answer is because all your users have that wad of chewing gum and paper clips installed on their devices already, and you don't need an IT admin to whitelist your executable to install it in the contexts where that's still necessary.
I worked with large React and large Angular (1 and 2+) codebases. I even migrated projects between them.
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.
> 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
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
We had a nontechnical person choose Next, against my recommendation but I didn't have the authority to override that choice, and it's been a total nightmare.
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).
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.
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:
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.
> 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.
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):
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.
> 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.
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.
Rust is unnecessarily low-level for the vast majority of things that a web app would be doing. There's no reason to struggle with the borrow checker in that kind of code when tracing GC is available and makes things so much easier.
Because rust actually compiles the code to native binaries. C# kind of started doing it some time ago, but AOT still has various limitations and edge cases. Blazor doesn't even compile your code into wasm - it ships the whole dotnet runtime as wasm and runs your app as bytecode. This means massive downloads regardless how simple your code is.
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.
> Most use cases? I'm interested if you have any examples.
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:
I don't use Blazor, but your point is still about solving a "problem" that might not exist.
> 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.
> I don't use Blazor, but your point is still about solving a "problem" that might not exist.
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:
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!
> 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.
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.
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.
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.
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.
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.
I'm not sure I've run into such a state yet, are you using Blazor without any UI component libraries? I am using MUDBlazor, genuinely curious what you're running into.
I used it enough to understand how it works, compare it with my WebForms, GWT and JSF experience since their early days in 2001 onwards, and decide to stick with MVC, and browser native stack.
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.
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.
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.
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.
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!
Yeah, I'm very wary about putting all my eggs in Microsoft's basket after what I've seen.
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.
I know all three, and I'm not seeing it dying any time soon. WebAssembly is not going anywhere, neither are dynamic back-end systems. I have drastically less issues with my front-end while using Blazor compared to just doing raw JavaScript. I've built everything from a PWA from scratch using Vanilla JS, to an iFrame Frenzy web app a client paid us top dollar to build.
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.
At a previous job they were moving away from Blazor (which bummed me out, I love the philosophy) because every time they deployed it broke sessions/disconnected all active users.
I've made some toys with Blazor; my teams are using Vaadin at a Java shop, now. Not exactly the same implementation, but a similar idea: express front end code using the backend language.
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.
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
I am torn about SSR. I see the advantages but I hate the workflow so so much... Also tightly coupling the views to your backend is something I really hate.
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.
Try Datastar, it leans into web components, and they're working on a plug-in that integrates web components with Datastar. For example, I believe the star field on the front page of it's site is a web component.
We write only front-end logic on our Blazor components now, and use services to glue the front-end to the back-end which is the recommended way is my understanding. It's really nice, especially when you pull in something similar to MudBlazor.
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.
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...
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!
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.
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 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.
Hey alex-moon one feature you had issues was that HTMX does not process server generated shadow DOM content because it uses the standard old DOM parser. Next point release should have https://github.com/bigskysoftware/htmx/pull/3185 merged hopefully which will allow the use of Document.parseHTMLUnsafe() which is the modern browser replacement that does support this use case but it might go behind a new config flag.
This might be tangentially but as a 90's/2000's brat I've always been confounded by the old maxim, "HTML is for markup not presentation" and sure but if that was true why are there clearly a bunch of tags which don't meaningfully markup anything except to tell the browser to display the text some way? I'm thinking, "<i>", or, "<b>."
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."
These elements have non-presentational definitions in the current spec. A screen reader could make use of the semantic difference between <strong> and <b>, even though desktop browsers default to presenting them the same way.
Alpinejs is my go-to for small stuff. Probably wouldn’t want to write something gigantic with it, but it can be broken into components pretty nicely so maybe that hesitation is wrong.
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.
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.
> 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.
Ah, possibly - the way I think about Show HN is it's for links to a codebase or demo app. There is a demo app linked in this article but it's not the link posted to HN. The Guidelines explicitly mention "blog posts" as not Show HN - https://news.ycombinator.com/showhn.html - but they also say that's because they "can't be tried out". Grey area? Happy to do whatever precedent suggests.
Cool! I'm also not 100% sure, have only done a handful of posts. I would definitely put "Show HN" on a link to the demo app or the Github repo - and wait for the mods to correct me :D
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.
This has been my experience, the reality is HTMX doesn't scale well in terms of complex ideas / code. Great if you have something simple to achieve, not so great for a massive ongoing project.
In other words: It has a steeper complexity gradient, albeit with a lower complexity floor.
99% of websites are, or should be, just a simple document(s) with a couple of forms, and the goal of HTMX is to help achieving low to medium complexity interactivity, and better UX on such sites easy. These are not the flashiest and most sexy demos, but the staple of the Internet.
If you really need to make a web _application_ with lots of reactive interdependent elements, HTMX is not the tool for the job.
Though, for me, that begs the question: why not just use vanilla Javascript's .fetch()? One gets more flexibility than HTMX could ever provide, and the same logic is really not that many more lines to type.
I feel like part of the mess of modern web development is the idea that most people actually need to "do something more complex than the basics". So much rehashing and effort spent trying to force MPAs into a SPA shape just because it's trendy.
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/
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).
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.
I can't help but to think "lol HTMX is shit" may have beat out "htmx sucks" for first place on that list!
+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.
- [1] https://checkboxes.andersmurphy.com
I was quite excited for Datastart until I saw that they keep a good chunk of the functionality behind a proprietary license [1]. It's not even about the price (it is a bit steep though, but I guess if you use it in a commercial project it will pay for itself), it's the proprietary part.
[1] https://data-star.dev/reference/datastar_pro
A "good chunk of functionality" is a mischaracterisation. I don't use anything from pro and I use datastar at work. I do believe in making open source maintainable though so bought the license.
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!
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...
Thank you! I've been meaning to write one on the nitty gritty of virtual scroll, hopefully I'll find some time next month.
That would be great to see. Likewise more details about your custom compression settings.
Datastar folks have some cool videos - https://data-star.dev/videos
HTMX does have web socket support! I've been experimenting with it...
Datastar uses SSE. In practice you almost always want SSE rather than websockets or your own UDP protocol. Websockets are an operational nightmare once you get off the happy path.
HTMX also has a SSE extension. I’m working on a multiplayer game as a hobby project and am not too far along.
Regarding your proposal:
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
> 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.
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…
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.
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.
I think I'd try a lightweight framework like preact or vue that I can use without a build step. Keep components as separate & stateless as possible; let them live as little islands of javascript, notifying other parts of the frontend of updates through custom DOM events and talking to the server directly with fetches.
You could consider using web components
[dead]
If only more people were like you <3
Stupid question, why have innerHTML as the default for HTMX but outerHTML for the spec merge?
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.
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!
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
Do you think apps like this are not a good fit for HTMX? Drag drop interactivity?
[flagged]
I've been doing IT for decades. Many times I've come across something that seems stupid yet also has a non-trivial number of supporters. When this happens (and it will many times), don't just continue to think it's stupid. Question if you are stuck on some paradigm or mindset that makes the thing seem stupid to you. That might call for a good head shake, a walk in the park, or a weekend-long bender to open your mind to new ideas. You don't have to jump on their bandwagon, but at least you'll increase your understanding and strengthen your position.
idk sometimes it turns out to be a pretty good approach for some problems:
https://htmx.org/essays/a-real-world-react-to-htmx-port/
Just reacting to the executive summary: where are the tradeoffs? The port decreased memory usage on the client significantly, by how much did the server's burden increase? How have their hosting costs changed now that less work is being offloaded to the clients?
idk they didn’t say, but the server side delta of JSON generation vs HTML generation is small in the overall scheme of things and HTML-style apps tend to be less chatty because they push you towards the one-request-per-view ideal
I'm already a fan of htmx, you don't have to sell me anymore.
Right? Someone show this kid how we used to make web apps back in the day, using hardware 1/100th as powerful. Turns out you don't need to send megabytes of JS to the client to have it render a table
https://htmx.org/essays/htmx-sucks/#no-front-end-back-end-sp...
> Sounds like this app wasn't a good fit for htmx
Might be beneficial to think the other way around, and rather think htmx was not a good fit for the app.
> 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?
> 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.
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.
Yeah this also reminds me of people getting burned by Web Components, because they use them with the same granularity as React components.
Because that's literally how they were marketed and hyped for a very long time.
Now? No one knows or can tell you what they are for (except leaf components and HTML Web Components maybe)
are they supposed to be more or less granular?
Less granular.
Somewhere between "React components" and "Microfrontends."
They can still be small, but often you will want many fewer than React components.
anything can be granular, but doing that in web component is very clunky, it's like writing java with a class and a code file for every tiny thing.
> Gotta admit, I'm still not completely grasping the hype around HTMX
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).
React is not huge - I don't understand where that conception comes from.
Huge as in usage? - yes it is huge.
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!!!"
React is 7.4kb minified, add react-dom and you add another 3.6kb - so ~11kb
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
https://bundlephobia.com/package/react-dom@19.1.1
https://bundlephobia.com/package/htmx.org@2.0.7
https://bundlephobia.com/package/react-dom@18.3.1 130kb for react-dom 15-18 (would check more but site has rate limited me...)
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.
I just created a new vite react project. All it does is render:
function App() { return <div>Hello world</div> }
Publish it as if it would be deployed to prod. ~185kb
Your level of understanding is not very huge. React is an absolute pleasure to use, and we do enjoy it - that is why it became the most popular library and a revolution in web dev.
> Your level of understanding is not very huge
We don't need such comments here.
Why do you speak for someone else? Those "We" are in the same room with us?
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.
"We" as the HN users, expect at least some level of civility when conversing here. It's right up there in the guidelines:
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.
Tell me then does this kind of comment fits those guidelines or welcome here?
>miroljub 3 hours ago | parent | next [–]
>
>We don't need such comments here.
Is it kind? Is it curious? Thoughtful? Substantive?
Compared to what?
React is not huge. It’s just a library that converts strings to tags. Oh you want to use React? You want JSX — the only use case for the React library? You want routing and URLs and history and state management and … ok you don’t want a virtual DOM but you need it. And you need Babel and a build tool and a generator framework (because piecing it all together is too hard) and tree shaking and CSS (in JS!) and lots of weird and complex lifecycle hooks.
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.
Sometimes it feels like those who would develop the next React should really just try to develop the next web browser. Why spend all this time and effort building what is essentially a massive wad of chewing gum and paperclips to take what is essentially a glorified document reader and make it into an application platform?
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.
A lot of those “apps” are just dynamic documents and forms that still fits the web model. It’s just that SPA is a bad architecture for them. Why push rendering to the client if all the data comes from the backend or need a round trip through there?
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.
The honest answer is because all your users have that wad of chewing gum and paper clips installed on their devices already, and you don't need an IT admin to whitelist your executable to install it in the contexts where that's still necessary.
I worked with large React and large Angular (1 and 2+) codebases. I even migrated projects between them.
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.
You forgot to mention the chaos of npm CVE transitive dependency hell.
Anything - it's like 10kb
Technically, yes. But the reality is almost nobody uses "just" React. There's typically tons and tons of other dependencies.
More like 5-10x that.
React is huge compared to both itself and most of the competition.
Compare the current React API to original React API. There are 18 hooks, Suspense, hydration, transitions, contexts, "user client"/"user server" etc.
Yet you don’t have to use all of it, but it’s there if you need it.
And yet it's a 10th the file size of htmx
"Huge" doesn't always refer to file size
> 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)
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
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).
I’m ready to bet that anyone that chose Next is now battling a ball of mud and a buggy one with that.
We had a nontechnical person choose Next, against my recommendation but I didn't have the authority to override that choice, and it's been a total nightmare.
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).
My favourite SSR framework is built in to React. It's called `renderToString`
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.
How does one handle errors with MESH?
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:
This gives very good UX on network and server errors.[0]: https://htmx.org/quirks/#by-default-4xx-5xx-responses-do-not...
[1]: https://htmx.org/events/#htmx:sendError
[2]: https://htmx.org/events/#htmx:responseError
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.
> 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.
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...
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.
> 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.
https://leptos.dev/
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.
Rust is unnecessarily low-level for the vast majority of things that a web app would be doing. There's no reason to struggle with the borrow checker in that kind of code when tracing GC is available and makes things so much easier.
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.
> 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?
Because rust actually compiles the code to native binaries. C# kind of started doing it some time ago, but AOT still has various limitations and edge cases. Blazor doesn't even compile your code into wasm - it ships the whole dotnet runtime as wasm and runs your app as bytecode. This means massive downloads regardless how simple your code is.
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.
> Most use cases? I'm interested if you have any examples.
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.
I don't use Blazor, but your point is still about solving a "problem" that might not exist.
> 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.
> I don't use Blazor, but your point is still about solving a "problem" that might not exist.
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...
> So you think a priori it's fine to shove MBs of code to a mobile user?
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.
Because Rust doesn't need a GC
https://developer.chrome.com/blog/wasmgc/
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!
> 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.
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-...
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.
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.
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.
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.
I'm not sure I've run into such a state yet, are you using Blazor without any UI component libraries? I am using MUDBlazor, genuinely curious what you're running into.
I used it enough to understand how it works, compare it with my WebForms, GWT and JSF experience since their early days in 2001 onwards, and decide to stick with MVC, and browser native stack.
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.
> Zillions of quirks
A bit hyperbolic, if you use a modern linter like biome or eslint it can warn you of the few that may cause issues.
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.
Tried Blazor, but found it too complicated and heavy for my needs.
I've had more success with Phoenix/LiveView.
Blazor at work to keep the lights on, Phoenix at home to keep my sanity :D
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.
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.
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!
Alex where on god's green earth is your scroll bar?
Blazor will die like Sliverlight. Just learn HTML, CSS and Javascript.
Yeah, I'm very wary about putting all my eggs in Microsoft's basket after what I've seen.
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.
I know all three, and I'm not seeing it dying any time soon. WebAssembly is not going anywhere, neither are dynamic back-end systems. I have drastically less issues with my front-end while using Blazor compared to just doing raw JavaScript. I've built everything from a PWA from scratch using Vanilla JS, to an iFrame Frenzy web app a client paid us top dollar to build.
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.
So what? It is just another tool in the toolbox. A tool that someone already invested in webdev can pick up in a week or two.
At a previous job they were moving away from Blazor (which bummed me out, I love the philosophy) because every time they deployed it broke sessions/disconnected all active users.
Sounds like Blazor Server limitations.
I've made some toys with Blazor; my teams are using Vaadin at a Java shop, now. Not exactly the same implementation, but a similar idea: express front end code using the backend language.
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.
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
I am torn about SSR. I see the advantages but I hate the workflow so so much... Also tightly coupling the views to your backend is something I really hate.
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.
Try Datastar, it leans into web components, and they're working on a plug-in that integrates web components with Datastar. For example, I believe the star field on the front page of it's site is a web component.
https://data-star.dev/
We write only front-end logic on our Blazor components now, and use services to glue the front-end to the back-end which is the recommended way is my understanding. It's really nice, especially when you pull in something similar to MudBlazor.
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.
"top talent" lol
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.
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...
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!
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.
Clickable: https://data-star.dev/
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.
Nothing is stopping one from adding a bit of javascript when needed. Or complimenting with something like alpine or jquery.
This is why I never understood htmx. Vanilla react is pretty easy to get started with, you just create a root component and mount it to a DOM element.
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.
After being a React true believer I ditched it recently.
I tried to go pure JavaScript but ended up with web components with lit and really could not be happier.
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.
Hey alex-moon one feature you had issues was that HTMX does not process server generated shadow DOM content because it uses the standard old DOM parser. Next point release should have https://github.com/bigskysoftware/htmx/pull/3185 merged hopefully which will allow the use of Document.parseHTMLUnsafe() which is the modern browser replacement that does support this use case but it might go behind a new config flag.
then you may be able to do things like this I think
Strange post. It feels like trying to carve a piece of wood with an iron. Cool hack, I guess... this is hacker news after all.
This might be tangentially but as a 90's/2000's brat I've always been confounded by the old maxim, "HTML is for markup not presentation" and sure but if that was true why are there clearly a bunch of tags which don't meaningfully markup anything except to tell the browser to display the text some way? I'm thinking, "<i>", or, "<b>."
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."
These elements have non-presentational definitions in the current spec. A screen reader could make use of the semantic difference between <strong> and <b>, even though desktop browsers default to presenting them the same way.
https://html.spec.whatwg.org/multipage/text-level-semantics....
>> it allows us to write an HTML-first back-end in such a way that it feels like writing an SPA.
I think you’ll find that most people who love HTMX don’t ever want something that feels like writing an SPA.
Yes. With HTMX, one can put a page definition and its endpoints in one file. It has high cohesion.
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.
Alpinejs is my go-to for small stuff. Probably wouldn’t want to write something gigantic with it, but it can be broken into components pretty nicely so maybe that hesitation is wrong.
[dead]
Is the alpine + htmx dynamic for appropriately handling interactive pages not suitable for many use cases?
there is vulgarity to r3 lab's sse protocol, which mozilla's documentation for closing event streams goes over.
[1]:https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
I prefer the approach of EHTML:
https://e-html.org/
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.
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.
Bulma doesn't require a build, and works quite well.
I’ve use Tailwind standalone CLI with non-node projects (Django, etc) and it’s always worked well.
But: Using the Tailwind standalone CLI is a build step. Which means you're no longer no-build.
> 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.
Congratulations, you have recreated NodeJS but with GO and HTMX.
alex, this is a "Show HN" really, just fyi
Ah, possibly - the way I think about Show HN is it's for links to a codebase or demo app. There is a demo app linked in this article but it's not the link posted to HN. The Guidelines explicitly mention "blog posts" as not Show HN - https://news.ycombinator.com/showhn.html - but they also say that's because they "can't be tried out". Grey area? Happy to do whatever precedent suggests.
yeah my bad i dont know the rules or what i'm talking about
but looking at your blog post i just thought "oh, they're showing us mesh", probably you're correct here though
Cool! I'm also not 100% sure, have only done a handful of posts. I would definitely put "Show HN" on a link to the demo app or the Github repo - and wait for the mods to correct me :D
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.
Maybe the causality goes the other way: once you need to do something more complex than the basics, HTMX doesn’t work that well anymore
This has been my experience, the reality is HTMX doesn't scale well in terms of complex ideas / code. Great if you have something simple to achieve, not so great for a massive ongoing project.
In other words: It has a steeper complexity gradient, albeit with a lower complexity floor.
99% of websites are, or should be, just a simple document(s) with a couple of forms, and the goal of HTMX is to help achieving low to medium complexity interactivity, and better UX on such sites easy. These are not the flashiest and most sexy demos, but the staple of the Internet.
If you really need to make a web _application_ with lots of reactive interdependent elements, HTMX is not the tool for the job.
HTMX is 14 kb of Javascript and additional complexity on the backend.
At this point you're better off using something like SolidStart
Though, for me, that begs the question: why not just use vanilla Javascript's .fetch()? One gets more flexibility than HTMX could ever provide, and the same logic is really not that many more lines to type.
I feel like part of the mess of modern web development is the idea that most people actually need to "do something more complex than the basics". So much rehashing and effort spent trying to force MPAs into a SPA shape just because it's trendy.
Is HTMX an antimeme?
I heard there's a cup for ppl who hate htmx.
Also, i don't see much htmx in the post, but what do I know.
[dead]
[flagged]
Feels like an LLM designed system.
IMHO this is already over-engineered as the frameworks being critisised; no simplification happening here.