hi there, as many of you know, i am the creator of htmx and I'm happy to answer any questions about it
htmx has seen a surge in popularity, triggered by a video by fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) and a series of videos by ThePrimeagen, a popular twitch streamer on it
hacker news readers might be interested in the essays I have written on htmx & hypermedia in general here:
while I am a fan of htmx, obviously, I think the deeper concept that it touches on is hypermedia, which is a worthwhile idea for people to explore even if they don't plan on using it in day-to-day programming.
There are also lots of other great hypermedia-oriented libraries worth checking out such as Hotwire from 37signals, or, my favorite after htmx, https://unpoly.com
I remember few month ago I was making a post liking system, before htmx, I had to use jQuery to fetch the json api server and update the like count, but with the use of HTMX, oh boy it was like I was just writing plain html along with my django logic.
This is one of the greatest thing I've found.
Also, handling forms with HTMX is also very easy.
HTMX really improve both user and developer experience.
I've also found htmx a great way to retain server side rendering with minimising the recalculation cost of client changes.
By avoiding needing to add lots of client side logic to still get very low latency updates, it's given me the best of both worlds.
The way Django's template system works also makes it so easy to render a full page initially, then expose views for subcomponents of that page with complete consistency.
On a tangent, Django's async support is still half-baked, meaning it's not great for natively supporting long polling. Using htmx to effectively retrieve pushed content from the server is impeded a little by this, but I slotted in a tiny go app between nginx and gunicorn and avoided needing async he'll without running out of threads.
The other day I wrote an htmx extension for aws api. You could describe an element using the common htmx tag such as for confirmation, triggers etc, but the ajax fetched any aws object like ec2 instances, pipelines, whatever. It's awesome!
and it will just work with any params such as form inputs or hx-vals etc
the reason i haven't posted it yet is i want to find a good way of mapping parameters since the aws api can have some notoriously complicated parameter formats
I think HTMX makes alot of sense for content that is a bit static but still needs some update and interactivity. Im building a job site right now and using htmx for job postlistings, search etc. And liveview for logged in view of creating and managing job posts.
For those curious, here's some numbers for the last 6 weeks to put things into context:
- 4147 new stars
- 86 new contributors
- New contributors account for most of the commits and issues created which is a very strong sign of growth. Even in very popular projects, it is usually existing contributors that contribute most of the code.
we've had a new person come on the project who is focused on auditing PRs and getting the good ones in front of me, which helps a lot w/ getting new contributors in
This is a great project, and reminds me a lot of where folks saw hypertext going many years ago.
I have read a little of the website and picked through many of the online examples. One thing I did notice is the preference to update client state (DOM rewrites) based on server HTTP request responses containing full-blown markup. Does the HTMX framework provide concessions for client-side-only triggers and client generated content?
The reason why I ask is that an advantage of the current crop of JS heavy-client frameworks is they offload as much work to the browser as possible. This can result in less resource use on the server end (e.g. data, CPU), which is a big deal for web-scale apps. Is HTMX able to meet these kinds of engineering goals or is the project intended to do something different entirely? I totally get that something like a Facebook client is not at all hypermedia oriented, but folks are going to draw the comparison anyway.
however, I would encourage most folks to use HTML as the network format: it typically isn't much more CPU to generate the equivalent HTML string that corresponds to a JSON string (sometimes even less, as with tables)
for pure client-side, htmx is largely hands off. We support an `hx-on` attribute to address the fact that HTML doesn't support general `on*` attributes, but that's it
it does, however, emit a large number of events that you can hook into to extend things:
Another benefit of using HTML is ease of progressive enhancement. If the default behavior of the server is to render a full HTML page, anyone hitting that URL directly will get the full HTML from the server with no additional back-end work. Additionally, if JS is disabled in the browser, links still work as traditional links.
Mobile phones have less powerful CPUs. Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server (where you already have it loaded into memory anyway).
I always see these claims but isn't network the more limiting factor?
Or do people study this while thinking about IoT which may use more limited resources while still relying on the internet?
Especially since a server has to handle multiple request concurrently, it doesn't seem to be remotely the same workload that a single device CPU would see anyway?
I can't speak to any kind of general principle here, but viewing any standard modern web page e.g. Twitter, Discord in a Web browser reliably takes more CPU and memory than running a late-game Factorio save.
I will allow that it is probably theoretically possible to do client-side rendering in a CPU-efficient way, but it sure isn't the standard.
I'm not the GP but I'd say it's not "just" doing that render-blocking work on a single thread on a potentially under-powered mobile device, it's also introducing significant latency to fetch, parse and execute the code that will render to the DOM.
JavaScript is single-threaded, so whatever CPU work is going on will compete with the UI responsiveness. Even mobile apps, which run a dedicated thread for each, probably won't do one single clean UI update in response to the server-response.
It's not enough to be a novel approach. It also has to be demonstrably better from a performance standpoint, a developer experience standpoint, or arguably both.
Frameworks like SolidJS and Svelte simply got rid of the virtual DOM and reaped massive performance wins from it. I find it hard to believe that adding a worker and a virtual DOM back would end up making them faster. Quite the opposite in fact.
Then there's the dev experience. Would it be easier for a developer to work out what to do in a separate thread and post messages back into the UI thread? Seems like extra cognitive overhead to me.
Ideas are great. They move the state of the art forward. But if your idea doesn't comport with positive results from testing, it's not useful. Intriguing, to be sure, but not useful.
Very fair assessment, though not everyone is using, or will use, Svelte or Solid. Including people who are using htmx.
I meant to suggest that frameworks might be able to take this approach internally and make the DX transparent. I actually had a go at this using Mercury back in the day, but didn't have the motivation to finish it properly.
I just had a fresh read of the docs and htmx is refreshingly, gloriously simple--such a breath of fresh air. So natural, self-documenting, and well thought out. It _does_ feel like a natural extension of html.
To me, the only "missing" piece of htmx is a component model, but for anyone looking for that, htmx would pair amazingly well with Astro[1] which allows you to define and use html components without the runtime overhead of say Vue or React.
Not sure what you mean by html components. That's kind of missing the point of HTMX, no? Most backend frameworks like Django or templating engines like Jinja2 have the concept of blocks or fragments so its easy to render out component pieces to send back to the frontend. If you combine that with the OOB options in HTMX and/or the Hyperscript or Alpine libraries, then I'm not sure what you would gain by using Astro.
I mean, I just don’t think you should have to have Django for a simple website. Astro is an alternative to those backend frameworks. It’s a backend framework itself in many ways.
That's a great video explaining the core use-cases of htmx in 100 seconds. Would be great if all projects had such a thing! Htmx reminds me of tailwind in that you've created a set of attribute names and values that are picked up at runtime by a singular library. There's no front-end build required, which is a Very Big Deal for most devs who don't want (and shouldn't have to) to mess with npm and webpack. It looks like the "breaking point" for page size is something like a small SPA - when it gets to big, make another SPA.
Particularly for react/vue devs I think the thing they'll miss is the idea of a uniform, singular object representing global state that is rendered by a single function (defined hierarchically in your component codebase) into the UI. However, it must be accepted that this idea is very demanding in itself, resulting in lots of opinions and hurt feelings, and in addition comes with the weight of a front-end build (and all the confusing variation there).
I don't use it but I'm already a big fan. Congrats!
One minor thing. This is not an issue directly with htmx, but more on the backend. This always feels clumsy for me:
I land on the index page, and get the full site, then click on about page, and now htmx swaps the content for the about page. However if i refresh the url stays the same, but i now only get the content without the container.
I know this can be solved with checking for a htmx header, but i feel like "there must be a better way" like raymond httinger of python fame has said multiple times.
i typically have a middleware component that decides whether to render the "chrome" around a given response, so my controller methods aren't junked up with it
You make two skeleton templates: One for full documents, one that has nothing in it except the parts that change (say, the meta > title, the body > main and the body > header > nav parts) each wrapped in a hx-swap-oob.
In general, out of band swaps are really, really convenient for non-hierarchical layout relationships.
This can be solved by returning the full about page always, but swapping only the content part of in the index page by selecting which element to swap from the requested page. Htmx supports it
That's interesting. I discovered Unpoly after HTMX (which I like) and decided to stay with Unpoly for a few reasons. Do you think hypermedia libraries will converge or do you think there is space for different interpretations ?
i definitely think there is room for multiple implementations
unpoly is higher level than htmx, with different design sensibilities and concepts like 'layers' (https://unpoly.com/up.layer) which is something that doesn't make sense from htmx's "just extend HTML" perspective
Just wanted to say thank you for what you do. I've long been a fan of HATEOAS and I'm very happy that there's finally a movement towards it and ecosystem growing. Also, the memes are unparalleled.
Adam Stepinski, the creator of Hypreview, built it after his experience with intercooler.js, the predecessor to htmx. It is a very interesting piece of technology and, through the magic of HATEOAS, allows you to update your mobile app instantly for all your users, without dealing with the mobile store!
There is an entire section on Hyperview, written by Adam, in part three of our book:
Looks cool but it seems it requires React which makes it a lot more difficult to use than regular HTMX. Form the GitHub repo: “More importantly, the client is designed to be incorporated into an existing React Native project”
Do you think that at some point in the future, browsers could bundle in htmx or something similar, and that we could imagine web pages that have javascript disabled but with great interactivity due to htmx? This could perhaps be used as a security feature.
Thank you for all your hard work put into htmx and indeed promoting hypermedia driven applications!
Since htmx works by way of custom attributes, can you write a bit about a11y recommendations for developers using htmx? It would seem to me that a lot of things that we get from using standard attributes are lost, and we’d need to do more nuts-and-bolts type work with regards to dom structure and aria attributes. Or does the htmx engine deal with this to generate relevant aria attributes etc.? I couldn’t find any references to this in the documentation.
Hi, I've been skimming over your book. There might be a typo under [1], where you write: "An HTTP response to this htmx-driven request might look something like this", but then the next figure's header is "JSON"
As someone relatively new (few months in) to full-stack development, what can HTMX offer me? I've been semi interested since Prime mentioned it a handful of times, but I feel maybe I'm too new to fully understand what I gain from it. As soon as I'm finish with my current project, I'd like to check it out.
For reference, I'm currently working within the T3 Stack.
HTMX is just a convenient way of handling user-initiated UI updates AJAX calls (for whatever purpose). So instead of writing some JavaScript that looks for a specific element to attach an `onclick` event and subsequently makes an AJAX call then again searches for an element on the page to update with the result you can put some (very simple) HTMX code in the HTML directly and it'll handle that sort of thing automatically; "without having to think."
It's just a nice, convenient way of handling such things. The argument in the article is that "this is how HTML should've been from the start" because it lets you do some pretty sophisticated stuff just by adding some simple/intuitive attributes to the HTML.
So my apis need to return html specific to the page its called from with the data embedded? I guess my apis would need different endpoints that return json for other clients. And different endpoints for the exact same data if they need to be displayed differently? It just seems like a bad thing to couple. What about CSS? I guess you have to look at what the server returns to figure out how to select/style it.
I recognize thats how templates work but for some reason it seems weirder when applied to the element, rather than page level.
In there book, the authors specify that it is valid and normal to have additionnal endpoints for json. For exemple, Mastodon provide html endpoints as a interface for the user's browser, but also json endpoints for other clients (mobile app, cli tools, or others web app providing an alternative ui)
Stupid question, why doesn't htmx parse the response html and extract from that the relevant data out needs to fulfill the configuration? Feels a bit cumbersome to return the exact part of the response on server side, like the next page of the table, if it was requested with htmx, else return the full page.
This way htmx would be even easier to implement in any front-end.
Rails does this with Turbo Frames [1]. When clicking a link that is contained in a <turbo-frame> element, the frame is automatically replaced if the response contains a frame with the same ID.
How do you organize a backend for a htmx based frontend? Specifically getting templates that serve as reusable components, but also endpoints (there is some proliferation of endpoints which I remember from my days with ASP.NET MVC partials.
So you start by just re-sending the entire page but with content changed. Generally you'd use query parameters, like say you have a page with a table and you need to sort it. Add to your query parameters what order you want them in, re-render the whole page.
Then once you've got it figured out you just return the part of the template that you actually need to. Makes sense when you think of it as a progressive enhancement on a plain html page.
I don't think the bundle size will shrink too much, especially if we include the morph-style merge, which is somewhat complicated
yes, I think you could do a stripped down htmx that doesn't support a lot of the stuff htmx does, particularly life cycle events and more elaborate swapping mechanism
for example, most response headers could be just done as the HX-Trigger response header + some client side scripting
history support and form-value gathering is likewise a source of complexity and code that could be omitted or done less completely
Sounds like reasonable places to strip out stuff while keeping the fundamental features. I think the history support would be important enough to keep though.
Maybe stupid question, but what are the downstream implications for folks like Vercel/Netlify/etc. who bet the farm on complex server rendered JS pipelines?
i don't think there are major implications: the web development world is still very react/javascript/JSON-centric
there is no reason that they can't tweak their services to be more hypermedia friendly if and when this approach becomes more popular
netlify (which offers free hosting for https://htmx.org, so is a sponsor of the project) is very HTML/hypermedia friendly as far as I can tell, and I don't have enough experience w/ vercel to say much other than a vague sense that they are extremely react-oriented
no reason that can't change as the market changes though: hypermedia pushes the main value locus of applications back on the server side and so server-side companies should like that
Guillermo Rauch is the ceo of vercel. In this tweet, he's effectively saying that the bulk of what his company was built upon (SPAs) is bullshit (zero interest rate phenomenon is a reference to when financial interest rates are very low/zero, as they've been for many years, all sorts of things will seem great and successful because you can borrow money for free. When rates go up, only actually viable projects will survive - as we're seeing in the startup world now).
can htmx work for restful backend that requires client side rendering and routing? my understanding is that htmx only fits for server side rendering such as Django.
HTMX pulls text from your backend, so normally folks serve HTML snippets... but you could have a bit of js that takes JSON and turns it into HTML in the browser, and HTMX will pull the JSON (or any other text) into the browser, so you could still use it with a JSON api, if you wanted to
I use DRFs renderrers so my Django backend can render either JSON or HTML, so my API is still "restful", it just serves HTML to clients that request HTML like browsers with HTMX and JSON to other clients that request JSON.
interesting,using DRF for json and Django for html at the same time for browser and nonbroswer clients.
my use case is embedded systems that can typically do client side rendering in browsers, the only server side rendering I can afford is some simple lua or c/c++ mvc alike backend,Django is too 'fat' on resources. there are some of them but none that is great and actively maintained as far as I know.
You mean "This just won't die"? Because it seems to me that Web Components are here to stay, especially since something like htmx boosts their functionality with absolutely minimal added cognitive load.
I feel that, pretty soon, the choices for a full-functioned web application that is easy to maintain with high development velocity is going to be:
1. Master HTMX and Web components in a day, and be productive
Or
2. Spend a month learning React, and still get hit by all the footguns.
Thank you, reading now - do genuinely want to know. I understand how my message came across, but I do intentionally reflect how many attempts there have been to change the paradigm so far.
Not a valid excuse, dude. You have every right to be skeptical or to avoid "bleeding edge" but to assume the whole thing is just a front to raise someone's speaking/blogging/social media profile, to buzz in from nowhere and start off by declaring that it's going to "die" is not the way to act if you "genuinely want to know."
Recursivedoubts has legitimately demonstrated he's not a one-trick pony (previously built intercooler, concurrently building hyperscript) and he deals with skeptics like yourself dozens of times every time an HTMX article gets posted on this site (which all seem to go to #1, if that serves as an indicator of the library's popularity). He handles himself with grace and patience and humor, far better than most of us would do.
You don't even state what your "current approach" happens to be in order for him, or anyone else, to provide you with a satisfactory answer.
no problem, i try not to take things personally online: i've said plenty of things that either were mean or came across as mean in my life, especially when I was younger
i think one of the strengths of htmx is that it isn't really trying to change the paradigm to something brand new, it is instead going back to the original web paradigm of hypermedia and asking how HTML could have advanced within that paradigm, in contrast with the SPA paradigm that replaced it
so less of a wild bet, with more known advantages and disadvantages
htmx has seen a surge in popularity, triggered by a video by fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) and a series of videos by ThePrimeagen, a popular twitch streamer on it
hacker news readers might be interested in the essays I have written on htmx & hypermedia in general here:
https://htmx.org/essays
and in a book I authored with a few other writers that we recently released on hypermedia, htmx and a mobile hypermedia called Hyperview:
https://hypermedia.systems
while I am a fan of htmx, obviously, I think the deeper concept that it touches on is hypermedia, which is a worthwhile idea for people to explore even if they don't plan on using it in day-to-day programming.
There are also lots of other great hypermedia-oriented libraries worth checking out such as Hotwire from 37signals, or, my favorite after htmx, https://unpoly.com