I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right.
The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form with some large select lists as well as the response of results became noticeable laggy when there was more than a half dozen results.
I ended up switching to Alpine Ajax (https://alpine-ajax.js.org/) and pulled the form out of the response and just used a local x-data on it to track the state. This greatly reduced the HTML I needed to send back to just the list of results. I did make the form a bit more complicated but the experience felt a lot snappier. Both versions just synced the form state from the URL and kept the initial render as full HTML from the server.
I found that Alpine + Alpine Ajax was SMALLER than HTMX 4 even though (in my opinion) it offers a lot more features in a more approachable and intuitive way if you need to do interactivity and don’t want to trigger a request just to toggle some classes or attributes. Of course you can use both together (I started down that road) but you are mixing worlds and making the bundle size bigger at the same time.
I still like HTMX and will probably use it again. I just found that with an interactive experience like a product listing page, where the HTML response was quite large/expensive to fetch, it wasn’t the best choice for that.
I think I understand now, even the partial required submitting everything to the server, which can be skipped if you can have interactivity without unnecessary requests.
Exactly. The partial response was 100kb-200kb of HTML + the backend query time. Of course, depending on your filters. But a large chunk of that was just sending down the form on the left side, which I already had on page load, so that penalty was real.
It was only the right side results of the experience that needed to be refetched when the form changed.
But in HTMX, you are expected to just send the whole dang thing back for every change. Makes sense for a like-button, a dialog, or even a classic form submission.
My refactor cut the HTML response by about 70kb and that made a big difference. The form became fully static and I had a simple Alpine data component that would just sync that state with the URL. Still used a GET on the form and still used the same partial endpoint. Just way less HTML to wait for.
The cards contained a large data table outlining a bunch of attributes across many columns and rows. Not an ideal design but the client wanted those stats included in the card so they were visible right away.
We could have paginated the results, but the client didn’t want that either because you are just promoting the results that happen to land on the first page. You also can’t just CTRL-F and find things that way.
Now, those could have been loaded in dynamically. That isn’t a free solution either though. It means adding a new endpoint, with a new partial, another request-response round trip, plus the error handling in case it fails, etc. etc.
I just ended up being more practical to go with a reactive JS form component to reduce the HTML being sent back and forth.
Why are you expected to send down the whole thing? Maybe I’m missing something, but when you send the request from the form the response is just a partial of the results on the right hand side, using hx-target to specify some div instead of replacing the form. Form just stays there?
To sync the form state based on the current selections in the form. This is often called facets. The form contained many options and as you filtered those options would change. So you need a way to update the form too. Hence, compute the full thing on the server (the form state, the options within the fields, and the results) then send it all back.
Except you don't. Use hx-vals, hx-include, or even hx-headers to pull in additional data into the request that's outside of the immediate form/component.
I can't really understand what you're describing. You have form on left & results on right, but you're requesting the new form state & re-rendering the form HTML on each request? Why? My naive understanding is that you could use something like hx-target to have the response to the form submissions update only the results area & the form should not need rerendered at all.
Why does the form need rerendered on a per request basis? HTML/Browser already tracks the current form state.
Because the form changed based on the selections you made. Like facet search.
Say you have a clothing store listing page and you filter for only "Shirts". Well, the filter that has "Material" might remove (or disable) the option for "Denim" because that is only for "Pants". So that state needs to be computed some where. My thought was, "Ok, refetch the whole thing with the updated options within the form (disable options that can’t be combined together) + the product results for those filters". But that was just a lot of HTML to ask for after each change.
So decoupling it so that the form never refetched, just the results, made it a lot snappier. But you still have the form state issue where you want to update the options based on selections. So the form became a little Alpine data component and the results stayed as an HTML partial.
AJAX is old tech though, using stuff that worked in the year 2000 is cheating in 2026. You are supposed to make the site slow and bloated for some reason.
Despite the fact that HTMX is a good solution in many cases, it's not the best solution in all cases. Ditto for React, and for any technology actually. Planning and consideration are always required, if you care about the end result.
Is there a reason why you don't have an endpoint + template that renders only the result list. The form could be separate thing and issue a form submit request with all the selected filters?
Seems better than rendering the whole page. You could even display a loader while the results are loading, and swap the list html element on success.
That is what I ended up doing but once I did that, I had a hell of a time getting that dynamic form working well with just the HTMX primitives. I even tried to do two different partials that would be fetched when I needed each one to rerender.
The gist of what I was saying was that once I had a more complicated experience, the benefits of just fetching a fresh partial each time started to dwindle. The HTML response grew, I needed a bunch of inline handlers to patch over some state issues, as well as the complexity of the template, just started to be too much. Really it was the Alpine part that I was missing. Simple class toggles, easy way to toggle aria attributes, show/hide for elements, and reactive/computed values, were the things I needed to get the results the client wanted.
If I was building a simple search input + results, I would use HTMX all day. These forum people make it work and that seems like a great use case. But it just didn’t fit with a more sophisticated form that had dynamic options plus a large results display and the burden of a slower query to just get the data.
If I wanted to do that I would have added pagination. But that UX also sucks in a different way.
I think dynamically fetching results (ala infinite scroll) would have been more complicated to build. I would have had to add an intersection detection (HTMX 4 has that) to trigger the form/request again, but with an ever increasing chunk offset slice. I also need a way to track that state as well. Considering I had one big HTML response, I don’t think I could have done that efficiently without splitting it anyway. Even if I could "pluck" the results I needed from the HTML response, the penalty of waiting for the response was the factor.
If you have any links to some demos where there is something like that, I would appreciate it.
All that being said, the count of items actually isn't the most relevant part. The most relevant part is the amount of HTML per single result. If you have a sophisticated card component (a title, a description, images, a table of information inside of it or complicated layout) just loading six cards could end up being hundreds of HTML elements.
So even if you lazy loaded elements in chunks, those chunks are still gonna take a while to fetch given the size of the HTML. You also break CTRL-F-ing since those results don’t exist in the DOM until you trigger their fetching code. Same problem as classic pagination.
I would have to completely refactor my entire experience regardless because if I want to lazily load the cards/results gradually, I would have to split up the layout to make it more efficient.
So my approach to shrink the HTML response was to break it up the "live" section to just the right half.
Infinite scroll is a shit pattern it creates complexity and makes it hard to get back to a position on the generated and changeable list. It can also be unexpected slow. Everyone knows a page load can be slow if their Internet is slow but a slow down when scrolling feels janky.If you think you need it you need pagination and more importantly better filters and search so users can find stuff easier without 200 options.
It was a genuine question. I’ve implemented infinite scrolling in HTMX and it’s quite easy, another commenter posted an example from the HTMX docs and it’s a couple of lines of html.
I think HTMX is a great fit for forum software. Forum websites mostly deliver non-interactive content in the form of text and maybe some audio, video, or image content. All of this can be represented as HTML and CSS.
With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions.
The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.
> Forum websites mostly deliver non-interactive content
I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things.
Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other people obviously like them.
Is that the kind of thing you'd be giving up as you move to a platform like HTMX?
It also doesn't actually work correctly - if you scroll too quickly it doesn't load more content. Possibly just a CSS issue on the example because the last row is not visible when scrolled to the bottom of the page due to the footer and its large margin.
I first learned about endless scroll in a Ruby on Rails meetup, where the presenter was showing how to craft snippets of HTML with ERB and using a bit of JS to insert them below the existing entries. It's definitely possible.
Maintaining a code path with a snippet for each possible viewing experience, back when REST was all the rage, was a bit obnoxious though.
Yes but then you're doing HTMX not HTML and at that point why not use something that's more flexible. I'm saying this as a person who still maintains a small application done with Intercooler.js and is perfectly happy with it.
If you want basic interactivity, HTMX is fine.
If you want something more (like sortable) I'd reach for lit instead of adding the Sortable.js dependency, something the HTMX docs suggest ( https://htmx.org/examples/sortable/ )
And yes there are also some scenarios that you want to control the whole routing and rendering stuff, then go for Solid, React, Angular, Vue, whatever.
There is no golden rule to all of this but finding out what makes sense is a fun exercise.
I don't necessarily disagree that there comes a point at which you are working more against HTMX than with it. I think rather than measuring that contention point between HTMX and SPA/MPA in terms of interactivity I'd measure it in the amount of client side state and logic needed. If you need a bunch of client side state and logic, for example a digital audio workstation, then a SPA would definitely be the appropriate pattern.
But interactivity in largely content-driven sites doesn't necessarily preclude HTMX. You can do a bunch of fancy interactive stuff with HTMX and some minimal JS. Drag and drop sort is a tiny drop-in JS snippet. Skeleton loaders and spinners are supported out of the box in HTMX as is infinite scroll as others pointed out.
I'm not saying Next.js, Solid Start, Remix, Nuxt or some other hybrid server and client rendered model doesn't work for forum software. Or that even client only rendering can be a valid approach if you accept the trade-offs (no curl-ability). People should use whatever they feel productive building with.
But if your backend is already a non-JavaScript server rendered framework like Django then HTMX makes a ton of sense to add some interactivity.
I personally think that if you are adding a sortable component to a content-driven website, maybe it is moving away from being such a website. Normally a textarea should be enough for most people to order a "list" but if the list items have ids (they are entities), then that'd not suffice, and you may be going in the direction of a web application.
Otherwise, I'd recommend HMTX even if you have a super flexible JS backend.
That said, this is all baseless thinking without seeing any requirements and as I said before, trying to choose the right abstraction is the hard but fun part.
Well I also do not really know the legitimate use case for infinite scroll (other than trying to push gambling/slot-machine tricks onto your userbase).
I get lazy-loading for pages that contain a ton of media of which the user will likely only see a fraction. But some people seem to think infinite scroll is a good idea with text based content as well..
> The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.
That's how interactivity has always worked.
Server-side render everything + ship interactivity via js on top of it.
I feel like most of the web developers forgot that React/Vue/etc solve a specific problem: single-page application.
This is a very narrow and specific problem: navigating from page to page not causing full page reloads.
But the web has changed since SPAs were needed in major ways:
1. the average device and connection is insanely faster than 10-15 years ago. Receiving and rendering content is not the problem it once was in the age of 2g connections and limited hardware mobile devices. Even the very low end phone from few years ago has nowadays 0 problems loading and parsing few hundred kbs of html and js.
2. Web technologies moved at all levels. Server technologies, cloud ones, browser ones. React and company are solving problems that barely belong to the modern web.
In short: today you can have an app-like, spa-like experience even out of fully server-side rendered applications. While also benefitting from shipping much less code to the client.
There's a very minimal amount of websites and applications out there that benefit, and aren't crippled by these rendering libraries: those that vastly leverage offline capabilities of the platform and want to keep working regardless of internet being available. I'm talking the notions and linears.
But bar from those, still working with this React slop is just not good for the user. Even multi billion companies hiring leetcode ninjas can't get acceptable user experience and performance out of those libraries, and it's not a coincidence: they keep forcing the wrong tool for the wrong problem.
They keep living in 2018 and at the end of the day the only excuse for those react/angular+tailwind slop is that there's an entire generation of developers that doesn't know anything else and has long lost any proper engineering skill (if there is any) in finding the right tool for the problem. This is a familiarity issue, not sound technical decisions. It's the "you can't go wrong with oracle/mysql/ibm", but actually you can, and it shows.
What's worse: it's incredibly cheap to experiment different solutions and approaches via LLMs in 2026, but people keep slopping the same monstrosities.
> the average device and connection is insanely faster than 10-15 years ago
Using the same reasoning, I’d come to the opposite conclusion. Devices are much faster than they were 10-15 years ago, but network latency is still roughly the same because physics limits how much it can improve. So reducing network round trips matters more than ever, which favors SPAs over MPAs.
But a lot of the time they can happen in the background where the user doesn't see them, or on a part of the page the user isn't currently interacting with, preventing it from being a stop-the-world interruption.
It’s in the name: an MPA requires a page roundtrip for every navigation, while SPA requires a single page roundtrip. Any subsequent requests are part of the application itself and can be handled without disrupting UX.
An MPA can make as many queries/service requests as it needs to to render the result. Most— the vast majority of SPAs I’ve ever written, maintained, or used— do that from the client, making many requests to render the new route.
The UX for an SPA can indeed be excellent, but the average SPA is worse than the average MPA, in my opinion. It’s just much easier to break things in many subtle ways in an SPA.
An SPA still requires roundtrips, just not to load the DOM root. Most of them do more than one roundtrip per navigation, making them worse than MPA. They also break loading screens.
One nice thing about using React even on the web is that it forces your Backend to be REST right from the start. Although I sincerely thing that is less important now with the explosion of LLMs. I've started thinking about everything as Display + MCP Server. Where a SPA front end is really just pre-defined display.
> React/Vue/etc solve a specific problem: single-page application
That's not true. They solve the problem of requiring separate code paths for interactive elements - one for initial render and another for updates.
Previously the server rendered the initial HTML and then client JS updated it after e.g. user clicks a button, but with React/Vue/etc., it's merged into one code path because HTML is derived from the current state.
> Even multi billion companies hiring leetcode ninjas can't get acceptable user experience
Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.
> Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.
This is untrue and is weird misunderstanding on your part. Most of modern UX and UI is designed to fit the needs of the customer for the frontend team/dev: the product or marketing or sales department. The user of the website is very rarely the customer for the dev.
The point is that there's only one template and DOM is derived from that template. This concept is the same in both Vue, React and other popular component-based UI frameworks.
> A Single-Page Application (SPA) is a web application or website that loads a single HTML page and dynamically updates its content as users interact with it, rather than loading entire new pages from the server.
That's the definition, I didn't made it up.
And those libraries solve that.
Your other definition, can be fully implemented server side, Elixir's Phoenix does that. But it's not the only one.
Your prior claim was that they only solve one problem, not about a definition. They solve several problems:
- less data can move over the wire compared to sending a full page every time (this is in your definition, and is definitely not always true, as sometimes REST APIs can return far more data than what's needed to render the screen)
- the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers
- you can write tests for your frontend, e.g. you can unit test components' behaviour and style in isolation
- the frontend can also work, or at least respond usefully to the user, when the network or the backend are not working
That second point is almost never true
" the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers"
In a reasonably complex application, each interface ends up needing its own shape of optimized APIs. Otherwise the clients become very complex munging/reshaping data or making too many API calls, throwing away a lot of data etc.
You said, that React/Vue/etc. solve a specific problem: SPAs - that's not accurate. That's not the problem they solve.
According to what you said, CSS also solves the problem of making an SPA because you could "switch pages" by changing CSS class names on `body`. But if someone asked what CSS is you're not gonna answer "you use CSS to make an SPA", even though _technically_ you can use it to make an SPA.
I basically use HTMX for all my Web Apps, including PWA(s) that run as ~near native apps on iOS/Android. It's great! I aso pair this with DaisyUI+TailwindCSS. YOu really can't go wrong, there is something quite pleasant about writing your web apps in ordinary HTML with partials and the extensions that HTMX adds to the browser for SPA-like interactivity.
How does the PWA work offline with HTMX? The “hit the server for fresh markup fragments” approach seems like it has to be abandoned here, however simplifying it is for online apps.
It seems like the wrong tool for the job to me, but I was curious and thought about it a little:
After initial page load, a service worker could intercept all the HTMX app's AJAX requests, but it could only work with what's already cached. Using a lot of tooling like workbox the developer could pre-cache the entire app. (Would that mean no dynamic responses?)
Alternatively, implement the entire HTMX app in JS, build the app once for the NodeJS/Deno backend and once for the front-end. After page load, the frontend could take over.
Or something like that. It's a bit convoluted as PWA solutions often are.
I know that you can have a shortcut on the users phone home screen but I've run into a bunch of problems with that setup where hitting it multiple times opens multiple tabs etc.
You have to build a proper PWA with a fully formed manifest.json first off. Web Push (i.e: Push Notifications) are fully supported on both iOS and Android. The Only thing that doesn't work is "background" work (but preactically speaking I haven't really needed it).
If you'd like to find out how I build Mobile-first apps with Go, HTML and HTMX hit me up.
Happy they did this. Htmx is a great fit for server rendering - which in many or most cases is what you should do in any case. You can always put a mini VueJS or ReactJS app inside of a template for a very custom interactivity.
Putting ReactJS or VueJS for a little interactivity is hardly the correct approach. It makes no sense to bring them in for "a little". What made React and React-like (Angular v2, Vue.js) frameworks stabilise is that they're about the right abstractions and everything else for managing dynamic html converges to about the same thing.
Why not? You can have server side routing that returns the page and then react then takes over and hydrates a small part within the page or the complete page. A similar approach is used for the islands architecture, and you can even combine different frontend frameworks for maximum flexibility, e.g. developer preference. You can decide to load your frontend libraries lazily or as shared scripts so they are cached and only take up some bandwidth on initial load (a couple of kB minified and zipped).
In principle I agree that putting React or Vue in for a little interactivity is a bad approach, if the same can be achieved with Htmx, which it usually can.
However for some really complex mini apps, that's another story. But for the rest of those CRUD pages, you can go simple server side rendered.
It can be. Think something like a file viewer or a text editor, or a music players. You can probably make do with vanilla javascript, but there’s some threshold where using react to take care of the state<=>ui relationship is worth it.
Again, the issue with htmx is that it pretends like it is not a framework, when in fact, it is just a second attempt at angular 1.0, with even more naive assumptions about web apps.
That’s basically a massive hack. Every real world app will need enough js that htmx will require you to put js on front end and you’ll need to hack it together. Just like we did php+js 15 years ago.
I've found this to not be true at all. You can do quite a lot with just HTMX. Any client-side Javascript™ you strictly need can often be done fairly minimally with Locality of Behaviour (LoB).
LoB isn't going to reconcile Chat Messages rendering state and Notifications. Their dependent state by nature. HTMX largely seems to ignore this reality.
In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.
> In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.
Which makes it even more ironic that in the 10 years since React was announced in 2013 and when I quit Facebook, they never managed to fix the original state synchronization bug that they demonstrated in the original React announcement for more than a few months at a time at best.
I'm sure technically it wasn't a singular bug over the years and the causes were complex, but React did fuck all in relation to the unread message counter being correct.
> In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.
SSE is perfect for chat/notifications and is a lot simpler than syncing. The server pushes updates to the client doesn't require a sync. SSE is also more performant since it can keep the connection open. The example below is on a $10 vps last I heard.
I think HTMX lacks a sensible way to do composition and reuse on the component level, something that react/vue/solid do extremely well. Since you are basically mostly swapping html content, it gets tricky if you want to reuse partials.
What I've found in practice is that HTMX is extensible enough that I can write a small amount of javascript to "put a funny plug on the end of HTMX" to talk to say Leafletjs if I'm drawing maps, and want things dynamically updated.
It works quite well, and saves me an awful lot of tedious mucking about with other stuff.
I've been saying for years: All buildings should be parking garages.
Because you can always just put a mini residential building inside a parking garage if you need tenants.
Need an office? Just put a mini office in the parking garage. It's perfect.
Parking garage construction is so clean and simple. Other buildings are too complex! From now on, I'll only build parking garages.
(Then I guess you have the opposite example of the residence without the parking garage! It's a great place to live, but there's nowhere to store my things and park my car!)
As others mentioned, not great for rich interactivity.
Example: Render a scrollable list and you need to change contents of the li items mid scroll - it resets the scroll position to the top because of how it replaced the entire HTML on render. There are workarounds you can do, DOM hacks, but they aren’t ideal.
React is designed around that kind of thing. They do some funny magic under the hood to support seamless DOM reconciliation and things like prop drilling of entire components on the prop of another, and so-on. This gives them a more granular way to manipulate the DOM without total page re-rendering.
Next.js SSR works because it’s designed around React. So they’re giving you all the SSR stuff you want but you still get client-side React for rich interaction design and other SPA niceties.
So if someone releases an SSR-like thing like htmx it feels like something is missing.
Maybe htmx needs an opinionated framework that gets more into high performance rendering and state management.
Or maybe they hone in on the “basic web pages” market. Who knows, maybe those make a comeback somewhere. PDF gets replaced with standalone HTML or something, and people use HTMX, or maybe it’s used in a dev environment for HTML email design in some future where email can have events (who knows). Couple of ideas.
Right now it feel incomplete or has nowhere for me to plug it in. Love the concepts though, HTML/JS should have been like that.
Adopting something like HTMX is primarily a UX choice, and the language you use to serve it is almost irrelevant to UX. JavaScript is a nice backend language. It’s fast, has a massive ecosystem, and many people know it well.
Using Django w/ frontend frameworks has been a struggle for me. (I only dabble as a hobbyist.) I think splitting the backend off into a restful API makes the marriage work. I've looked at django-rest-framework (https://www.django-rest-framework.org/) and django-ninja (https://django-ninja.dev/). Of course,, then you're discarding a lot of batteries that come with the django framework. Perhaps using Django templates for admin / internal facing work only, and React for customer-facing sites can be a healthy compromise?
That's the architecture my B2B SaaS uses, except Vue instead of React. We deploy the SPA to a CDN and it feels snappy. Some clients access the API directly via OAuth. django-allauth is the other critical piece. Works great altogether.
> A lot of pages in Misago are implemented twice: as Django templates and React.js components.
I think this tells all about the level of competence of these devs. That’s literally unmaintainable. So instead of fixing the problem and have a nice api + interface + ssr, they patch it up with a yet worse approach in htmx.
> there's a lot of forum software out there that still does the old way of rendering as much as possible on the server and using some JavaScript on client to improve its interactivity here and there. And people are happy with that
Yeah, server returns class xxx and jquery needs to target that. Once is out of sync silent bugs will appear. And will be many, not a few. No way to check at compile time.
But on serious note, htmx is basically a solution in the search of a problem. It is the new hype.
Or rather, a solution that overlooks 2 decades of learnings. Yes, for a small set of projects htmx is okay, but even then, where htmx is ideal, static is king, and once static is not good enough, htmx sooner or later starts to feel like the XAML and BPEL soap.
The fundamental problem is that it is pretending to be a declarative language while entirely imperative.
Sounds like you never worked on complex HTMX systems. They're easier to maintain, allow for easy caching of HTML fragments in a page. For higher traffic pages React just fails spectacularly.
How does React fail for high traffic pages? It is amazing that you would suggest I don't understand HTMX "systems" and then go make such assertion.
I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. I looked into htmx and it is very much a second attempt at angular 1.0, which I did use for some good half decade as that was the best option at the time, but sooner or later, you get sick of stuffing "little codelets" inside attributes all over the place, which is exactly what htmx does.
If you want to understand what htmx is going to look like at scale, look at angular 1.0 projects.
It is different in that some of what happened on the frontend now happens in the backend, but overall, it is the exact same approach, so as I said in a sibling comment, it, it is just a second attempt at angular 1.0 with even more naive assumptions about web.
Based on skimming the couple sibling comments, I believe the issue you have had with htmx is precisely that you have somehow conflated it with angular. If you think they're the same, you will use them the same and have the same poor outcomes.
In another comment, you mentioned State Management. If this is on your mind then you are using htmx wrong. You should not be managing any client side state with htmx. State is on the server or in your database. Interactions on the client should immediately reflect the updated server state. If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework.
> If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework.
Yeah, because clients never need to keep track of state like which block is expanded or which tab is selected or that the previous page was or what the user is currently typing...
Angular being basically the same HTMX is nonsense and you should know better.
Say you have a huge Google Ads budget burning up on those landing pages. Make one version with React and one with HTMX. Open Lighthouse and see performance difference. First page renders are much slower with React. Page load is slower and this makes a huge difference in mainland USA where people are still on 3G speeds on their budget phones.
"High traffic" might be the simplified view here and it took me a few page memos to explain it to my lead but the gist is that React is slower, takes longer to load and most of what it is used for is easily done with plain HTML and sprinkles of JS as needed. Unless you're streaming sound or video like you do on Facebook pages it's really not the right tool for the job in a majority of cases.
The only nonsense here is ignoring that React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015.
The gist of it continuously seems to be that people who think HTMX Great, know very little about good frontend engineering.
Being a curmudgeon is not good engineering leadership. "Seeing everything" is just old people being wistful, not actually contributing or doing in the now. I deployed (via ftp) my first site before Netscape so I do understand where you're coming. There isn't at present a valid or detailed criticism of why X won't Y based on all of that supposed XP - so why mention it? Educate us - why will it fail? Is it because you never mastered CDN's or the exact opposite? It certainly doesn't lead any credibility the assertion that A will become Z because they look similar or embrace similar ethos.
But I will answer your main questions since your comment seems to be in good faith.
Just like angular 1 choked on complex, high-frequency UIs, HTMX is going to follow the same faith. Github uses a similar approach to HTMX and you will find that even for such a simple system, their notification indicator elements on the same page are often out of sync.
The reasons for this is that State Management is hard, which is why the reconciliation loop of React-like frameworks and shadow-dom does away with pushing complex state management to user application and handles it systematically.
Of course, this doesn't mean htmx is useless, for a specific case of web apps, it is good enough, but the problem is that often times, you start with "specific cases" and your application grows overtime.
So when you consider that and the cost of doing htmx vs React or any react-like framework, picking htmx is only reasonable if it is the only option you're comfortable with and rarely on merit.
If it's a traditional React SPA, you can use a versioned bundle with immutable caching and each user only has to download your bundle when you release an update or they use a new browser. You will need to think about how you handle spikes in traffic when you do a release, but even then users won't all load your page immediately after you bump the version.
Most of the time (existing user using the same browser, no update) there will be precisely zero traffic to your servers to load the React app except for the initial HTML skeleton.
For an app using SSR it's more complicated and I'll admit I don't know how that works at very high load
I had landing pages using React on a 1.6M/m budget. The loading times on cell phones in mainland USA meant we had people cancelling the loading of pages. When we converted to straight up cached HTML we saw a huge increase in full page loads.
People weren't cancelling the page load and surfing back anymore. You cannot argue that React is extremely heavy and also adds a lot of time between first render. Test a normal HTMX page in Lighthouse and then convert it to React and you'll see how drastic things are.
People use React today out of habit rather than because it's the best tool for the job.
This just shows that despite the 1.6M/m budget, you did not have people who could do react correctly. React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015.
But while first render is of course important, now everything else is more expensive with htmx because you have to generate HTML on the server, on top of your usual fetch pipeline. Yes, for small traffic it makes little difference, but once you have >10k/s requests, things start to cost.
Yes but why bother with React, Hydrating pages at all if you can do something simpler? What advantages does React provide here?
HTMX tools are simpler while providing straightforward thinking around html fragment caching, whole page caching. React just gives a runaround way of doing everything. I'll remind you React was built so that people could continue watching a streamed video while they navigated on a page. Most pages aren't streaming anything.
What does React have to do with loading times of a page? React does not contribute to that at all other than having to download the JS runtime, which with Preact is 3KB.
> You cannot argue that React is extremely heavy and also adds a lot of time between first render
Yes you can! In no world would React itself add enough render time to make people navigate back, even if running on a computer from the 90s!
This feels like an uninformed, generalized opinion from someone with zero experience on the topic. Have you even used HTMX or a similar approach?
Besides the memes, it is absolutely not hype-driven, but hypermedia driven. It asks the question: could HTML be even more powerful than it already is?
The creators of HTMX even want to standardize core ideas of HTMX into the official HTML specification: https://triptychproject.org/ Please read this and reply when you still think it's hype.
I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go.
Hypermedia is what to web apps what XML is to programming languages. We have tried HTMX as a concept many times over, there is nothing new here, and like everything declarative, sooner or later it will fall short and you're going to reach for escape hatches and what not.
And the features specified in that project is nice to have, in the same way that it is nice that we have Date Pickers or other advanced input features, but it is never going to replace React-like frameworks.
Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management, Google really really tried that with Angular 1.0, and we know it doesn't scale.
> Hypermedia is what to web apps what XML is to programming languages.
I have no idea what this means. The World Wide Web itself is quite literally hypermedia.
The fact that a lot of front-end frameworks appear hell bent on ignoring this fact doesn't make it any less true.
> Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management...
You may have stabilised on JSX, "we" have not. React is one way of building web applications. It's appropriate for a certain subset of highly interactive SPAs, and completely inappropriate for many other things.
> I have no idea what this means. The World Wide Web itself is quite literally hypermedia.
I think he's saying that the Web is hypermedia plus Javascript, rather than just hypermedia. Which means, from the standpoint of the power of hierarchy, that it's Javascript, which also happens to use some hypermedia. Even if you use only a tiny bit of a Turing-complete language, Turing-completeness defines what your system actually can do.
This makes the Web fundamentally awkward, because most of the behavior is defined by the hypermedia part, and users have inconsistent expectations for what happens when you break the illusion.
HTMX works by extending the illusion. JSX works by breaking the illusion earlier rather than later.
[delayed]
I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right.
The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form with some large select lists as well as the response of results became noticeable laggy when there was more than a half dozen results.
I ended up switching to Alpine Ajax (https://alpine-ajax.js.org/) and pulled the form out of the response and just used a local x-data on it to track the state. This greatly reduced the HTML I needed to send back to just the list of results. I did make the form a bit more complicated but the experience felt a lot snappier. Both versions just synced the form state from the URL and kept the initial render as full HTML from the server.
I found that Alpine + Alpine Ajax was SMALLER than HTMX 4 even though (in my opinion) it offers a lot more features in a more approachable and intuitive way if you need to do interactivity and don’t want to trigger a request just to toggle some classes or attributes. Of course you can use both together (I started down that road) but you are mixing worlds and making the bundle size bigger at the same time.
I still like HTMX and will probably use it again. I just found that with an interactive experience like a product listing page, where the HTML response was quite large/expensive to fetch, it wasn’t the best choice for that.
Why is this the top-most comment when the user obviously didn’t know how to use HTMX?
You can always make the server-side render partials based on a request header.
https://github.com/dsego/ssr-playground/blob/main/src/server...
That is what I did. I was using Astro which has full support for partial HTML via the router
I think I understand now, even the partial required submitting everything to the server, which can be skipped if you can have interactivity without unnecessary requests.
Exactly. The partial response was 100kb-200kb of HTML + the backend query time. Of course, depending on your filters. But a large chunk of that was just sending down the form on the left side, which I already had on page load, so that penalty was real.
It was only the right side results of the experience that needed to be refetched when the form changed.
But in HTMX, you are expected to just send the whole dang thing back for every change. Makes sense for a like-button, a dialog, or even a classic form submission.
My refactor cut the HTML response by about 70kb and that made a big difference. The form became fully static and I had a simple Alpine data component that would just sync that state with the URL. Still used a GET on the form and still used the same partial endpoint. Just way less HTML to wait for.
Unless there's a material change to the form, why not just update the changed parts?
I'd also question architectural decisions if you need to send 100kb+ of html down the wire for a partial.
The cards contained a large data table outlining a bunch of attributes across many columns and rows. Not an ideal design but the client wanted those stats included in the card so they were visible right away.
We could have paginated the results, but the client didn’t want that either because you are just promoting the results that happen to land on the first page. You also can’t just CTRL-F and find things that way.
Now, those could have been loaded in dynamically. That isn’t a free solution either though. It means adding a new endpoint, with a new partial, another request-response round trip, plus the error handling in case it fails, etc. etc.
I just ended up being more practical to go with a reactive JS form component to reduce the HTML being sent back and forth.
Thats not on htmx to decide what html to resend that's your engineering work...
Why are you expected to send down the whole thing? Maybe I’m missing something, but when you send the request from the form the response is just a partial of the results on the right hand side, using hx-target to specify some div instead of replacing the form. Form just stays there?
To sync the form state based on the current selections in the form. This is often called facets. The form contained many options and as you filtered those options would change. So you need a way to update the form too. Hence, compute the full thing on the server (the form state, the options within the fields, and the results) then send it all back.
Except you don't. Use hx-vals, hx-include, or even hx-headers to pull in additional data into the request that's outside of the immediate form/component.
I can't really understand what you're describing. You have form on left & results on right, but you're requesting the new form state & re-rendering the form HTML on each request? Why? My naive understanding is that you could use something like hx-target to have the response to the form submissions update only the results area & the form should not need rerendered at all.
Why does the form need rerendered on a per request basis? HTML/Browser already tracks the current form state.
Because the form changed based on the selections you made. Like facet search.
Say you have a clothing store listing page and you filter for only "Shirts". Well, the filter that has "Material" might remove (or disable) the option for "Denim" because that is only for "Pants". So that state needs to be computed some where. My thought was, "Ok, refetch the whole thing with the updated options within the form (disable options that can’t be combined together) + the product results for those filters". But that was just a lot of HTML to ask for after each change.
So decoupling it so that the form never refetched, just the results, made it a lot snappier. But you still have the form state issue where you want to update the options based on selections. So the form became a little Alpine data component and the results stayed as an HTML partial.
AJAX is old tech though, using stuff that worked in the year 2000 is cheating in 2026. You are supposed to make the site slow and bloated for some reason.
It isn’t literally AJAX. Just a catchy name. It is just a fetch wrapper that mimics the $get, $post, etc. API
Despite the fact that HTMX is a good solution in many cases, it's not the best solution in all cases. Ditto for React, and for any technology actually. Planning and consideration are always required, if you care about the end result.
Is there a reason why you don't have an endpoint + template that renders only the result list. The form could be separate thing and issue a form submit request with all the selected filters? Seems better than rendering the whole page. You could even display a loader while the results are loading, and swap the list html element on success.
That is what I ended up doing but once I did that, I had a hell of a time getting that dynamic form working well with just the HTMX primitives. I even tried to do two different partials that would be fetched when I needed each one to rerender.
The gist of what I was saying was that once I had a more complicated experience, the benefits of just fetching a fresh partial each time started to dwindle. The HTML response grew, I needed a bunch of inline handlers to patch over some state issues, as well as the complexity of the template, just started to be too much. Really it was the Alpine part that I was missing. Simple class toggles, easy way to toggle aria attributes, show/hide for elements, and reactive/computed values, were the things I needed to get the results the client wanted.
If I was building a simple search input + results, I would use HTMX all day. These forum people make it work and that seems like a great use case. But it just didn’t fit with a more sophisticated form that had dynamic options plus a large results display and the burden of a slower query to just get the data.
have a look at https://segor.de/ - it just downloads 2MB of product listing data (pre-dating JSON!) and then does all filtering client-side
You swapped out HTMX because you couldn’t figure out how to load a list of items gradually instead of all at once??
If I wanted to do that I would have added pagination. But that UX also sucks in a different way.
I think dynamically fetching results (ala infinite scroll) would have been more complicated to build. I would have had to add an intersection detection (HTMX 4 has that) to trigger the form/request again, but with an ever increasing chunk offset slice. I also need a way to track that state as well. Considering I had one big HTML response, I don’t think I could have done that efficiently without splitting it anyway. Even if I could "pluck" the results I needed from the HTML response, the penalty of waiting for the response was the factor.
If you have any links to some demos where there is something like that, I would appreciate it.
All that being said, the count of items actually isn't the most relevant part. The most relevant part is the amount of HTML per single result. If you have a sophisticated card component (a title, a description, images, a table of information inside of it or complicated layout) just loading six cards could end up being hundreds of HTML elements.
So even if you lazy loaded elements in chunks, those chunks are still gonna take a while to fetch given the size of the HTML. You also break CTRL-F-ing since those results don’t exist in the DOM until you trigger their fetching code. Same problem as classic pagination.
I would have to completely refactor my entire experience regardless because if I want to lazily load the cards/results gradually, I would have to split up the layout to make it more efficient.
So my approach to shrink the HTML response was to break it up the "live" section to just the right half.
Infinite scroll is a shit pattern it creates complexity and makes it hard to get back to a position on the generated and changeable list. It can also be unexpected slow. Everyone knows a page load can be slow if their Internet is slow but a slow down when scrolling feels janky.If you think you need it you need pagination and more importantly better filters and search so users can find stuff easier without 200 options.
Want to help rather than throw tomatoes?
It was a genuine question. I’ve implemented infinite scrolling in HTMX and it’s quite easy, another commenter posted an example from the HTMX docs and it’s a couple of lines of html.
Wouldn't constantly loading new items into a select form be super annoying? Can HTML even keep a select input open when new items are added?
I think HTMX is a great fit for forum software. Forum websites mostly deliver non-interactive content in the form of text and maybe some audio, video, or image content. All of this can be represented as HTML and CSS.
With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions.
The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.
To paraphrase: "I think HTMX is a great fit for <majority of websites on the internet> save for a few that want to be an _APP_"… :)
Agreed very much.
I'd extend this to "web apps that revolve around forms, views, filters and pagination" when it comes to "Ajax" stuff (yes, I'm old).
The part of htmx that's relevant to these topics being discussed here, I once wrote an inferior clone of, some years ago.
It was "isomorphic", tailored to our PHP-based CMS, and could handle filters, search forms, and pagination.
Suitable for forums definitely, and current PHP-based forum software vendors that are still on the market follow the same paradigm.
> Forum websites mostly deliver non-interactive content
I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things.
Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other people obviously like them.
Is that the kind of thing you'd be giving up as you move to a platform like HTMX?
Infinite scroll with htmx: https://htmx.org/examples/infinite-scroll/
It’s funny how hilariously simple that is and the parent commenter making it sound like you need a full JS framework for that instead.
It also doesn't actually work correctly - if you scroll too quickly it doesn't load more content. Possibly just a CSS issue on the example because the last row is not visible when scrolled to the bottom of the page due to the footer and its large margin.
I mean I'm not a front-end guy I was genuinely curious how well HTMX handles this kind of case.
I first learned about endless scroll in a Ruby on Rails meetup, where the presenter was showing how to craft snippets of HTML with ERB and using a bit of JS to insert them below the existing entries. It's definitely possible.
Maintaining a code path with a snippet for each possible viewing experience, back when REST was all the rage, was a bit obnoxious though.
Nope, HTMX could power endless scroll features if you want them
Yes but then you're doing HTMX not HTML and at that point why not use something that's more flexible. I'm saying this as a person who still maintains a small application done with Intercooler.js and is perfectly happy with it.
If you want basic interactivity, HTMX is fine.
If you want something more (like sortable) I'd reach for lit instead of adding the Sortable.js dependency, something the HTMX docs suggest ( https://htmx.org/examples/sortable/ )
And yes there are also some scenarios that you want to control the whole routing and rendering stuff, then go for Solid, React, Angular, Vue, whatever.
There is no golden rule to all of this but finding out what makes sense is a fun exercise.
I don't necessarily disagree that there comes a point at which you are working more against HTMX than with it. I think rather than measuring that contention point between HTMX and SPA/MPA in terms of interactivity I'd measure it in the amount of client side state and logic needed. If you need a bunch of client side state and logic, for example a digital audio workstation, then a SPA would definitely be the appropriate pattern.
But interactivity in largely content-driven sites doesn't necessarily preclude HTMX. You can do a bunch of fancy interactive stuff with HTMX and some minimal JS. Drag and drop sort is a tiny drop-in JS snippet. Skeleton loaders and spinners are supported out of the box in HTMX as is infinite scroll as others pointed out.
I'm not saying Next.js, Solid Start, Remix, Nuxt or some other hybrid server and client rendered model doesn't work for forum software. Or that even client only rendering can be a valid approach if you accept the trade-offs (no curl-ability). People should use whatever they feel productive building with.
But if your backend is already a non-JavaScript server rendered framework like Django then HTMX makes a ton of sense to add some interactivity.
I personally think that if you are adding a sortable component to a content-driven website, maybe it is moving away from being such a website. Normally a textarea should be enough for most people to order a "list" but if the list items have ids (they are entities), then that'd not suffice, and you may be going in the direction of a web application.
Otherwise, I'd recommend HMTX even if you have a super flexible JS backend.
That said, this is all baseless thinking without seeing any requirements and as I said before, trying to choose the right abstraction is the hard but fun part.
> There is no golden rule to all of this but finding out what makes sense is a fun exercise.
"Fun" as in you're years into a project before you fully accept that you made the bad call.
Well I also do not really know the legitimate use case for infinite scroll (other than trying to push gambling/slot-machine tricks onto your userbase).
I get lazy-loading for pages that contain a ton of media of which the user will likely only see a fraction. But some people seem to think infinite scroll is a good idea with text based content as well..
I'm specifically cranky about MS Azure Devops and how much lazy-loading and unloading of text it does. It's basically impossible to ctrl-F.
Also Github. Doing a review or searching logs is pain.
Yes! I suffer through this daily. It's atrocious.
> The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.
That's how interactivity has always worked.
Server-side render everything + ship interactivity via js on top of it.
I feel like most of the web developers forgot that React/Vue/etc solve a specific problem: single-page application.
This is a very narrow and specific problem: navigating from page to page not causing full page reloads.
But the web has changed since SPAs were needed in major ways:
1. the average device and connection is insanely faster than 10-15 years ago. Receiving and rendering content is not the problem it once was in the age of 2g connections and limited hardware mobile devices. Even the very low end phone from few years ago has nowadays 0 problems loading and parsing few hundred kbs of html and js.
2. Web technologies moved at all levels. Server technologies, cloud ones, browser ones. React and company are solving problems that barely belong to the modern web.
In short: today you can have an app-like, spa-like experience even out of fully server-side rendered applications. While also benefitting from shipping much less code to the client.
There's a very minimal amount of websites and applications out there that benefit, and aren't crippled by these rendering libraries: those that vastly leverage offline capabilities of the platform and want to keep working regardless of internet being available. I'm talking the notions and linears.
But bar from those, still working with this React slop is just not good for the user. Even multi billion companies hiring leetcode ninjas can't get acceptable user experience and performance out of those libraries, and it's not a coincidence: they keep forcing the wrong tool for the wrong problem.
They keep living in 2018 and at the end of the day the only excuse for those react/angular+tailwind slop is that there's an entire generation of developers that doesn't know anything else and has long lost any proper engineering skill (if there is any) in finding the right tool for the problem. This is a familiarity issue, not sound technical decisions. It's the "you can't go wrong with oracle/mysql/ibm", but actually you can, and it shows.
What's worse: it's incredibly cheap to experiment different solutions and approaches via LLMs in 2026, but people keep slopping the same monstrosities.
> the average device and connection is insanely faster than 10-15 years ago
Using the same reasoning, I’d come to the opposite conclusion. Devices are much faster than they were 10-15 years ago, but network latency is still roughly the same because physics limits how much it can improve. So reducing network round trips matters more than ever, which favors SPAs over MPAs.
I’m not sure I follow.
SPA’s tend to require more network round trips, sometimes significantly more based on the architecture.
But a lot of the time they can happen in the background where the user doesn't see them, or on a part of the page the user isn't currently interacting with, preventing it from being a stop-the-world interruption.
It’s in the name: an MPA requires a page roundtrip for every navigation, while SPA requires a single page roundtrip. Any subsequent requests are part of the application itself and can be handled without disrupting UX.
An MPA can make as many queries/service requests as it needs to to render the result. Most— the vast majority of SPAs I’ve ever written, maintained, or used— do that from the client, making many requests to render the new route.
The UX for an SPA can indeed be excellent, but the average SPA is worse than the average MPA, in my opinion. It’s just much easier to break things in many subtle ways in an SPA.
An SPA still requires roundtrips, just not to load the DOM root. Most of them do more than one roundtrip per navigation, making them worse than MPA. They also break loading screens.
They don't have to be that way.
They still are
One nice thing about using React even on the web is that it forces your Backend to be REST right from the start. Although I sincerely thing that is less important now with the explosion of LLMs. I've started thinking about everything as Display + MCP Server. Where a SPA front end is really just pre-defined display.
> One nice thing about using React even on the web is that it forces your Backend to be REST right from the start.
The creator of HTMX would disagree with you (as the person who described and coined the term REST)
https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
> React/Vue/etc solve a specific problem: single-page application
That's not true. They solve the problem of requiring separate code paths for interactive elements - one for initial render and another for updates.
Previously the server rendered the initial HTML and then client JS updated it after e.g. user clicks a button, but with React/Vue/etc., it's merged into one code path because HTML is derived from the current state.
> Even multi billion companies hiring leetcode ninjas can't get acceptable user experience
Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.
> Modern UX is bad because many front-end programmers fundamentally just do not care about the UX, it's not about the specific tech they use.
This is untrue and is weird misunderstanding on your part. Most of modern UX and UI is designed to fit the needs of the customer for the frontend team/dev: the product or marketing or sales department. The user of the website is very rarely the customer for the dev.
Only react "solves" that. In vue component setup only runs during mount. Update is not a thing in the way react has it.
The point is that there's only one template and DOM is derived from that template. This concept is the same in both Vue, React and other popular component-based UI frameworks.
> A Single-Page Application (SPA) is a web application or website that loads a single HTML page and dynamically updates its content as users interact with it, rather than loading entire new pages from the server.
That's the definition, I didn't made it up.
And those libraries solve that.
Your other definition, can be fully implemented server side, Elixir's Phoenix does that. But it's not the only one.
> That's the definition, I didn't made it up.
Your prior claim was that they only solve one problem, not about a definition. They solve several problems:
- less data can move over the wire compared to sending a full page every time (this is in your definition, and is definitely not always true, as sometimes REST APIs can return far more data than what's needed to render the screen)
- the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers
- you can write tests for your frontend, e.g. you can unit test components' behaviour and style in isolation
- the frontend can also work, or at least respond usefully to the user, when the network or the backend are not working
That second point is almost never true " the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers"
In a reasonably complex application, each interface ends up needing its own shape of optimized APIs. Otherwise the clients become very complex munging/reshaping data or making too many API calls, throwing away a lot of data etc.
You said, that React/Vue/etc. solve a specific problem: SPAs - that's not accurate. That's not the problem they solve.
According to what you said, CSS also solves the problem of making an SPA because you could "switch pages" by changing CSS class names on `body`. But if someone asked what CSS is you're not gonna answer "you use CSS to make an SPA", even though _technically_ you can use it to make an SPA.
I basically use HTMX for all my Web Apps, including PWA(s) that run as ~near native apps on iOS/Android. It's great! I aso pair this with DaisyUI+TailwindCSS. YOu really can't go wrong, there is something quite pleasant about writing your web apps in ordinary HTML with partials and the extensions that HTMX adds to the browser for SPA-like interactivity.
How does the PWA work offline with HTMX? The “hit the server for fresh markup fragments” approach seems like it has to be abandoned here, however simplifying it is for online apps.
It seems like the wrong tool for the job to me, but I was curious and thought about it a little:
After initial page load, a service worker could intercept all the HTMX app's AJAX requests, but it could only work with what's already cached. Using a lot of tooling like workbox the developer could pre-cache the entire app. (Would that mean no dynamic responses?)
Alternatively, implement the entire HTMX app in JS, build the app once for the NodeJS/Deno backend and once for the front-end. After page load, the frontend could take over.
Or something like that. It's a bit convoluted as PWA solutions often are.
I know that you can have a shortcut on the users phone home screen but I've run into a bunch of problems with that setup where hitting it multiple times opens multiple tabs etc.
Have you found nice workarounds for that?
You have to build a proper PWA with a fully formed manifest.json first off. Web Push (i.e: Push Notifications) are fully supported on both iOS and Android. The Only thing that doesn't work is "background" work (but preactically speaking I haven't really needed it).
If you'd like to find out how I build Mobile-first apps with Go, HTML and HTMX hit me up.
Any chance you could write a hello world repo of this stack and post a link here?
Try asking this question to an LLM. (No, seriously.)
Or to a search engine: https://share.google/dTJmGU38xw0kDSJlZ
Big fan of bDaisy and TW ...all thats missing is jQuery and Razor .cshtml to rock my 2026 mistersoft web stack. HTMX is very cool but $...
Happy they did this. Htmx is a great fit for server rendering - which in many or most cases is what you should do in any case. You can always put a mini VueJS or ReactJS app inside of a template for a very custom interactivity.
Putting ReactJS or VueJS for a little interactivity is hardly the correct approach. It makes no sense to bring them in for "a little". What made React and React-like (Angular v2, Vue.js) frameworks stabilise is that they're about the right abstractions and everything else for managing dynamic html converges to about the same thing.
Why not? You can have server side routing that returns the page and then react then takes over and hydrates a small part within the page or the complete page. A similar approach is used for the islands architecture, and you can even combine different frontend frameworks for maximum flexibility, e.g. developer preference. You can decide to load your frontend libraries lazily or as shared scripts so they are cached and only take up some bandwidth on initial load (a couple of kB minified and zipped).
In principle I agree that putting React or Vue in for a little interactivity is a bad approach, if the same can be achieved with Htmx, which it usually can.
However for some really complex mini apps, that's another story. But for the rest of those CRUD pages, you can go simple server side rendered.
"Complex mini app" is one hell of a concept.
It can be. Think something like a file viewer or a text editor, or a music players. You can probably make do with vanilla javascript, but there’s some threshold where using react to take care of the state<=>ui relationship is worth it.
A text editor or music player is hardly "mini".
Again, the issue with htmx is that it pretends like it is not a framework, when in fact, it is just a second attempt at angular 1.0, with even more naive assumptions about web apps.
> A text editor or music player is hardly "mini".
If it's a sub-function of a bigger ensemble that mostly dies something else then it's fine to call them “mini apps”.
For instance a bank app may contain a text editor for the internal messaging feature of the app, that would count as a min-app in that context.
Having adopted Angular 1 back when it was new, I can promise you it's completely different than Htmx.
What is the main difference?
Astro then.
That’s basically a massive hack. Every real world app will need enough js that htmx will require you to put js on front end and you’ll need to hack it together. Just like we did php+js 15 years ago.
I've found this to not be true at all. You can do quite a lot with just HTMX. Any client-side Javascript™ you strictly need can often be done fairly minimally with Locality of Behaviour (LoB).
LoB isn't going to reconcile Chat Messages rendering state and Notifications. Their dependent state by nature. HTMX largely seems to ignore this reality.
In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.
> In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.
Which makes it even more ironic that in the 10 years since React was announced in 2013 and when I quit Facebook, they never managed to fix the original state synchronization bug that they demonstrated in the original React announcement for more than a few months at a time at best.
I'm sure technically it wasn't a singular bug over the years and the causes were complex, but React did fuck all in relation to the unread message counter being correct.
> In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.
SSE is perfect for chat/notifications and is a lot simpler than syncing. The server pushes updates to the client doesn't require a sync. SSE is also more performant since it can keep the connection open. The example below is on a $10 vps last I heard.
https://data-star.dev/examples/dbmon
right, so use the right tool for the job. most apps are boring CRUD apps and dont support chat.
I think HTMX lacks a sensible way to do composition and reuse on the component level, something that react/vue/solid do extremely well. Since you are basically mostly swapping html content, it gets tricky if you want to reuse partials.
That "massive hack" is supposed to be one of the core features of React.
What I've found in practice is that HTMX is extensible enough that I can write a small amount of javascript to "put a funny plug on the end of HTMX" to talk to say Leafletjs if I'm drawing maps, and want things dynamically updated.
It works quite well, and saves me an awful lot of tedious mucking about with other stuff.
For what it's worth, Claude Code is really good with HTMX and with adding that glue logic if needed.
But it is different this time, we are going back to HTML! /s
I've been saying for years: All buildings should be parking garages.
Because you can always just put a mini residential building inside a parking garage if you need tenants.
Need an office? Just put a mini office in the parking garage. It's perfect.
Parking garage construction is so clean and simple. Other buildings are too complex! From now on, I'll only build parking garages.
(Then I guess you have the opposite example of the residence without the parking garage! It's a great place to live, but there's nowhere to store my things and park my car!)
As others mentioned, not great for rich interactivity.
Example: Render a scrollable list and you need to change contents of the li items mid scroll - it resets the scroll position to the top because of how it replaced the entire HTML on render. There are workarounds you can do, DOM hacks, but they aren’t ideal.
React is designed around that kind of thing. They do some funny magic under the hood to support seamless DOM reconciliation and things like prop drilling of entire components on the prop of another, and so-on. This gives them a more granular way to manipulate the DOM without total page re-rendering.
Next.js SSR works because it’s designed around React. So they’re giving you all the SSR stuff you want but you still get client-side React for rich interaction design and other SPA niceties.
So if someone releases an SSR-like thing like htmx it feels like something is missing.
Maybe htmx needs an opinionated framework that gets more into high performance rendering and state management.
Or maybe they hone in on the “basic web pages” market. Who knows, maybe those make a comeback somewhere. PDF gets replaced with standalone HTML or something, and people use HTMX, or maybe it’s used in a dev environment for HTML email design in some future where email can have events (who knows). Couple of ideas.
Right now it feel incomplete or has nowhere for me to plug it in. Love the concepts though, HTML/JS should have been like that.
I haven’t used it with htmx, but DOM morphing seems like it’s probably a good solution to this.
https://v1.htmx.org/extensions/morphdom-swap/
https://github.com/patrick-steele-idem/morphdom/issues/261
This issue is reporting the same kind of thing - text selection is lost on re-render
Replace React / Vue with HTMX 2 years ago and still going strong.
Hono + WebComponents + HTMX + serverless is the backend for my apps now.
What is the point of using HTMX if your backend is JavaScript(Hono)?
Adopting something like HTMX is primarily a UX choice, and the language you use to serve it is almost irrelevant to UX. JavaScript is a nice backend language. It’s fast, has a massive ecosystem, and many people know it well.
I don't see how HTMX has anything to do with UX. Could you clarify what you mean?
I used htmx but had to migrate to svelte for storybook for development, I wish htmx had that sort of tooling
Using Django w/ frontend frameworks has been a struggle for me. (I only dabble as a hobbyist.) I think splitting the backend off into a restful API makes the marriage work. I've looked at django-rest-framework (https://www.django-rest-framework.org/) and django-ninja (https://django-ninja.dev/). Of course,, then you're discarding a lot of batteries that come with the django framework. Perhaps using Django templates for admin / internal facing work only, and React for customer-facing sites can be a healthy compromise?
That's the architecture my B2B SaaS uses, except Vue instead of React. We deploy the SPA to a CDN and it feels snappy. Some clients access the API directly via OAuth. django-allauth is the other critical piece. Works great altogether.
This happened 3 years ago... wondering what makes it news worthy today?
We need a follow up, how this change panned out, how much did performance improve?
most people i know that bought into htmx went back to react after they couldn't manage the spaghettification
although i wonder if LLM changes things
i am interested in moving away from React but its also what LLMs know infinitely more of than HTMX
Archive link: https://archive.ph/bLu1Z
> A lot of pages in Misago are implemented twice: as Django templates and React.js components.
I think this tells all about the level of competence of these devs. That’s literally unmaintainable. So instead of fixing the problem and have a nice api + interface + ssr, they patch it up with a yet worse approach in htmx.
> there's a lot of forum software out there that still does the old way of rendering as much as possible on the server and using some JavaScript on client to improve its interactivity here and there. And people are happy with that
Yeah, server returns class xxx and jquery needs to target that. Once is out of sync silent bugs will appear. And will be many, not a few. No way to check at compile time.
MISAGO MONGO DJANGO BUN
WHY WILL NOT MY FORUM RUN
MISAGO MONGO DJANGO BUN
PERFECT CONFIGURATION
MISAGO MONGO DJANGO BUN
IF YOU ARE THE CHOSEN ONE
MISAGO MONGO DJANGO BUN
REWRITE MY APP AND MAKE IT RUN!
See, one of the great things about FlaskBB is that it doesn't have React.js to begin with.
But Misago sure does look good.
Great, now you can't offload your FE to a CDN.
But on serious note, htmx is basically a solution in the search of a problem. It is the new hype.
Or rather, a solution that overlooks 2 decades of learnings. Yes, for a small set of projects htmx is okay, but even then, where htmx is ideal, static is king, and once static is not good enough, htmx sooner or later starts to feel like the XAML and BPEL soap.
The fundamental problem is that it is pretending to be a declarative language while entirely imperative.
Sounds like you never worked on complex HTMX systems. They're easier to maintain, allow for easy caching of HTML fragments in a page. For higher traffic pages React just fails spectacularly.
How does React fail for high traffic pages? It is amazing that you would suggest I don't understand HTMX "systems" and then go make such assertion.
I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. I looked into htmx and it is very much a second attempt at angular 1.0, which I did use for some good half decade as that was the best option at the time, but sooner or later, you get sick of stuffing "little codelets" inside attributes all over the place, which is exactly what htmx does.
If you want to understand what htmx is going to look like at scale, look at angular 1.0 projects.
As someone who wrote a lot of angular back in the day, and who writes a lot of htmx in the current day... That comparison makes absolutely no sense.
The only thing the 2 have in common is the use of HTML attributes for functionality. Completely different on every other axis that matters.
It is different in that some of what happened on the frontend now happens in the backend, but overall, it is the exact same approach, so as I said in a sibling comment, it, it is just a second attempt at angular 1.0 with even more naive assumptions about web.
Based on skimming the couple sibling comments, I believe the issue you have had with htmx is precisely that you have somehow conflated it with angular. If you think they're the same, you will use them the same and have the same poor outcomes.
In another comment, you mentioned State Management. If this is on your mind then you are using htmx wrong. You should not be managing any client side state with htmx. State is on the server or in your database. Interactions on the client should immediately reflect the updated server state. If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework.
> If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework.
Yeah, because clients never need to keep track of state like which block is expanded or which tab is selected or that the previous page was or what the user is currently typing...
Angular being basically the same HTMX is nonsense and you should know better.
Say you have a huge Google Ads budget burning up on those landing pages. Make one version with React and one with HTMX. Open Lighthouse and see performance difference. First page renders are much slower with React. Page load is slower and this makes a huge difference in mainland USA where people are still on 3G speeds on their budget phones.
"High traffic" might be the simplified view here and it took me a few page memos to explain it to my lead but the gist is that React is slower, takes longer to load and most of what it is used for is easily done with plain HTML and sprinkles of JS as needed. Unless you're streaming sound or video like you do on Facebook pages it's really not the right tool for the job in a majority of cases.
The only nonsense here is ignoring that React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015.
The gist of it continuously seems to be that people who think HTMX Great, know very little about good frontend engineering.
If you really think HTMX and Angular 1.0 are equivalent then…actually I don’t even know where to begin.
Being a curmudgeon is not good engineering leadership. "Seeing everything" is just old people being wistful, not actually contributing or doing in the now. I deployed (via ftp) my first site before Netscape so I do understand where you're coming. There isn't at present a valid or detailed criticism of why X won't Y based on all of that supposed XP - so why mention it? Educate us - why will it fail? Is it because you never mastered CDN's or the exact opposite? It certainly doesn't lead any credibility the assertion that A will become Z because they look similar or embrace similar ethos.
You need to read things in the context, Chicken.
But I will answer your main questions since your comment seems to be in good faith.
Just like angular 1 choked on complex, high-frequency UIs, HTMX is going to follow the same faith. Github uses a similar approach to HTMX and you will find that even for such a simple system, their notification indicator elements on the same page are often out of sync.
The reasons for this is that State Management is hard, which is why the reconciliation loop of React-like frameworks and shadow-dom does away with pushing complex state management to user application and handles it systematically.
Of course, this doesn't mean htmx is useless, for a specific case of web apps, it is good enough, but the problem is that often times, you start with "specific cases" and your application grows overtime.
So when you consider that and the cost of doing htmx vs React or any react-like framework, picking htmx is only reasonable if it is the only option you're comfortable with and rarely on merit.
Why would react fail for higher traffic pages?
If it's a traditional React SPA, you can use a versioned bundle with immutable caching and each user only has to download your bundle when you release an update or they use a new browser. You will need to think about how you handle spikes in traffic when you do a release, but even then users won't all load your page immediately after you bump the version.
Most of the time (existing user using the same browser, no update) there will be precisely zero traffic to your servers to load the React app except for the initial HTML skeleton.
For an app using SSR it's more complicated and I'll admit I don't know how that works at very high load
I had landing pages using React on a 1.6M/m budget. The loading times on cell phones in mainland USA meant we had people cancelling the loading of pages. When we converted to straight up cached HTML we saw a huge increase in full page loads.
People weren't cancelling the page load and surfing back anymore. You cannot argue that React is extremely heavy and also adds a lot of time between first render. Test a normal HTMX page in Lighthouse and then convert it to React and you'll see how drastic things are.
People use React today out of habit rather than because it's the best tool for the job.
This just shows that despite the 1.6M/m budget, you did not have people who could do react correctly. React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015.
But while first render is of course important, now everything else is more expensive with htmx because you have to generate HTML on the server, on top of your usual fetch pipeline. Yes, for small traffic it makes little difference, but once you have >10k/s requests, things start to cost.
Yes but why bother with React, Hydrating pages at all if you can do something simpler? What advantages does React provide here?
HTMX tools are simpler while providing straightforward thinking around html fragment caching, whole page caching. React just gives a runaround way of doing everything. I'll remind you React was built so that people could continue watching a streamed video while they navigated on a page. Most pages aren't streaming anything.
Because "simple" is transient at best and a lie at worst.
But for more details, see the sibling comment:
https://news.ycombinator.com/item?id=49069477
What advantages does HTMX have? You end up with splintered spaghetti code, multiple languages/idioms, and unpredictable state.
> loading times
What does React have to do with loading times of a page? React does not contribute to that at all other than having to download the JS runtime, which with Preact is 3KB.
> You cannot argue that React is extremely heavy and also adds a lot of time between first render
Yes you can! In no world would React itself add enough render time to make people navigate back, even if running on a computer from the 90s!
For what it's worth, your last statement is why react always felt off to me.
This feels like an uninformed, generalized opinion from someone with zero experience on the topic. Have you even used HTMX or a similar approach?
Besides the memes, it is absolutely not hype-driven, but hypermedia driven. It asks the question: could HTML be even more powerful than it already is?
The creators of HTMX even want to standardize core ideas of HTMX into the official HTML specification: https://triptychproject.org/ Please read this and reply when you still think it's hype.
I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go.
Hypermedia is what to web apps what XML is to programming languages. We have tried HTMX as a concept many times over, there is nothing new here, and like everything declarative, sooner or later it will fall short and you're going to reach for escape hatches and what not.
And the features specified in that project is nice to have, in the same way that it is nice that we have Date Pickers or other advanced input features, but it is never going to replace React-like frameworks.
Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management, Google really really tried that with Angular 1.0, and we know it doesn't scale.
> Hypermedia is what to web apps what XML is to programming languages.
I have no idea what this means. The World Wide Web itself is quite literally hypermedia.
The fact that a lot of front-end frameworks appear hell bent on ignoring this fact doesn't make it any less true.
> Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management...
You may have stabilised on JSX, "we" have not. React is one way of building web applications. It's appropriate for a certain subset of highly interactive SPAs, and completely inappropriate for many other things.
> You may have stabilised on JSX, "we" have not.
Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%.
So I am not sure what "we" you are talking about.
> Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%.
I have no idea if that's accurate, but let's assume for a moment that it is.
- Vue supports JSX, but it is not the default.
- Angular does not support JSX.
- Svelte, which you neglected to mention, does not support JSX.
- Solid does indeed use JSX, as of course does React.
So two out of the five main SPA frameworks don't even support JSX, and another doesn't typically use it.
As I said, you may have stabilised on JSX, "we" have not.
This is ignoring the React Native and Flutter prominence on App Stores as well.
I miss vue2.0 =[.
JSX just feels weird.
> I have no idea what this means. The World Wide Web itself is quite literally hypermedia.
I think he's saying that the Web is hypermedia plus Javascript, rather than just hypermedia. Which means, from the standpoint of the power of hierarchy, that it's Javascript, which also happens to use some hypermedia. Even if you use only a tiny bit of a Turing-complete language, Turing-completeness defines what your system actually can do.
This makes the Web fundamentally awkward, because most of the behavior is defined by the hypermedia part, and users have inconsistent expectations for what happens when you break the illusion.
HTMX works by extending the illusion. JSX works by breaking the illusion earlier rather than later.
The creators of HTMX are combative, dismissive, and short-sighted. Keep them far away from any spec discussions.
> hot take > 70-day old account > relentless contrarianism
steer clear.