After a year of using HTMX, I really like it and would encourage everybody to give it a try.
It's nice for:
- internal tools
- midly dynamic websites
It's not great for any web page you stay a long time on mobile on, though. I made a web app with it, and on my phone, you can't handle the fact the browser plays against you if you stay a long time with a tab open and goes in and out of the app. You really need a lot of control in JS for that.
Also: don't try to avoid JS using it. It's a mistake many people do, and that's not how you get the best out of it.
I regularly sparkle a little vanilla js or alpine in my htmx websites to make them nicer. And in some cases, I even have one lone page that loads a full vue/react because that particular section needs to be way more dynamic. It's not an XOR. You have now a whole spectrum of how dynamic and how much work you want to put in.
Sometimes, I don't write JS at all, but it's not a requirement.
Can you expand on it not being great for sites with long sessions? Why does that play into it at all, wouldn’t the tab just sit there and do nothing? Do you mean if you need interactivity when the user goes in and out of the page?
Unfortunately no, the tab doesn't sit there and do nothing.
Mobile browsers will do all sorts of optimization, such as interrupting the network, slowing down the vm, putting it to sleep, caching and uncaching things without letting you know, and without a predictable pattern.
If you use raw JS, you can deal with all kinds of errors manually, put in place recovery strategies, bust caches, etc.
With HTMX, you just get sluggish behavior, or no behavior at all in your page, and you don't know why.
Also like another person said, you expect your state to be the same, like the scrolling placement, but chrome might decide that no, you get a page refresh there, or you are somewhere else in the page on next switch.
In this particular app, I have a raw JS counter, which is updated on the client to make it snappy, and by htmx to keep it up to date with other modifications. But the counter will be off randomly because Chrome messes with it. So I had to manually put many rules to know it's out of sync, and request the sync at the right moment. But the sync may not happen because Chromes decided so. So I should try several times, with exponential backoff, differentiates the different reasons of failures and update the DOM manually while handling various interactions with other components.
At this stage, you are basically coding a lot in JS instead of getting the state from the server in HTML, so having VueJS + VueRouter + Pinia is going to be easier to manage, and you'll get more interactivity and optimistic updates on top.
It's not worth it. Right tool for the right job and all that.
It's mostly on mobile though. On Desktop, the HTMX app behaves perfectly.
Depending on RAM limitations, the mobile browser will kill the tab session. When the user comes back, it'll reload the page. But I don't see how this is different for htmx or JS websites.
He might be referring to the problem that URLs are not enough to get to a certain state, which you might run into when trying to share a specific view or when your browser heavily unloads your tab.
I found this to be the biggest issue when building my webpage, I wanted to have a link like /blog/foo, but what exists out there is just / and the documents at /blog and /blog/foo are just the small fragments that get loaded once you click your way through /
Ultimately I hacked around it by adding some js to every file beyond /, which redirected to / with some anchor, and having / restore the state through the anchor, but it doesn't look the same as regular links into a website (/#blog-foo vs /blog/foo)
In between being laid off and recently finding a new job recently, I worked my way through this book and built a website using htmx.
It was such a pleasant experience compared to the frontend work I'd been doing in react. I never felt like htmx got in the way, it just worked and I almost never needed to think about it. I spent all my time solving problems and learning CSS.
hello hn, i'm one of the authors of hypermedia systems
this is a book about how hypermedia systems work in general, and how htmx (augmenting the standard web hypermedia system) and hyperview (a novel mobile hypermedia) work specifically
it's available free online, or for purchase via kindle or hardcover
This is the first time I had heard of hyperview, but it seems like an interesting approach for some mobile apps. I really appreciated the chapters on it, thank you!
It's a really great library, allowing you to take advantage of native mobile features while keeping the deployment model of web applications. Technically, it's a much bigger achievement than htmx, in that Adam Stepinski, the creator, had to create not only a hypermedia format but also a hypermedia client, which I've come to understand is the really hard part of creating a hypermedia system:
No one appreciates this tide reversal back towards hateoas principles and semantic HTML more than me, but why does it always come with prescriptions to adopt some new tech? You can implement all this stuff using literally any framework from the past 15 years if you want.
The book starts out with a history of hypermedia, a deep dive on the components of a hypermedia system and then a Web 1.0 style application built entirely in Flask. It then incrementally improves this with htmx, because htmx extends HTML in a specific way: it generalizes hypermedia controls. It considers how to integrate scripting and JSON APIs into a hypermedia driven application. It then showcases Hyperview (https://hyperview.org) a novel hypermedia system for mobile application development.
You can't implement things like infinite scroll or active search in plain HTML because plain HTML only supports hypermedia exchanges based on two hypermedia controls, links & forms, with two events, clicks and submits, and your target options are limited to the current window, an new window, iframes and a few other obscure options. htmx generalizes this, allowing you to implement more dynamic user interfaces within the hypermedia paradigm.
The unique and very special aspect of HTMX's approach is that it changes just 4 things in browser behavior (list from the Hypermedia book):
- Any element should be able to make HTTP requests
- Any event should be able to trigger an HTTP request
- Any HTTP Action should be available
- Any place on the page should be replaceable
The default behavior of browsers (without HTMX) is that only A and FORM tags can make requests, only GET (A,FORM) and POST (FORM) HTTP actions are available, only click can trigger a request, and only the full can be replaced.
By changing these 4 things, it opens up a huge range of possibilities, but requires learning very few new concepts. And it also lets you work in whatever language you're most comfortable with -- you don't generally have to use JS (e.g very useful for data scientists, who generally know python).
The changes you're describing are already here in standard HTML + JS.
Every element can be replaced with custom Web Components that can cause requests. Content can be partially displayed with just a click, tap, keypress, etc. and it doesn't even require scripting!
There are over 200 extant discrete methods that can be used to send network requests in web applications running in modern browsers.
It's a shame that the list is in that order (both on the htmx website and in the book). Items 1 and 3 are simply not important, whereas 4 is by far the most important feature that HTMX offers.
The downside being, naturally, that every single interaction requires a separate round-trip HTTP request, and a web backend that is far more stateful/sessionful than would otherwise be necessary.
To some extent I can see the appeal for rapid prototyping, especially for those less familiar with JavaScript. In a production environment- especially a bandwidth-limited, high-latency environment like a mobile device- it incurs an outrageous overhead on end users and server resources for that developer convenience.
Yes, and htmx is basically intercooler.js with jQuery ripped out and some attributes renamed. Intercooler.js is one of these 'framework[s] from the past 15 years' that you referred to.
Feels like a missed opportunity that the online version of the book isnt a demo of hypermedia in itself? Maybe a serious student of htmx could (as a learning exercise) transcribe the book from asciidoc into htmx? :-)
Besides technical merit [1] in this era of tech hypes, manias and virality it helps to engineer some gee-wow moments... 2 cents.
[1] (that htmx and friends definitely have, reminding us once again that "any fool can make something complicated but it takes a genius to make it simple")
When I look into the website source of the book I just see static HTML and CSS as well as a few media queries. Why would you want to use htmx to serve a completely static website?
Because many usage examples could be "live" as you go through the document learning about htmx functionality. Seeing is believing. The very same htmx-enhanced html pages deployed statically would (presumably) fall back to something still readable.
Ofcourse there might be valid reasons to choose to deploy statically using adoc (reusing for pdf, minimal maintenance etc.) but my point is about maximizing the impact.
I found Hypermedia Systems to be useful. Bought the hard copy as support/thank you to the authors, but the entire book is free online at hypermedia.systems. The documentation & essays on htmx.org further explain what you see in the book.
htmx is a straightforward, simple-to-implement javascript library that brings HATEOAS to the top of your development mindset. You can disagree with the HATEOAS philosophy, but the reasoning and purpose of the approach is clearly and professionally explained by the authors.
Yes, the gorilla marketing on x.com may rub some the wrong way, but frankly, it's fun. Humor and a useful product, with a deep rationale & good documentation, are wins in my book.
HTMX is not perfect and there are many situations when you probably don't want to use it, but I think it should be considered the default answer to the question: What framework should I learn to build a dynamic frontend?
At the moment the answer to that question is "react" and while react can be cool (I've heard) it has developed into a complex world that requires quite some time to master. Even intuitive JS frameworks like Svelte have been getting a lot bigger in order to be more feature complete.
HTMX is the Pareto answer to building dynamic frontends. It will be great for 80% of all projects that require interactivity while doing that job in 20% of the complexity that react would bring.
Is HTMX a legit solution for single-page applications? Feels like you just move the complexity to the server side. For example, the server side code for a simple TODO app is a massive programming project as seen in this repository:
Readit News
This book is the missing tutorial, and it's been very useful to me. It even lead to the "A little taste of HTMX" series (https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1).
After a year of using HTMX, I really like it and would encourage everybody to give it a try.
It's nice for:
- internal tools
- midly dynamic websites
It's not great for any web page you stay a long time on mobile on, though. I made a web app with it, and on my phone, you can't handle the fact the browser plays against you if you stay a long time with a tab open and goes in and out of the app. You really need a lot of control in JS for that.
Also: don't try to avoid JS using it. It's a mistake many people do, and that's not how you get the best out of it.
I regularly sparkle a little vanilla js or alpine in my htmx websites to make them nicer. And in some cases, I even have one lone page that loads a full vue/react because that particular section needs to be way more dynamic. It's not an XOR. You have now a whole spectrum of how dynamic and how much work you want to put in.
Sometimes, I don't write JS at all, but it's not a requirement.
Mobile browsers will do all sorts of optimization, such as interrupting the network, slowing down the vm, putting it to sleep, caching and uncaching things without letting you know, and without a predictable pattern.
If you use raw JS, you can deal with all kinds of errors manually, put in place recovery strategies, bust caches, etc.
With HTMX, you just get sluggish behavior, or no behavior at all in your page, and you don't know why.
Also like another person said, you expect your state to be the same, like the scrolling placement, but chrome might decide that no, you get a page refresh there, or you are somewhere else in the page on next switch.
In this particular app, I have a raw JS counter, which is updated on the client to make it snappy, and by htmx to keep it up to date with other modifications. But the counter will be off randomly because Chrome messes with it. So I had to manually put many rules to know it's out of sync, and request the sync at the right moment. But the sync may not happen because Chromes decided so. So I should try several times, with exponential backoff, differentiates the different reasons of failures and update the DOM manually while handling various interactions with other components.
At this stage, you are basically coding a lot in JS instead of getting the state from the server in HTML, so having VueJS + VueRouter + Pinia is going to be easier to manage, and you'll get more interactivity and optimistic updates on top.
It's not worth it. Right tool for the right job and all that.
It's mostly on mobile though. On Desktop, the HTMX app behaves perfectly.
Depending on RAM limitations, the mobile browser will kill the tab session. When the user comes back, it'll reload the page. But I don't see how this is different for htmx or JS websites.
I found this to be the biggest issue when building my webpage, I wanted to have a link like /blog/foo, but what exists out there is just / and the documents at /blog and /blog/foo are just the small fragments that get loaded once you click your way through / Ultimately I hacked around it by adding some js to every file beyond /, which redirected to / with some anchor, and having / restore the state through the anchor, but it doesn't look the same as regular links into a website (/#blog-foo vs /blog/foo)
It was such a pleasant experience compared to the frontend work I'd been doing in react. I never felt like htmx got in the way, it just worked and I almost never needed to think about it. I spent all my time solving problems and learning CSS.
Thanks for writing the book and making it free!
this is a book about how hypermedia systems work in general, and how htmx (augmenting the standard web hypermedia system) and hyperview (a novel mobile hypermedia) work specifically
it's available free online, or for purchase via kindle or hardcover
hope people find it useful
https://htmx.org/essays/hypermedia-clients/
You can't implement things like infinite scroll or active search in plain HTML because plain HTML only supports hypermedia exchanges based on two hypermedia controls, links & forms, with two events, clicks and submits, and your target options are limited to the current window, an new window, iframes and a few other obscure options. htmx generalizes this, allowing you to implement more dynamic user interfaces within the hypermedia paradigm.
By changing these 4 things, it opens up a huge range of possibilities, but requires learning very few new concepts. And it also lets you work in whatever language you're most comfortable with -- you don't generally have to use JS (e.g very useful for data scientists, who generally know python).
Every element can be replaced with custom Web Components that can cause requests. Content can be partially displayed with just a click, tap, keypress, etc. and it doesn't even require scripting!
There are over 200 extant discrete methods that can be used to send network requests in web applications running in modern browsers.
To some extent I can see the appeal for rapid prototyping, especially for those less familiar with JavaScript. In a production environment- especially a bandwidth-limited, high-latency environment like a mobile device- it incurs an outrageous overhead on end users and server resources for that developer convenience.
There’s nothing special about it other thab doing pretty much exactly what you’d want.
Do you want to do that? I'd rather use what other people have done
Besides technical merit [1] in this era of tech hypes, manias and virality it helps to engineer some gee-wow moments... 2 cents.
[1] (that htmx and friends definitely have, reminding us once again that "any fool can make something complicated but it takes a genius to make it simple")
Ofcourse there might be valid reasons to choose to deploy statically using adoc (reusing for pdf, minimal maintenance etc.) but my point is about maximizing the impact.
htmx is a straightforward, simple-to-implement javascript library that brings HATEOAS to the top of your development mindset. You can disagree with the HATEOAS philosophy, but the reasoning and purpose of the approach is clearly and professionally explained by the authors.
Yes, the gorilla marketing on x.com may rub some the wrong way, but frankly, it's fun. Humor and a useful product, with a deep rationale & good documentation, are wins in my book.
At the moment the answer to that question is "react" and while react can be cool (I've heard) it has developed into a complex world that requires quite some time to master. Even intuitive JS frameworks like Svelte have been getting a lot bigger in order to be more feature complete.
HTMX is the Pareto answer to building dynamic frontends. It will be great for 80% of all projects that require interactivity while doing that job in 20% of the complexity that react would bring.
https://github.com/guilycst/go-htmx-todo-list/blob/main/inte...
More importantly, quite often the complexity is duplicated for both front end and back end.
https://news.ycombinator.com/item?id=34134545