htmx began life as intercooler.js, a library built around jQuery that added behavior based on HTML attributes.
For developers who are not familiar with it, jQuery is a venerable JavaScript library that made writing cross-platform JavaScript a lot easier during a time when browser implementations were very inconsistent, and JavaScript didn’t have many of the convenient APIs and features that it does now.
Today many web developers consider jQuery to be “legacy software.” With all due respect to this perspective, jQuery is currently used on 75% of all public websites, a number that dwarfs all other JavaScript tools.
Why has jQuery remained so ubiquitous?
Here are three technical reasons we believe contribute to its ongoing success:
Now, that’s a ridiculous (and arrogant) statement to make, of course, but it is an ideal that we on the htmx team are striving for.
In particular, we want to emulate these technical characteristics of jQuery that make it such a low-cost, high-value addition to the toolkits of web developers. Alex has discussed “Building The 100 Year Web Service” and we want htmx to be a useful tool for exactly that use case.
Websites that are built with jQuery stay online for a very long time, and websites built with htmx should be capable of the same (or better).
Going forward, htmx will be developed with its existing users in mind.
If you are an existing user of htmx—or are thinking about becoming one—here’s what that means.
We are going to work to ensure that htmx is extremely stable in both API & implementation. This means accepting and documenting the quirks of the current implementation.
Someone upgrading htmx (even from 1.x to 2.x) should expect things to continue working as before.
Where appropriate, we may add better configuration options, but we won’t change defaults.
We are going to be increasingly inclined to not accept new proposed features in the library core.
People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed, and they should feel comfortable that the htmx that they write in 2025 will look very similar to htmx they write in 2035 and beyond.
We will consider new core features when new browser features become available, for example we
are already using the experimental moveBefore() API on supported browsers.
However, we expect most new functionality to be explored and delivered via the htmx extensions API, and will work to make the extensions API more capable where appropriate.
Our release schedule is going to be roughly quarterly going forward.
There will be no death march upgrades associated with htmx, and there is no reason to monitor htmx releases for major functionality changes, just like with jQuery. If htmx 1.x is working fine for you, there is no reason to feel like you need to move to 2.x.
htmx does not aim to be a total solution for building web applications and services: it generalizes hypermedia controls, and that’s roughly about it.
This means that a very important way to improve htmx — and one with lots of work remaining — is by helping improve the tools and techniques that people use in conjunction with htmx.
Doing so makes htmx dramatically more useful without any changes to htmx itself.
While htmx gives you a few new tools in your HTML, it has no opinions about other important aspects of building your websites. A flagship feature of htmx is that it does not dictate what backend or database you use.
htmx is compatible with lots of backends, and we want to help make hypermedia-driven development work better for all of them.
One part of the hypermedia ecosystem that htmx has already helped improve is template engines. When we first wrote about how “template fragments” make defining partial page replacements much simpler, they were a relatively rare feature in template engines.
Not only are fragments much more common now, that essay is frequently cited as an inspiration for building the feature.
There are many other ways that the experience of writing hypermedia-based applications can be improved, and we will remain dedicated to identifying and promoting those efforts.
Although htmx will not be changing dramatically going forward, we will continue energetically evangelizing the ideas of hypermedia.
In particular, we are trying to push the ideas of htmx into the HTML standard itself, via the Triptych project. In an ideal world, htmx functionality disappears into the web platform itself.
htmx code written today will continue working forever, of course, but in the very long run perhaps there will be no need to include the library to achieve similar UI patterns via hypermedia.
At the end of the intercooler docs, we said this:
Many javascript projects are updated at a dizzying pace. Intercooler is not.
This is not because it is dead, but rather because it is (mostly) right: the basic idea is right, and the implementation at least right enough.
This means there will not be constant activity and churn on the project, but rather a stewardship relationship: the main goal now is to not screw it up. The documentation will be improved, tests will be added, small new declarative features will be added around the edges, but there will be no massive rewrite or constant updating. This is in contrast with the software industry in general and the front end world in particular, which has comical levels of churn.
Intercooler is a sturdy, reliable tool for web development.
Leaving aside the snark at the end of the third paragraph, this thinking is very much applicable to htmx. In fact, perhaps even more so since htmx is a standalone piece of software, benefiting from the experiences (and mistakes) of intercooler.js.
We hope to see htmx, in its own small way, join the likes of giants like jQuery as a sturdy and reliable tool for building your 100 year web services.