I’ve been using htmx for over a year now for our internal management application (order monitoring, partner management, CAD model uploading and management type stuff) and I continue to be delighted at how quickly I can add features and iterate existing ones. I write way less client side JS, the app is very fast and responsive and I don’t have to write the app twice like with a SPA + API.
One thing I've been struggling with using HTMX... with an app and a frontend REST API I've found I can really kinda quickly craft a frontend by filtering down whatever resources I need (though it's honestly pretty wasteful at times).
With HTMX I'm finding myself needing to have as many backend views as I have ways of interacting with a page. I still have to write the frontend, and on top of that I gotta make a bunch of one-off backend views for many interactions. What am I doing wrong?
This is the thing that makes me lose interest in HTMX. People talk about it like it eliminates the need for JS/React/etc, but as far as I can tell, you're still writing those same templates, just using your backend language instead of JS. Which is convenient, but hardly "less code", just a different language, and that backend language probably lacks a lot of functionality you'd want for UI convenience. That's all fine if you'll never want those UI conveniences, by my experience has been that the want of those UI conveniences creep in over time, and eventually you regret not using something that makes them native and easy.
I haven't actually played around with HTMX, so I might be sizing it up wrong, but it's mission statement just never resonated with me enough to want to try it out.
I make htmx sites built around view fragments rather than pages. And when I need a page it's just a set of fragments. I make "API" endpoints fir the needed fragments and call via ssr on first paint, then as needed from the htmx side.
HTMX pairs incredibly well with something like Go’s templates. Giving you the “what you’d want react to be” experience for many scenarios. I imagine it’s similar with other languages with good templating engines, I just know it’s extremely easy to build things with Go and HTMX.
That being said, HTMX is not for everything. It’s great for internal tools as long as you don’t have very complex role-based access model. But security and access rights is where I think HTMX quickly becomes too complicated compared to a more traditional approach. As far as having “too many back end views” I do think that is down to you choosing an “incompatible” backend for your HTMX. It’s hard to say without knowing your details. You do say that you put a REST api behind it, but why would you do that with HTMX?
When I build a page that uses HTMX, I go one of two ways.
Traditionally I first build it as a fully server-side rendered page. Once that’s working I setup my views to return HTML partials for different parts of the page.
So I might still have multiple views (or I might have single views that handle path parameters, query parameters, etc), but each is then basically just returning part of the existing template:
Full page: return render(request, "jobs/index.html", ...)
Some part of the page: return render(request, "jobs/index.html#status", ...)
You can sort of think of this the same as you would with JSON API endpoints, where you still need different endpoints handling different HTTP methods (GET, POST, etc) for the different CRUD operations, and there’s a tradeoff regarding how granular you get with views, but typically you can make the views pretty generic and reusable (the same way you can make JSON API endpoints that essentially just serialize database query results). There’s an article [0] that gives an example of a similar approach.
More recently I’ve been using a more component-based approach, using something like htpy [1] where I build up the page out of components (like you would in React), and sprinkle JS and CSS into the HTML with Alpine and Tailwind.
I've tried HTMX with a few different back end frameworks and languages, my setup varies a lot based on which framework/language I use.
The pattern I've been happiest with is when I can have a templating language designed to work really well with a component (or partials) approach.
I break down the UI into smaller components as I add more HTMX interactions. The UI is effectively a tree of nested components, much like react or svelte. When an HTMX request is sent, the API handler logic runs and instead of returning a success response it sends back HTML for the individual component(s) that HTMX needs to update.
tl;dr; When a request comes in, check headers to see if it was an HTMX request. If it wasn't, handle the API logic and return the full HTML page. If it was an HTMX request, still run the API logic but send back only the rendered components/partials that changed.
Check out https://alpine-ajax.js.org it defaults to using the same template views you would in a typical JavaScript-less app, then you can sprinkle in fragments where you need to optimize requests.
I love htmx for internal dashboards. I find htmx difficult to use for user facing applications because it's difficult to get everyone on board with the constraints of htmx (no optimistic uis, simple ui/ux). When building complicated frontends with lots of popovers, modals, optimistic state, I like react.
UX designers are immersed in this world of React and frontend frameworks, so their designs are built with that in mind.
Doing things the "htmx way" on a team requires buy-in from more than just devs and that can be hard.
We should be careful not to push htmx too past what it was meant for, as well. I remember how much I admired React when it was released for its simplicity.
I don't think htmx should be used on its own when implementing ui/ux - htmx has the job of getting the blocks of html, with data embedded, from the back-end to the front-end (and posting back up as necessary); once it's there, front-end client-only ui/ux can be handled by other tools in JavaScript
I guess I could have done but the server was initially set up to respond with JSON and then the pages aspect got added in later and it felt easier to boot in htmx and bolt in the partials system and keep the json endpoints that are still needed than rearchitect for a proper MPA.
> I am a simple sole, ... go back to the halcyon early days of the web before Netscape dropped the JS-bomb. You know HTML for the layout and CSS for the style.
I am not sure if this is intended as humor, but JavaScript came before CSS.
I remember when CSS Zen garden was showcasing what you can do with CSS, and browsers (well, "browser", singular, as there was basically only IE 6 back then) supported Javascript and VBScript.
It seems JavaScript was first released, just internally, in May 1995 in a pre-alpha version of Netscape 2.0. It would not be publicly announced until December 1995. Netscape 2.0 didn't even come out until March 1996 and even then it was language version 1.0 which was extremely defective. The first version of the language that actually worked was JavaScript 1.1 that came out in August 1996. CSS on the other hand first premiered with IE3 that came out in August 1996.
The distinction either way is trivial, because at that time nobody was using either CSS or JavaScript as they required proprietary APIs. There was no DOM specification at that time.
JavaScript was created by Brendan Eich in just 10 days in May 1995 while he was working at Netscape Communications Corporation
CSS (Cascading Style Sheets) was introduced later than JavaScript. The first CSS specification was published in December 1996 by Håkon Wium Lie and Bert Bos.
> As we have seen in the previous posts, HTMX eliminates the need for JS to make dynamic web content.
Well, sort of! I suppose that for certain definitions of eliminating Javascript, this Javascript framework eliminates the need for Javascript completely.
HTMX is whooping 45KB of JS, which is being often loaded in <head> blocking rendering HTML, whereas you can have a fully functioning interactive website with pure CSS framework like Spectre.css (https://niutech.github.io/spectre/) and a sprinkle of 166-byte (sic!) HTMZ. See my demo: https://kodus.pl
Which is a bit surprising considering that react is 90kb unzipped, 46kb zipped. Yet there's this weird sentiment that react is JS bloat while htmx isn't.
htmlx, taiwind and the like certainly help back-end dev churn out web codebases faster, eliminating a lot of poor souls who have to maintain them afterward!
> I am a simple sole, I want to reduce the cognitive load in my web projects. The general idea is to go back to the halcyon early days of the web before Netscape dropped the JS-bomb. You know HTML for the layout and CSS for the style. An elegant division of roles.
(I'm not quite sure if this is the author's sentiment), but the point shouldn't be to escape JS entirely, but make it into something that can be used in a repeated pattern that works in lockstep with your application, such that you are neither creating custom JS for each page (e.g. React), nor blindly manipulating the DOM (like JQuery).
The division of roles between CSS and HTML is an almost contradictory point - your styling and layout should be coupled if you are to impose any meaningful order in your design. If you are rejecting the "decoupling" of front-end and back-end that React gives you, then why would you expect to be able to do it between HTML and CSS?
these two points are exactly where I am coming from ...
(i) I am deliberately starting from a(n over-) simplified pov to see how far I can get with zero JS ... but as I read the comments above I realise that, for real applications, I will need to "sprinkle" some Alpine and Tailwind here and there. (I chose Cro for the user auth.)
(ii) Indeed HTML and CSS are in an intricate contradictory dance. In the purest sense I think that my sites should be composed of reusable parts that sit within context. These parts can be composed from roles and may selectively tweak them. The roles convey aspects of the design (colours, typography, containment, scale, size). The parts contain content (text, image, actions), identity and semantic intent. Role mixing in SASS is a small start in this direction.
[This is a very weak stab at a very thorny problem ... please let me know if there is any reading that you recommend.]
HTMX is a great tool to bring the UI implementation back into the realm of more capable & expressive languages. And to start with a new perspective.
My personal preference is Raku, but you may prefer OCAML, Rust, Go, Python, Haskell, Elixir, ROC, Zig ...
Why not just use a pure CSS framework like Spectre.css (including accordions, modals, carousels, tooltips, tabs) and optionally a 166-byte HTMZ where CSS is not enough? You don't need more than 1KB of JS, see PHOOOS at https://kodus.pl.
HTMX, Unpoly and Twinspark are great, can't say anything about Raku.
I also really liked an idea about class-less CSS frameworks, as I was frustrated with all the `<table class="table">` and so on. Then I've tried it for one project where I had to integrate Leaflet map on a page. And it's just not possible to do with class-less CSS frameworks.
Since then I write `<table class="table">` and have zero problems with that.
How is it not possible? Can you not just use classes for the map tags and keep everything else the same? Or is the problem that the map styles are affected by the classless CSS?
The main example in this article — immediately following a section on semantic HTML — is a list of <a> tags with the hrefs all set to `#` and the hyperlink behavior emulated with htmx. So we’ve taken what would otherwise be a perfectly functional list of links, removed the most important semantic attribute, broken a bunch of behavior and rendered them useless without a ~16kb JavaScript library.
…and look, that’s an okay mistake to make — it takes time to learn this stuff — but when you also go out of the way to pine for “the halcyon early days of the web before Netscape dropped the JS-bomb” it makes it difficult to take you seriously. A list of links is, like, the most basic essence of a website; if you aren’t able to make that work without a JavaScript library, what are you even pining for?
It’s not really about the tooling. My point is that people who talk about the “good old days” of the web often (charitably) are unfamiliar with or (cynically) don’t care about the medium they venerate.
I'm just curious if anyone is using unpoly instead of HTMX?
I know that HTMX has a much larger userbase, its main dev is well known and beloved, and the landing page doesn't look web 1.0
With that said, unpoly appears to have a similar feature set and one feature that HTMX doesn't: The ability to create modals without loading a new page.
I use it for a rewrite I'm doing because tracking state on both back- and front-end got too cumbersome.
I'm using Django, and a big positive of using unpoly is that I can write views like a traditional Django application and have a reactive frontend.
It does mean however that heavy pages impact front-end reactivity. So if there's only one tiny element that needs to be updated on the front-end, that takes more time than if the backend would only have to return a template partial (htmx) or some JSON (alpine).
Also, the documentation is really a reference. You need it read it front to back a few times to understand unpoly's capabilities.
It's strange that there are so few tutorials about it, because it's been around for a while already, it really has its use and it is still under active development.
It has "actions" that bridge a need for some client-side interactivity, without resorting to write lots and lots of JS. I have some interactive stuff that don't touch server. Also it's pretty easy to add more actions when needed.
And if I need to do something really complex, I can just go and read its source code. Which is really hard to do with unpoly and its really complicated OOP style.
Yes, using unpoly, I conclused the way updates work in unpoly to be easier to work with, less need for lots of special endpoints for every kind of interaction than in htmx. But haven't really tried htmx much.
Readit News
With HTMX I'm finding myself needing to have as many backend views as I have ways of interacting with a page. I still have to write the frontend, and on top of that I gotta make a bunch of one-off backend views for many interactions. What am I doing wrong?
I haven't actually played around with HTMX, so I might be sizing it up wrong, but it's mission statement just never resonated with me enough to want to try it out.
- https://htmx.org/essays/template-fragments/
- https://htmx.org/essays/10-tips-for-ssr-hda-apps/
That being said, HTMX is not for everything. It’s great for internal tools as long as you don’t have very complex role-based access model. But security and access rights is where I think HTMX quickly becomes too complicated compared to a more traditional approach. As far as having “too many back end views” I do think that is down to you choosing an “incompatible” backend for your HTMX. It’s hard to say without knowing your details. You do say that you put a REST api behind it, but why would you do that with HTMX?
Traditionally I first build it as a fully server-side rendered page. Once that’s working I setup my views to return HTML partials for different parts of the page.
So I might still have multiple views (or I might have single views that handle path parameters, query parameters, etc), but each is then basically just returning part of the existing template:
Full page: return render(request, "jobs/index.html", ...)
Some part of the page: return render(request, "jobs/index.html#status", ...)
You can sort of think of this the same as you would with JSON API endpoints, where you still need different endpoints handling different HTTP methods (GET, POST, etc) for the different CRUD operations, and there’s a tradeoff regarding how granular you get with views, but typically you can make the views pretty generic and reusable (the same way you can make JSON API endpoints that essentially just serialize database query results). There’s an article [0] that gives an example of a similar approach.
More recently I’ve been using a more component-based approach, using something like htpy [1] where I build up the page out of components (like you would in React), and sprinkle JS and CSS into the HTML with Alpine and Tailwind.
[0] https://www.circumeo.io/blog/entry/django-htmx-and-template-...
[1] https://htpy.dev/
If you have problems filtering in the backend but it's easy in the frontend your backend technology is probably lacking.
The pattern I've been happiest with is when I can have a templating language designed to work really well with a component (or partials) approach.
I break down the UI into smaller components as I add more HTMX interactions. The UI is effectively a tree of nested components, much like react or svelte. When an HTMX request is sent, the API handler logic runs and instead of returning a success response it sends back HTML for the individual component(s) that HTMX needs to update.
tl;dr; When a request comes in, check headers to see if it was an HTMX request. If it wasn't, handle the API logic and return the full HTML page. If it was an HTMX request, still run the API logic but send back only the rendered components/partials that changed.
Doing things the "htmx way" on a team requires buy-in from more than just devs and that can be hard.
We should be careful not to push htmx too past what it was meant for, as well. I remember how much I admired React when it was released for its simplicity.
Plus I wanted an excuse to use htmx.
I am not sure if this is intended as humor, but JavaScript came before CSS.
* https://www.w3.org/Style/CSS/msie/
* https://webdevelopmenthistory.com/1995-the-birth-of-javascri...
The distinction either way is trivial, because at that time nobody was using either CSS or JavaScript as they required proprietary APIs. There was no DOM specification at that time.
JavaScript was created by Brendan Eich in just 10 days in May 1995 while he was working at Netscape Communications Corporation
CSS (Cascading Style Sheets) was introduced later than JavaScript. The first CSS specification was published in December 1996 by Håkon Wium Lie and Bert Bos.
apologies
Deleted Comment
Well, sort of! I suppose that for certain definitions of eliminating Javascript, this Javascript framework eliminates the need for Javascript completely.
(I'm not quite sure if this is the author's sentiment), but the point shouldn't be to escape JS entirely, but make it into something that can be used in a repeated pattern that works in lockstep with your application, such that you are neither creating custom JS for each page (e.g. React), nor blindly manipulating the DOM (like JQuery).
The division of roles between CSS and HTML is an almost contradictory point - your styling and layout should be coupled if you are to impose any meaningful order in your design. If you are rejecting the "decoupling" of front-end and back-end that React gives you, then why would you expect to be able to do it between HTML and CSS?
Deleted Comment
(i) I am deliberately starting from a(n over-) simplified pov to see how far I can get with zero JS ... but as I read the comments above I realise that, for real applications, I will need to "sprinkle" some Alpine and Tailwind here and there. (I chose Cro for the user auth.)
(ii) Indeed HTML and CSS are in an intricate contradictory dance. In the purest sense I think that my sites should be composed of reusable parts that sit within context. These parts can be composed from roles and may selectively tweak them. The roles convey aspects of the design (colours, typography, containment, scale, size). The parts contain content (text, image, actions), identity and semantic intent. Role mixing in SASS is a small start in this direction.
[This is a very weak stab at a very thorny problem ... please let me know if there is any reading that you recommend.]
HTMX is a great tool to bring the UI implementation back into the realm of more capable & expressive languages. And to start with a new perspective.
My personal preference is Raku, but you may prefer OCAML, Rust, Go, Python, Haskell, Elixir, ROC, Zig ...
I also really liked an idea about class-less CSS frameworks, as I was frustrated with all the `<table class="table">` and so on. Then I've tried it for one project where I had to integrate Leaflet map on a page. And it's just not possible to do with class-less CSS frameworks.
Since then I write `<table class="table">` and have zero problems with that.
…and look, that’s an okay mistake to make — it takes time to learn this stuff — but when you also go out of the way to pine for “the halcyon early days of the web before Netscape dropped the JS-bomb” it makes it difficult to take you seriously. A list of links is, like, the most basic essence of a website; if you aren’t able to make that work without a JavaScript library, what are you even pining for?
Deleted Comment
I know that HTMX has a much larger userbase, its main dev is well known and beloved, and the landing page doesn't look web 1.0
With that said, unpoly appears to have a similar feature set and one feature that HTMX doesn't: The ability to create modals without loading a new page.
1: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
2: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
I'm using Django, and a big positive of using unpoly is that I can write views like a traditional Django application and have a reactive frontend.
It does mean however that heavy pages impact front-end reactivity. So if there's only one tiny element that needs to be updated on the front-end, that takes more time than if the backend would only have to return a template partial (htmx) or some JSON (alpine).
Also, the documentation is really a reference. You need it read it front to back a few times to understand unpoly's capabilities.
It's strange that there are so few tutorials about it, because it's been around for a while already, it really has its use and it is still under active development.
It has "actions" that bridge a need for some client-side interactivity, without resorting to write lots and lots of JS. I have some interactive stuff that don't touch server. Also it's pretty easy to add more actions when needed.
And if I need to do something really complex, I can just go and read its source code. Which is really hard to do with unpoly and its really complicated OOP style.