One of the happiest days of coding in the last 10 years for me happened in September last year when I added htmx to an internal self serve web app I develop for our company. With the addition of maybe 5 htmx attributes I was able to delete about 500 lines of client side JS.
The app is now chock full of htmx interactions and has very little client side JS for the size of the app and it’s a joy to work on.
Without htmx I would not be able to turn around features as quickly as I do for the wider team so thank you, thank you, thank you.
I’ve been in web dev for 20 years and this feels like what we should have made all along.
The one area I would like to see some development is the file upload experience, I’ve had to do something a bit weird to get htmx and dropzone playing nice.
You deleted 500 lines of JS and added 44KB of (minified) HTMX. Better use HTMZ, which is only 166 bytes (sic!) and provides most of the interactivity: https://leanrada.com/htmz/
It was all normal JS code to handle a complicated form we have on a customer facing portal page. By moving to htmx I was able to rely on the server side to handle basically everything with only a small addition of code to what it was already doing.
this isn't much of a feature upgrade, but we took the opportunity to clean up a few things and drop IE support, which will help us slim down the library over time
hopefully it's an easy upgrade for most htmx users, upgrade guide is here:
As someone that has long since soured on frontend things despite having tried everything from the start - mootools, jQuery, backbone.js, SproutCore, Ember, React, Vue, etc.
I genuinely think htmx is the only one I have liked even after I built something substantial in it.
To me that is big, to be able to walk away from a significant amount of time with something and say "yeah! I want to use that again!" instead of some variant of "it's the least bad option" is both rare and cherished so thanks for all the hard work.
Not a question, but I just wanted to say that HTMX is a joy to work. I’m using it in production to slowly replace VueJS wherever full SPA interactions aren’t needed, and it has made development so much simpler. HTMX is such a breath of fresh air from the over-engineered jenga tower that web dev has evolved into over the past decade.
Are there any efforts to push functionality like this into the HTML standard? It would be nice if htmx eventually became unnecessary as browsers implemented it, and the work you're doing with proving it out in the wild seems like a crucial part of that.
No question but I wanted to say, I was pulling my hair out trying to figure out which js framework was less of an overkill, and finding htmx was pure joy
Have you considered replacing xhr with fetch? I believe it would allow htmx to be used in even more places. Fetch can be hijacked so returning data to the htmx framework isn't limited to the network. You could "run" a server in the browser or have a native app render HTML as well.
Perhaps, there's already a good way to hijack xhr that I'm unaware of too.
yeah, looked at it, unfortunately fetch() and xhr have a non-intersecting set of features (in particular, upload progress for xhr) so we decided not to touch it
i may restructure the internals to allow for mocking out responses using events, it comes up, especially w/ extensions
Hey Carson! I'm using HTMX on quite a number of internal tools. It's completely revolutioned the way we've done things, especially coupled with Django. Extremely grateful for your work - you're a net positive for humanity.
Oddly specific. Why implementing "forEach" and "toArray" instead of using the functions from Array.prototype? [1] I can see `Array.from` used elsewhere on the code.
As for slimming down over time, HTMX 1.0 was 26KB minified, now version 2.0 is 48KB minified. Why has it blown up by 184%, when it dropped IE support? Why don't keep it lightweight? Compare it with e.g. Petite Vue, which is 16KB minified.
i think that the better web components support blew is up a little. there is a reasonable amount of fat we can cut around IE support that is still in there, planning on doing so over the next few months & slowly
17ms over emerging 4G (and hopefully cached forever after that) doesn't freak me out too much
HTMX is like a glimpse into the road not taken, where HTML is the main language of the web instead of JS. Sometimes the grass really is greener on the other side, and I hope as an industry we make the switch.
My cynical take: this is by design. Those web committees are staffed by companies that each have their non-web platform they're pushing (or were, until it died, see Microsoft), so even the most well meaning members are somehow contorted into compromises that make the web as a platform a bad technical choice in terms of actual design, but the best one in terms of flexibility and of course ubiquity.
It's completely stupid HTML, by default, doesn't have basic controls found in EVERY UI toolkit since circa 1980. The standard examples being ListView and TreeView.
> It's completely stupid HTML, by default, doesn't have basic controls found in EVERY UI toolkit since circa 1980. The standard examples being ListView and TreeView.
This is one of my greatest frustrations with the web as a platform. These controls are so basic they should just be there, eliminating the need to sift through dozens of third-party implementations all with wildly varying feature sets, performance profiles, framework compatibility, levels of upkeep, etc to find one that works for your project.
Don’t attribute to malice… Many people working on frontend came from application or backend development and preferred the JavaScript model to a more declarative one. Not understanding enough the document context that drives the web. This makes everything more fragile and slow but hey “functionality” wins over everything else in todays world.
It is possible for normal everyday people to make contributions to the standards. I'm sure if you created a patch that showed these things working in firefox/webkit/chrome and wrote up a proposal and sent it to the correct listserv, you would at least have something more than baseless conspiracy to be mad about
Definitely one place htmx can be abused is oob-swap: https://htmx.org/attributes/hx-swap-oob/, which allows any given HTMX request to replace any part of the page. It sort of destroys the concept of locality of concern that HTMX pushes for.
One example of this is the lack of an include-tag that could fetch a fragment from the server (useful for headers/footers). Developers have wanted it for decades and have been forced to reproduce the functionality themselves using frames and/or javascript.
Htmx users, can you please share your backend stacks and approaches? Me specifically interested in templaters for node (+ts) and your thoughts on endpoint management, but all ideas are welcome I guess.
The way maud lets you compose markup works very nicely with htmx. The HX-Request header lets you know if the request is coming from htmx or if it is a regular request. You either call the top-level function if it's a regular request to get the entire page rendered, or call a subset of functions to get the appropriate partial rendered if it's an htmx request.
It's also nice to easily have tests for the rendered pages. My unit tests cover verification of the rendered HTML, too.
Go: go templates and fiber for http serving. I have a mini framework for adding some structure to the templates (folder per feature: contains controller, templates, etc, and some naming conventions)
Django user here. HTMX fits in perfectly with the Django templating system. A fairly common approach is to use the same view but check for the HTMX header and then return a template file with the specific bit of HTML being swapped. There's also work in the Django space to be able to return parts of a template based on the request, which will suit HTMX perfectly too.
Well, as I expected, templating is the hardest part of migrating to htmx on nodejs.
After reviewing few templaters/etc (handlebars, ejs, lit-html, virtual-dom) and few abstractions (html``, just ``, h()), barely anything seems too easy and too freedom-y. Arcane syntaxes, high character noise (ejs, lit, js), lack of typing (all non-`` based), trivial screw ups (virtual-dom, handlebars), experimental status (lit ssr). Sigh.
Most people prefer templ but I don't like logic in templates, I just want to parse values. I keep different states in different template files.
Each template file is a portion of a full page which makes it easy to create an endpoint that pulls the partial with the latest values. HTMX can then hit that endpoint to load or refresh values.
Endpoints are usually
domain/page/partial
so if I'm on a configuration page at
example.com/config
then the endpoint for the privacy settings partial would be
example.com/config/privacy
Going directly there in a browser would get a 404 because I check for the HX-Request header.
Endpoint handlers return a processed template with the current state. I use those functions to both compose the full page on the backend, and to build the output for the partial endpoint.
I don't automatically expose all partials. I add endpoints as I need them. This is probably more idiomatically Go than anything to do with htmx.
Htmx + Kotlin with ktor and the html dsl was really fun to play with on a personal project. Static typing, autocomplete and a full-fledged programming language available to use in your html markup is a game changer. I was structuring my endpoints as pairs of "data" and "render", where the render endpoint just reused the function for the date endpoint.
NestJS with Handlebars templates. I don’t love Handlebars but I have past experience with it so was the most pragmatic choice.
I’m interested in trying EdgeJS as a templating alternative to HB but haven’t got round to it yet.
I’ve added a NestJS error handler that looks to see if the request came from an htmx request and then serve the error response as html, if not then it sends back json since I do have json api end points as well in the back end.
perl + Template Toolkit (using the underdocumented support for the fragment pattern with EXPOSE_BLOCKS), before finding htmx we used Jemplate, which let you compile Template Toolkit templates into Javascript functions
My hot take: We initially used this library to allow us to iterate faster. But its is a pain once you reach a certain point, where it doesn't make sense to have this type of logic in HTML. I especially don't like how this library does error handling. I feel like this is the new jQuery. There is better way to represent interaction logic with open JS standards like Web Components.
I just want to take advantage of this news to say: I love HTMX so much! :D It makes web development fun again. I can still use all the fancy js libs I want -- but my main logic lives on the server, using plain HTTP and HTML. Really clear and simple.
Readit News
The app is now chock full of htmx interactions and has very little client side JS for the size of the app and it’s a joy to work on.
Without htmx I would not be able to turn around features as quickly as I do for the wider team so thank you, thank you, thank you.
I’ve been in web dev for 20 years and this feels like what we should have made all along.
The one area I would like to see some development is the file upload experience, I’ve had to do something a bit weird to get htmx and dropzone playing nice.
this isn't much of a feature upgrade, but we took the opportunity to clean up a few things and drop IE support, which will help us slim down the library over time
hopefully it's an easy upgrade for most htmx users, upgrade guide is here:
https://htmx.org/migration-guide-htmx-1/
happy to answer any questions
I genuinely think htmx is the only one I have liked even after I built something substantial in it.
To me that is big, to be able to walk away from a significant amount of time with something and say "yeah! I want to use that again!" instead of some variant of "it's the least bad option" is both rare and cherished so thanks for all the hard work.
Thank you!
https://www.youtube.com/watch?v=inRB6ull5WQ
we are talking w/the chrome developers about these ideas, i'm cautiously optimistic
You can make tabs, accordions, carousels, modals, popovers and even Pure HTML Out-Of-Order Streaming (PHOOOS) using only HTML & CSS: https://kodus.pl
Perhaps, there's already a good way to hijack xhr that I'm unaware of too.
Edit: Relevant link: https://logankeenan.com/posts/client-side-server-with-rust-a...
i may restructure the internals to allow for mocking out responses using events, it comes up, especially w/ extensions
https://htmx.ceo
My only question: how can I get a set of those sweet sweet floppy disks?
i often recommend it for people that want a more "batteries included" hypermedia-oriented library
---
1: https://github.com/bigskysoftware/htmx/blob/master/src/htmx....
https://bundlephobia.com/package/htmx.org@1.9.12
and 2.0.0 was 45.3:
https://bundlephobia.com/package/htmx.org@2.0.0-beta4
i think that the better web components support blew is up a little. there is a reasonable amount of fat we can cut around IE support that is still in there, planning on doing so over the next few months & slowly
17ms over emerging 4G (and hopefully cached forever after that) doesn't freak me out too much
It's completely stupid HTML, by default, doesn't have basic controls found in EVERY UI toolkit since circa 1980. The standard examples being ListView and TreeView.
This is one of my greatest frustrations with the web as a platform. These controls are so basic they should just be there, eliminating the need to sift through dozens of third-party implementations all with wildly varying feature sets, performance profiles, framework compatibility, levels of upkeep, etc to find one that works for your project.
This is a good essay on the topic: https://htmx.org/essays/when-to-use-hypermedia/
Definitely one place htmx can be abused is oob-swap: https://htmx.org/attributes/hx-swap-oob/, which allows any given HTMX request to replace any part of the page. It sort of destroys the concept of locality of concern that HTMX pushes for.
The W3C specced out such a tag nearly 20 years ago, but because the browser devs are terrified of all things XML it was never implemented.
https://twitter.com/htmx_org/status/1799661735781261592
There's even some sweet ascii art on the disk: https://twitter.com/jcs224/status/1799586838161621339
Great to see the continued love of this framework. (don't throw anything at me)
- axum: web application framework - https://github.com/tokio-rs/axum
- axum-htmx: axum extractors, responders, guards for htmx - https://github.com/robertwayne/axum-htmx
- rusqlite: SQLite bindings - https://github.com/rusqlite/rusqlite
- maud: HTML templating as a macro - https://maud.lambda.xyz
The way maud lets you compose markup works very nicely with htmx. The HX-Request header lets you know if the request is coming from htmx or if it is a regular request. You either call the top-level function if it's a regular request to get the entire page rendered, or call a subset of functions to get the appropriate partial rendered if it's an htmx request.
It's also nice to easily have tests for the rendered pages. My unit tests cover verification of the rendered HTML, too.
> mini framework for adding some structure to the templates
Would be good to read little more about this mini-framework
Dead Comment
After reviewing few templaters/etc (handlebars, ejs, lit-html, virtual-dom) and few abstractions (html``, just ``, h()), barely anything seems too easy and too freedom-y. Arcane syntaxes, high character noise (ejs, lit, js), lack of typing (all non-`` based), trivial screw ups (virtual-dom, handlebars), experimental status (lit ssr). Sigh.
I use PUG. I don’t like to close HTML tags. This cuts 30% of the visual bloat out of my templates.
[1] https://biffweb.com/
Most people prefer templ but I don't like logic in templates, I just want to parse values. I keep different states in different template files.
Each template file is a portion of a full page which makes it easy to create an endpoint that pulls the partial with the latest values. HTMX can then hit that endpoint to load or refresh values.
Endpoints are usually
so if I'm on a configuration page at then the endpoint for the privacy settings partial would be Going directly there in a browser would get a 404 because I check for the HX-Request header.Endpoint handlers return a processed template with the current state. I use those functions to both compose the full page on the backend, and to build the output for the partial endpoint.
I don't automatically expose all partials. I add endpoints as I need them. This is probably more idiomatically Go than anything to do with htmx.
It's basically cheating. The setup is dead-simple to operate.
Templ is great when you need to separate reusable components.
I’m interested in trying EdgeJS as a templating alternative to HB but haven’t got round to it yet.
I’ve added a NestJS error handler that looks to see if the request came from an htmx request and then serve the error response as html, if not then it sends back json since I do have json api end points as well in the back end.
Deleted Comment