I’ve just completed a port from HTMX to Hotwire (Stimulus, Turbo). HTMX is a great idea, but in my experience it’s a poor execution.
It’s really quite buggy, in my experience it plays poorly with fundamental web and browser features (relative links are broken in at least 2 ways, I fixed a third way). One of the events just stopped working at all in the most recent release. The docs are lacking. And where it promises to let you write less JS, if you ever do need to write some JS you’re on your own in structuring that, and you’ll be fighting against HTMX (who gets to update the DOM, maintaining event handlers, etc).
As a (brief) contributor to HTMX, I also feel like these issues were all inevitable. It’s a single 5k line file with 190 top level functions in it meaning it’s pretty impenetrable to get up to speed on. When proposing a bug fix the maintainers weren’t sure if it would have other consequences. Tests didn’t cover the functionality. I’ve been mostly a backend engineer in my career, and I empathise with not wanting the complexity of a modern frontend, but that doesn’t mean we can’t have some basic organisation of the code to make it approachable and more obvious whether changes will work or not.
After porting to Turbo and Stimulus I have a more reliable code base, I have significantly less JavaScript, and I have a JS code base that much easier to reason about. I really wanted to like HTMX but the execution is not there. A focus on stability is a great fit for the project, but it’s most certainly not there yet and has quite a way to go in my experience.
I would love to know in what other two ways relative links are broken, and which event stopped working, so we can get those fixed. With respect to the fix you PRed (thank you, by the way), we did get that merged very quickly, and would love to do the same for whatever is broken here, even (especially) if you are no longer interested in doing the fix yourself. [0]
As for the DX of making changes to htmx: absolutely true! The single file is a DX we've chosen, and it has both costs and benefits, which we've written about in "Why htmx doesn't have a build step". [1]
Hi Alex, thanks for the reply and for your work on HTMX. I love the idea and think there's a strong need for something like HTMX, and if HTMX can live up to those promises then great. For me it doesn't, currently, but it sounds like it does for others.
The relative link bugs are [0] and [1], and I fixed [2]. My fix was merged quickly, but the other two bugs of what appears to be similar significance, have been open for well over a year each. My issue however is less about these specific issues, and more the general lack of support for hypermedia, which speaks to a general state of HTMX not living up to its promises.
As for the DX, I think not having a build step, and code structure, are somewhat orthogonal. I agree with much of that essay, but most of it is about issues with complex build systems and the use of Typescript. It's not about having 190 top-level functions, which, with all due respect, I think indicates a lack of architecture. Again, the issue is less about the specifics, and more about the fact that HTMX is not living up to its promise of simplicity because of how impenetrable the codebase is in this regard.
As mentioned, so far I have found Stimulus and Turbo to be better implementations of what HTMX appears to promise to be. More activity in this space from anyone and everyone is great here though!
They're sectioned off, so "event/log support" and "AJAX" and such are grouped by the type of method, but they're not prefixed so there's no way for your editor to help you explore grouped functionality.
Given that the code isn't particularly organized or structured in any way that I could quickly glean (aside from the aforementioned grouping of related functionality, which is only so helpful), I think I'd be put off from wanting to contribute to this codebase.
De gustibus, but after taking a look personally I think it's pretty good. It's typed to the extent allowed by js, sections are clearly delineated, and if you collapse all the functions you can get a quick overview of every section. I personaly would use a different naming convention, but still their functions look reasonably named.
Naming doesn't have anything to do with the number of functions. They section things off in the file, so if you prefer things split into multiple files I can understand, but it's a personal perference in something this size
If you're not using more common organization tools like modules, naming tends to be where organization is implemented: common prefixes, etc. Even if they're carefully done, you still end up with a long list of names, with a lot of implicit rules to keep in mind to decode the name (this is why Hungarian notation seemed like such a good idea in the beginning, and a bad idea once it was actually extensively used). Names shouldn't need decoding.
I haven't looked deeply at HTMX, so I won't claim they're falling prey to this exact problem. But it's definitely a code smell that's concerning.
The more you need to hold in your head at once to understand code the harder it is to do understand, and the harder it is to contribute or onboard to a codebase.
A lot of functions doesn't necessitate a lot of things to hold in your head, but in my experience, HTMX hasn't got enough other structure to prevent this. I was not confident about the changes I made, and the reviewer was not confident about the changes. In a well architected codebase the goal is for these things to be obvious.
As for minimising classes? Sure. I can get behind that. But I think it's orthogonal to having a lot of top level functions with no clear naming or sorting.
If the goal is to have a single-file codebase, I'd suggest considering the following (you may already have done so, but I haven't noticed consideration in the few documents I've read):
- Structuring the file into clearer regions – there is already some of this, but comment blocks are easy to miss in a 5.2k file, and utilities are everywhere.
- Adding named closures for grouping related functionality – "classes lite", at least gives some function namespacing and code folding.
- Ordering the file to help direct readers to the right bit, literate-programming style, so that there's a sort of narrative, which would help understand the architecture.
- Function name prefixes to indicate importance – is something the entrypoint to core functionality? is it a util that should be considered a sort of private function?
- Pure functions – so much of the code is state management performed in the DOM, which makes it hard to test, hard to know if it's working, hard to know what interactions will be introduced, etc. State management is always hard, but centralising state management more would be good.
- (That said... arguably library internals are the place to have make the low-abstraction high-performance trade-off with a bunch of mutable state. However, this makes it hard to have other Javascript that co-exists with HTMX, because it's too easy to stomp over each other's changes. A better integration path, like Stimulus, might alleviate this and retain HTMX's control over the DOM).
- I understand the preference for longer functions, but `handleAjaxResponse` is a lot. More abstraction would really help make this more understandable.
I get that personal preferences are key to why HTMX is the way it is, but I think it's important for the general health of open source projects that others are able to contribute, safely and effectively, and I'm not sure the current choices are most conducive to that. Hopefully some sort of middle ground can be found where HTMX doesn't lose its "personality"(?) but where some of these things can be improved.
Obviously it's an idiosyncratic way to organize code, and I get that someone coming in and making a one-time contribution might be a bit overwhelmed by how different it is than other codebases, but I've been happy with how easily i've been able to come into it after taking time off and figure things out, particularly when debugging.
We have other people contributing on an ongoing basis and i've had people (mostly non-JS people) comment on that they find the codebase easy to navigate, since you don't have to rely on IDE navigation.
There isn't a lot of state involved in htmx: it's mostly passed around as parameters or stored on nodes. History, where you ran into a problem, is a tricky part of the library that's hard to test, and that's where most of the problems have cropped up. I could probably factor that better to make it more testable, at the cost of more abstractions and indirection.
In general, I'm not inclined to change the organization much (or the codebase, per the article above) so that we can keep things stable (including the behavior of events, which apparently changed on you at one point.) I'll sand it, but I'm not going to do a big refactor. We've had people come in and propose big changes and reorganizations, and we've said no.
https://data-star.dev is a result of someone proposing a big htmx rewrite and then taking it and doing their own thing, which I think is a good thing. htmx will stay boring, just generalizing hypermedia controls.
Given the lack of API changes going forward, I hope that artifacts like that, coupled with overall stability of the implementation, will mitigate risks for adopters.
I think an opinionated stance is in general a good thing when it comes to open source project. I just worry that contrarianism in frontend development is being conflated with contrarianism in general programming. The former being the intention of the project that I support (yay hypermedia!), and the latter most likely not being the goal.
Maybe the sanding will help, and if HTMX is not going to change much then maybe not much is needed, but I think there's still a way to go to stability and feature completeness.
Thanks. Genuinely asking something here: are relative links actually common in frontend? I've only ever used absolute URLs for static assets. Actually I even made tooling that ensures that static asset paths will always be correct: https://yawaramin.github.io/dream-html/dream-html/Dream_html...
Of course, this kind of tooling exists for many frameworks. But I've never seen frontend frameworks suggest using relative links for static assets, they always seem to put them in a separate subdirectory tree.
Relative links are common in the Microsoft ecosystem; the IIS webserver, in its default configuration, serves websites at a subpath named something like /Our.App/ instead of at /. Frontends often use the <base> tag so that they can refer to assets by relative path, allowing different environments to have different base paths.
Random developer here: in my code, yes they are common. I tend to write modules so that I can route to them from wherever, reuse them, and move them around as I please. Relative links help greatly with such things.
Besides that, they are a very basic part of the spec, and I consider anything that breaks them to be truly fundamentally broken.
Understood, but how do you deal with static asset caching and cache-busting with version markers or similar? Does your framework/build system/whatever automatically add version markers to static assets that are bundled directly with your module?
I tend to keep statics consolidated and slap middleware on those routes to handle expiration headers and whatnot. Versioning is handled where links are generated; an href="{{ linkfor(asset) }}" style resulting in generated urls complete with content hash tacked on. I almost never construct asset links without some form of link generator function because said functions give me a centralized place to handle things just like this.
(edit: I should clarify that I'm mostly working in Go these days, and all my assets are embedded in the binary as part of compilation. That does make some of this much easier to deal with. Javascript-style build mechanisms tend far too much toward "complex" for my tastes.)
OK, wait, you said earlier that you bundle static content like images in the same module as the feature itself, but now you're saying you keep them consolidated in a separate place? You also said earlier that you commonly used relative links but now you're saying you generate them with a link generator function? I'm confused about what you're actually doing...if you look at the link I posted earlier, you can see how I'm doing it. So...are you using relative links like <img src=dog.png> or not?
I was unclear; I bundle them per-module; each module has an asset route with attached middleware. So for a users module, there will be users/assets or some such route, to which various static-related middleware gets attached.
The link gens inherently accept relative paths (foo) and output relative links with appropriate adjustments (foo.png?v=abcdef), though they can generate fully-qualified links if circumstances warrant (eg I often have a global shared css file for theming, though that's all I can think of offhand other than "/" for back-home links). The module can then be mounted under /bar/blort, or wherever else, and the links remain relative to wherever they are mounted.
On occasion I do hardcode links for whatever reason; my rule of thumb is relative links for same level or deeper, or root-anchored if you're referencing a global resource outside the current path, but there aren't many of those in my apps. A rare exception might be something like an icon library, but I tend toward font-based icons.
To put the rule more succinctly, I never use "../foo". Going up and then over in the hierarchy strikes me as a recipe for bugs, but that's just instinct.
I also never use fully-qualified (including hostname) urls to reference my own assets. That's just madness, though I vaguely recall that WordPress loves to do crap like that; there's a reason I don't use it anymore. :)
So the main difference if I understood your link correctly, would be that I would have maybe one or two items in /static/assets by root-anchored urls, and the rest accessed as /path/to/module/assets/whatever (edit: or just assets/whatever from within the module).
Because I'm doing this in go, the module's assets live where the code does and gets embedded in a reasonably standard way. I actually tend to use git commit as my cache buster to avoid having to hash the content, but full hashing can be done as well very easily just by changing the generator functions.
I can then just import the module into an app and call its associated Route() function to register everything, and it just works. Admittedly it's very rare that I reuse modules between apps, but it's easily possible.
For background to my thought process, I originally started using the link gen paradigm long ago to make it easy to switch CDN's on and off or move between them, back before whole-site proxying was considered best-practice. The rest is just a desire for modularity/encapsulation of code. I like to be able to find stuff without having to spelunk, and keeping assets together with code in the source tree helps. :)
It was `htmx:load`. On 1.x this fired on first page load, which I used to do a bunch of setup of the other little bits of JS I needed, and which would cause that JS to re-setup whenever the page changed.
On 2.x this never fired as far as I could tell. Maybe I got something else wrong, but only downgrading to 1.x seemed to fix it immediately, I didn't investigate further.
I did wonder if there were breaking changes in 2.x, but as far as I could tell from the release notes and documentation there were not.
I’m curious about your Swift backend stack, if you’re willing to describe it. I’ve become quite fond of the language after writing a few small desktop apps & command-line tools with Swift.
I love the language. I'm using Vapor+Fluent+Leaf, but I've had a few issues with them, I think they're fine, but if I was making decisions again I'd probably choose something else. I think the problem is that Vapor is trying to be a Django/Rails style, batteries-included framework as opposed to a Flask-style library (if those terms help you at all), but they've not quite nailed it to the Django/Rails level yet. For my project I'd have been better off with less framework, as most of my code is not strictly web code. I've ended up changing the Vapor application architecture a bit and pulling lots out into non-web-specific Swift Modules. If I were choosing again I'd give consideration to Hummingbird.
Library availability has mostly not been a problem for me, there are some really high quality libraries, particularly open source ones from Apple. Quality is high compared to other ecosystems.
I'm targeting Linux/Docker for deployment and while I don't have the project running in production yet, I've been running CI builds and it so far seems fine. It's fairly clear when things are Linux compatible and when they're not. Most things you'd expect to be are compatible. Some third-party libraries are accidentally not Linux compatible, but it hasn't been much of a problem for me.
The new Swift Testing library is really nice, and I'm using that for all my server tests with no real problems. Vapor could have more testing support (Django's is excellent and my bar for comparison), but it all works.
Overall it's just a lovely language to work in, and I'm enjoying server side development with it.
no doubt there was something small that i was missing, but i was doing a rapid, time-boxed experiment and didn't have time to get deeper into it, at the time
I have had a great experience with Astro and HTMX. When the first time I tried, I didn't think much about HTMX and thought it was an Astro thing, about a year or over. But this time, I had a great experience and I understand the power of htmx and native web only JS, no framework when building simple sites is much refreshing.
I prefer this style. I primarily use Emacs as someone else mentioned. I feel like it's sort of similar to editor tabs vs buffers. Like, once you have a good way of switching between buffers, separate editor tabs seem like a superfluous UI element. In a similar way, if you have powerful ways of navigating to the function definition you want, then everything being in the same file doesn't seem to matter.
Also, having all the code in a single file helps expression exposition of the code. You can sort of captivate the reader of your code, and present the code in the order of your choosing.
I do. I've always felt that I'm doing something wrong when I do this, but I much prefer not having to switch files all the time and navigate folders etc. looking for things. With everything in one file, I can just use regular within-file search (and M-x occur in emacs which is a bit like clickable (and editable) grep). If I need "focus", I just use narrowing in Emacs (shows only the highlighted part of the buffer, with handy shortcuts for narrowing to current function/class). If I need to see something side-by-side, just split or clone the buffer. I loathe working on those java etc. projects where you have a zillion classes each in their own file, many with maybe a handful of members each; whenever I switch files I feel like I'm losing context.
If you look at the end-user API documentation[1] it's pretty good.
But the htmx.js file itself seems to struggle from a certain type of internal naming scheme that will take a while to get up to speed with and doesn't really lend itself to being easy to context switch in & out of it, where you might simply forget that things exist and end up re-writing or inlining these fragments.
This naturally stems from a very organic development process, where something starts out as a quick prototype, then the functions get too big so you split fragments out into things like `shouldProcessHxOn` and `processHXOnRoot` which absolutely make sense at the time where you're avoiding duplication, and trying to turn it into something 'more proper' with 'better abstractions' would actually cause the code to balloon in size and make it much bigger and much more like object spaghetti.
On the whole though, a large amount of the file is type documentation, e.g. `/* @param {Node} start */` which is more a failing of JavaScript itself than anything else, and honestly a 5k self-contained file with good public documentation of what's user-facing vs internal is pretty easy to grok if it's something you work with frequently.
If you were to rewrite this in a saner language like Python with a more functional style, you could probably condense it down to 1000 lines or less.
Just a note to other readers, Turbo doesn't require Stimulus... I use Turbo mainly with AlpineJS and it works just as well since Turbo is the just tag driven side of things.
I wanted to use Hotwire but it felt like it was made for Rails as backend? This probably needs to be fixed because if the DX is as good as you say then its disservice to be tied to Rails.
Which leads to the appeal of HTMX. It promises no other dependence. It just does exactly what it advertised. I'm not sure whether your issues were due to implementation or specific known bugs in HTMX not covered.
I am curious to know more about Hotwire, I'm just worried about state management and this is greatly overlooked when it comes to adding application logic beyond just hydration of specific components on page.
So far I have not seen anything that competes with Sveltekit.
Hotwire is designed for good integration with Rails, but Rails is not required. In a similar way, HTMX works better with various server-side libraries, but none are required.
Personally I'm using Hotwire (was using HTMX) with a Swift backend with no issues.
Full stack polyglot dev here, the relentless pressure to use Sveltekit that has utterly destroyed plain Svelte docs, IMO, coupled with the koolaid kult around v5 is why i finally ditched svelte.
I have backend solutions and existing databases and existing backends. I would never consider a Js backend in a production app to begin with, despite the benefits an isomorphic approach offers.
I dislike when physical actual boundaries in code execution contexts are obfuscated, for one...
But not everyone is building SPAs, and my dev server is my actual backend, thanks
Yeah, Svelte5 said "away with these pesky svelte users, lets market to React devs and make everyone realize that Vue3 has a bigger ecosystem, since you are gonna have to do a rewrite anyway "
Basically the opposite of this principled stance here on this htmx missive
It doesn't have to, you can just start using a piece of technology 5-10 years after everybody else, you know.
We started using react a couple of years after hooks were introduced when there were millions of ready libraries, all major design patterns were established, tons of docs were written, etc., and although there's still major churn, it's nothing like it was when react first came out.
I looked at svelte when the hype circle started and decided to postpone using it for at least five years — these comments show it was a right decision.
It saves money and time to be conservative with these things.
> ...you can use as much or as little of it as you like... Stability as a Feature... No New Features as a Feature...
This is the way.
Having lived the alternative, I won't consider building anything significant on top of an abstraction that doesn't credibly promise these.
When the abstraction you've built on changes or fails, the thing you built breaks. When you choose an unstable abstraction, you're creating future bugs you'll have to spend future time on to resolve (and if it wraps the lower layer rather than sitting beside it, you have fewer options to fix them).
These aren't concerns for things that will be short-lived, or are small enough to replace if needed. But I've seen plenty of small and temporary things turn into large and permanent things when they end up being useful.
But the node ecosystem includes essentially everything that touches on javascript, both the bad and the good.
I don't think there are very many ecosystems that are guaranteed to have only good stuff. Regardless of ecosystem, the developer has to examine what is available and make wise choices.
I think the culture is so prevalent that I have to defend parent’s statement. Node itself, and npm which is a node project, are some of the worst offenders. It’s had abysmal stewardship imo, and one could argue this sets the tone for the ecosystem at large. Hack upon hack, config files of doom.
There are exceptions, but at this point the verdict is clear. It’s like the meme about Java being enterprisey and over-abstracted with factories. As far as stereotypes go, it’s true. (Or was, haven’t used it in forever)
I’m not even against JS, and much less the web. I think it’s the 7th wonder of the world. But the developer practices makes me want to tear my hair off.
I know there's plenty of junk, but if you opt out of the node ecosystem in its entirety, you're essentially opting out of most of javascript development as well, which is a substantial part of web development.
That's your choice, but you're missing out on a lot of good and useful things... just in terms of software development but also in terms of meeting whatever your business needs are (if you're trying to make money).
Javascript static analysis tools can be very useful (like TS and eslint). app frameworks can provide routing, UI frameworks, UI controls, validation libraries, etc. that you would otherwise have to implement on your own.
These are all part of the node ecosystem. htmx is part of the node ecosystem. IDK, lumping it all together doesn't make sense to me because there's a lot lost and little gained.
There is a great way to combat this, use libraries you've reviewed to have proper design and implementation, then ignore the rest. People rely on libraries for the stupidiest shit, and also are really afraid to go against the current flow. If you're not doing TypeScript/VueJS/$POPULAR_THING you don't know anything about JS and you're a dumb developers, which of course is very wrong. And stop listening to recommendations from lifestyle developer streamers who most likely got paid to recommend whatever they're babbling about.
I quite liked svelte 4. Svelte 5 might be even better, but I'll probably never find out.
I won't touch it if I can help it. No matter how good it is, I'm fairly certain there will be a svelte 6, 5 will be abandoned, and whatever issues crop up in it will not be addressed unless I move to 6... probably just in time for 7 to come out. I know this because that's what happened before, repeatedly.
I don't know if htmx is actually any good, but they are saying all the right things.
Major versions that change basically everything should be considered different projects and require a re-review. I remember I did this early with react-router, and I think when they changed the public API for the second time, we forked it and left it as-is, because they made their goals apparent.
If Svelte version 4 and 5 are very different, then they're "SvelteV4" and "SvelteV5", both on version 1.0.0, in my mind :)
"Pretty good" is good enough for most developers, but React has some issues that reduce developer experience (having to do your own memoization and a lot of hidden complexity that can impact performance) that require a huge engineering effort to solve (React Compiler has been in the works for years).
I'm also not sure whether the move from class- based components to functional components with hooks should've been part of the "regular" React or if it would've been better to do a hard break (e.g. a version 2.0), but I think the collective front-end developer world is still traumatized from the AngularJS -> Angular transition.
>But I've seen plenty of small and temporary things turn into large and permanent things when they end up being useful.
My experience is that probably more than 9/10 temp projects end up forever projects. My goal is never to work anywhere again that insists on just get it done quick and dirty "its temporary" ever again.
I don't remember where I stole it from but at work any time we're discussing something temporary I like to drop in a "remember there's nothing more permanent than a temporary fix" and it usually gives us at least a few more minutes of considering things carefully before pulling the trigger. Makes me feel better anyway.
I have a wood block wedged between my car's battery and battery mount because the new battery was smaller and I couldn't get the mount to adjust down. I cringe whenever I get the oil done but I don't fix it because it is good enough. I do feel dirty about it and every other weekend I think, "I should install a proper sized mount." But the battery doesn't wiggle. It works. It is a temp fix that has been there half a year. Code is even less visible to most, so even more out of sight and out of mind.
In modern development best practice, you'd refactor that bug fix, by moving the block of wood to underneath the battery where you can't see it any more. (And writing "node_modules/" on it with crayon...)
This perfectly captures the node_modules / JavaScript experience, because being underneath the battery would also stop it from working as intended and the battery would be loose again.
I've created a Django application using HTMX. Usually I'd jump to React or Vue. It was a great exercise and I can see where HTMX would be a great fit.
1. If you consider yourself a "backend developer" only and want to write the minimum amount of JS/TS.
2. If your application is simple. Yes you can do more complicated interactivity with oob swaps, but you end up with more complexity than you chose HTMX for.
For my next projects, I will still use Django but with React/Vue for pieces that need interactivity. As an example in my HTMX app, I wanted to add a profile image uploader. Lots of great frontend libraries exist to resize / modify your image before even uploading it to your server.
Finally, HTMX is just not testable the same way modern frontend libraries are. I've managed to write some decent tests using beautifulsoup, but it's night and day compared to vitest or jest.
This was my exact experience - loved it as a backend developer wanting to build simple frontends with minimal JavaScript (and I still recommend it for many use cases) but when I then tried HTMX to build a more complex application I found that the complexity that would normally be handled by a JavaScript framework ultimately grew and shifted to the HTML and, surprisingly, the backend as well.
For example, error handling in complex forms. When you have React handling errors you simply return a 400 JSON response with fields and reasons, or some other error message, and React decides what to do depending on the context, which it knows. When this responsibility is moved to the backend you now need to track the request location, state etc. and find the right fragment, which very quickly turned the code into a mess.
I think the choice of backend is also important. I suspect that Java (Spring Boot) made using HTMX much less pleasant than it would have been with something else, especially when it comes to templates and routing. Using Java for HTML templates (Thymeleaf or any of the other popular libraries) is something I will never do again.
Edit:
The analogy with jQuery is interesting. I feel the same way about HTMX now as I did about jQuery ten years ago. I used to plug jQuery into every project even if it was just to select elements or whatever, but whenever I used jQuery entirely over the frameworks that were popular at the time (Ember, Angular) I ended up with way messier code.
> When this responsibility is moved to the backend you now need to track the request location, state etc. and find the right fragment,
Maybe not? I'm just returning a 422 JSON response with fields and reasons and I have a tiny bit of JavaScript in the frontend that just plugs them in to the form with the built-in Constraint Validation API.
> I suspect that Java (Spring Boot) made using HTMX much less pleasant than it would have been with something else, especially when it comes to templates and routing.
IMHO one of the biggest advantages of using HTMX is not having to maintain three layers of test suites (backend, frontend, end-to-end). You just need to test that your endpoints return the right HTML piece. You don't need unit testing the frontend since you don't have that much logic there. Just rely on end-to-end tests as a complementary tool to check small pieces of logic on the HTMX code.
I’m not sure I’d agree. The HX attributes encode a lot of functionality and you want to check that they do the right thing together. You can test you get the right attributes in a response, but that’s only a proxy for the application doing the right thing, so you most likely still need the end to end tests.
The problem is that end to end tests are the hardest kind to write. At least if you have a frontend code base you can have some tests there and get some confidence about things working at a lower level.
> You just need to test that your endpoints return the right HTML piece. You don't need unit testing the frontend since you don't have that much logic there.
Only using the standard Django test client? I don't find this myself when I've had to work with HTMX code e.g. if you're using HTMX for your sign up form, it can be completely broken on the happy path and on form errors if the HTMX attributes are wrong, and the standard Django test client won't let you know, so you lose a lot of confidence when making refactors/changes.
That honestly sounds like a downside. Having to verify HTML as an output (in comparison to e.g. JSON) is brittle since it will often change just for presentation reasons. Having a clear and somewhat stable API (which is a boon for testing) is IMHO a strong reason for the SPA model.
> Having to verify HTML as an output (in comparison to e.g. JSON) is brittle since it will often change just for presentation reasons.
For HTML tests, if you target elements by their ARIA role, semantic tag, or by matching against the text/label/title the user would see, it should be robust to a lot of presentation changes (and does some accessibility checks too). It's much more robust than e.g. `body > div > div .card > h2` which are sure to break in tests and slow you down when you make changes later.
Not sure if this is what you meant, but you can't rely on only the JSON because you can't assume it's been properly transformed into the expected HTML.
In my experience snapshots have largely fallen out of vogue, at least as far as them blocking deploys goes. They're usually flaky, change often, are slow to test and it's way too easy to have false positives which lulls people into complacency and just regenerating the snapshots as soon as they reach a failure. I'm guilty of that myself, unless I can spot the breakage immediately I pretty much just regen the snapshot by default subconsciously because of how often I've had to do that for false positives
Then what's to stop you from making any unit test pass by just changing the expectations? The best testing technique in the world can't save us from developer error.
The problem with snapshot tests is that they tend to fail when something is changed.
One property of good tests is that they only fail when something is broken.
Snapshot tests aren't really automated tests, because you have to manually check the outputs to see if failures are genuine. It's a reminder to do manual checking but it's still not an automated process.
> The best testing technique in the world can't save us from developer error.
Sure, but using a testing technique that increases developer error is unwise, and snapshot testing has done that every time I've seen it used, so I don't use it anymore.
Then fix the test so that it fails only when something breaks? Do people not fix flaky, overly broad, or incorrect unit tests? How is a snapshot test any different?
I'm not sure you understand what snapshot testing is. It's a form of testing where you render frontend components and take a "snapshot", storing the output and saving it for later, then on the next test run, the component is rendered again and compared to the saved snapshot.
Any change that modifies the rendering of any component under test will break snapshot tests. It's literally just a test that says, "Is this render function still the same as it used to be?"
I'm not sure you understand how to capture snapshots at the correct level of granularity. If you have snapshots that are breaking for irrelevant changes, then by definition those changes don't need to be snapshotted, do they? Cut down the snapshot to only the relevant part of the rendered HTML so that when it fails, you know something broke.
It would still break if you need to modify that output in any way. Need to add a class for styling? The snapshot breaks. Need to add a new hx-attribute? The snapshot breaks. It's not tied to the logic, it's tied to whatever markup you output. You've reduced the surface area of the problem, but not eliminated it.
> If you have snapshots that are breaking for irrelevant changes, then by definition those changes don't need to be snapshotted, do they?
How often? All the time? Or relatively rarely? For most projects, it's the latter. We are not constantly churning the styling.
> Need to add a new hx-attribute? The snapshot breaks. It's not tied to the logic
An `hx-` attribute is logic. That's the point of htmx.
> You've reduced the surface area of the problem, but not eliminated it.
That's a risk of any kind of unit test. You can always have false positives.
> You're so close to getting it.
That tests should be fixed until they're robust? I'm not a fan of the learned helplessness of the 'We couldn't figure out how to do XYZ, therefore XYZ is a bad idea' approach.
Do you have experience with snapshot tests? If not, you should try it out for a bit and see what we mean, you'll quickly run into the situation we described.
If you introduce a new feature and have a new button on the page, for example, the snapshot test will fail (by necessity, you're changing what's on the page) because the snapshot doesn't match the current version with the new button, for example. So, what you have to do is regenerate the snapshot (regenerating it will always make it pass).
The problem is in my experience, that these kind of tests are massively unreliable. So you either fiddle with tolerances (most testing libraries let you set a threshold for what constitutes a failure in a snapshot) a lot, or you manually have to hunt down and pixel peek at what might've happened.
As an example of what usually happens is that, at some middle step of the test an assert fails because some new code causes things to render slightly out-of-order or delayed in some way. Ultimately the final product is good and if it was an intelligent system it would give it a pass. The unit tests pass. Even the integration and E2E tests pass, but the snapshot tests fail because something changed. The chance that this test failure is a false positive is much, much higher than the chance of it being a legitimate failure, but let's assume it's legitimate like the good citizens we are and try to hunt it down.
So, you go through the snapshots, 1-by-1, setting breakpoints where you think things might break - note that this process by itself is painful, slow and manual, and often running snapshot tests on your local machine can break things because things get rendered differently than how they would in CI, which leads to an extra set of headaches - What happens here is that you're testing an imperfect reflection of what the actual underlying app is, though, because a lot or most of it will be mocked/hoisted/whatever. So sifting through what is a potential breakage, and what is just the quirk of the snapshot test is basically a gamble at best. You spin up the app locally and see that nothing looks out of the ordinary. No errors to be seen. Things look and behave as they should. You have your other tests, and they all pass. So, you chalk it up to a false positive, regen the snapshots, and go on with your day.
The next day you add some other thing to the page. Uh oh, snapshots fail again!
Rinse and repeat like this, and after the 50th time sitting there waiting for the snapshot to be captured, you decide there are better ways to spend your limited time on this mortal plain and just say "Fuck it, this one's probably a false positive as well" after taking a 2 minute look at the page locally before hitting the repacture command again.
I legitimately don't think I've ever actually seen a non-false positive snapshot test failure, to be honest.
Snapshot tests are even more sensitive to flakiness than E2E tests but flakiness is still a bug that can (and probably should) be fixed like any other.
As an example - the different browser you have running locally and in CI? That's a bug. The fix is to run the browser in a container - the same container in both environments. You can probably get away without this with an E2E test. Snapshot test? No way.
Ive seen people decry and abandon E2E tests for the same reason - simply because they couldnt get flakiness under control and thought that it was impossible to do so.
I dont think it's intrinsically impossible though. I think it's just a hard engineering problem. There are lots of nonobvious points of flakiness - e.g. unpinned versions, selects without order bys, nondeterministic JavaScript code, etc. but few that are simply IMpossible to fix.
> 1. If you consider yourself a "backend developer" only and want to write the minimum amount of JS/TS.
This is a great point and should be underscored more. I think generally the HTMX vs React/Vue/Svelte argument gets undercut when people don't express their innate bias on which part of the stack they want to give more control to. HTMX is great if you're pro-expanding the server; JS Frameworks if you're trying to expand it from the application layer.
With the BeautifulSoup tests I can run 1000s of tests in seconds. Cypress/Playwright are wonderful for e2e tests, but not comparable to simple unit tests you'd have in React/Vue. I find that the BeautifulSoup tests are a decent middle ground.
But with beautifulsoup you don't test the interactions at all. You only test the rendered template which is nice, but doesn't tell you if any button actually works the way you expect.
I've successfully used (for 3+ years in multiple projects) an approach similar to BeautifulSoup's get_text() function to assert the whole visible text of a component. You can implement it in other languages with a few regexes.
One addition makes it an order of magnitude more versatile: a way to visualize non-textual information as text in the tests. For example add a data-test-icon attribute which contains the replacement text that should be shown in tests. Another method is to parse the HTML and write custom visualization for some elements, so that you get useful default visualization for at least form elements and such, without having to repeat the data-test-icon attribute every time.
They're both fantastic expansions of what server-side rendering can do. They can't really do work as nice as what React can, but you can get perhaps 85% of React for 5-10% of the development time. And a big increase in usability of your app.
As I dont do frontend work, how do you "test" anything without an insane amount of browsers/hardware realistically ?
If I was to write tests, it'd be basically http get/post/put/delete requests and measuring the responses are what I expect.. how can HTMX be any different here ?
How do you "test" a button works without a browser engine ? Every browser engine ?
but they're about as reliable as you can expect: it's difficult to keep up the pace with the big three (or two) on standards compliance, and they usually don't even try.
So the only reliable solution is a headless Chromium, Firefox, and/or WebKit-based noname browser like the sibling says.
Anyone got a good feel for the htmx accessibility story at the moment?
I'm interested in using it more, but I want to be 100% confident that I understand how to get htmx sites to work well with screen readers. I worry about things like fetching new data into a page not altering the screen reader user in the same way as refreshing a page completely would.
I'm not interested in whether or not htmx uses the correct ARIA attributes - I want to be confident that those ARIA attributes (or similar) do the right thing.
My ideal is still to use JavaScript libraries where the documentation not only describes how they work with screen readers, but is accompanied by video evidence showing the experience a screen reader user gets for different problems solved by that library.
This is one reason I created https://alpine-ajax.js.org.
A few years ago there were a lot of examples in the HTMX documentation that discouraged accessibility and progressive enhancement. Stuff like like clickable <div>s, ignored keyboard focus, lack of screen reader announcements.
There’s been some improvement latel, but I still think the library has a lot of foot guns for new web developers.
tl;dr htmx is better than a lot of alternatives, but Simon is right, it can improve this story and it has a responsibility to do so.
As a framing device: any interactivity that is not described with HTML is interactivity that someone is responsible for making accessible (which you correctly pointed out). Unlike JS frameworks, htmx encourages the developer to solve problems with HTML first, so the inaccessible surface area that the developer has to worry about is going to be much smaller on htmx-based applications than it is with JS-based applications. That's a pretty strict win from where a lot of the industry is right now.
That having been said, I agree with you (and disagree with a lot of our defenders in the comments) that thinking about this is in-scope for htmx. In fact, I'm a firm believer that libraries are exactly where responsibility for implementing ARIA attributes live. The average web developer should not have to think about this at all—they should be able to use declarative abstractions and trust that they are annotated correctly for screen readers. This is the only system that scales, and htmx should adhere to it as much as possible.
Ideally, htmx would just add the polite notification attribute to the elements it processes, and give an easy way to customize that. I think it's basically possible to do this in a backwards-compatible way (first as an extension) that aligns with the maintenance strategy outlined in this essay. And I do think we can improve the documentation as well.
I would argue that frontend libraries like htmx and React are not the place to build in ARIA attributes patterns/behaviours. In fact, none of the Big Ones do anything specifically w.r.t. announcing changes. See https://news.ycombinator.com/item?id=42625070
What would be the appropriate place, imho, would be component frameworks that are built on top of htmx. FastHTML is an example; they already have htmx integration and they talk about server-side components. If we look at a popular one in React, this is what they do: https://blog.logrocket.com/aria-live-regions-for-javascript-...
Thinking about it in terms of dream-html[1], it might look like:
let announce msg =
p [
class_ "announcement";
Hx.swap_oob "innerHTML:.announcement";
Aria.live `polite;
] [txt "%s" msg]
(* POST /purchase *)
let purchase request =
let thank_you_fragment = ... in
Dream_html.respond (
(* Join fragments together *)
null [
thank_you_fragment;
announce "Your purchase has been successful!";
]
)
I'm thrilled to hear you're thinking about this. I really like the philosophy of the project, very happy to hear that reducing accessibility friction is a value you care about too.
Yeah, any website that uses JavaScript to load page elements needs to solve this. My hope is that a library like HTMX can help reduce the friction in implementing the best possible patterns for doing so.
See the proposed moveBefore API [1] which is meant to solve those issues at the platform level. In the meantime, htmx has their morphdom extension, which I’d say is a must when replacing any page content with interactive elements within. Aside from that one major gotcha, the main issues with htmx are the poor accessibility of the examples in the docs [2]. In particular seeing so much ARIA without the corresponding keyboard support.
Handling ARIA attributes is out of scope for HTMX. It is your responsibility to include ARIA attributes on the HTML you return and swap/transclude.
As for handling dynamic content for screen readers, focus management is already a thing, and is in the scope of browser standards and the HTML your backend returns. As before, it's your responsibility to manage this. HTMX will neither help you nor get in your way.
HTMX merely extends hypertext functionality to its (mostly) natural conclusion. It is not a component library, or a framework for building components, or a site building framework, or...
You can use other tools to enhance and audit accessibility, but their use is orthogonal to HTMX. I think web developers in general are very used to frameworks abstracting a ton of complexity, but HTMX is not a framework so much as a standardized set of tools for specific low level problems, it is not a one stop shop.
In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this.
Leaving accessibility up to the end developer feels like a genuine missed opportunity for me here. One of the great things about NOT using a JavaScript library is that you can rely on the browser's default accessibility features for forms and links. Those benefits are the thing I care most about when considering HTMX or jQuery or React or Vue or similar.
> The server will bulk-update the statuses based on the values of the checkboxes. We respond with a small toast message about the update to inform the user, and use ARIA to politely announce the update for accessibility.
If you check the Server Requests panel it also shows the responses and the ARIA attribute they include.
The key is to mark all live regions statically before doing any htmx requests, then injecting the response HTML inside those regions. Then they are announced by the screen reader. This is nothing special to htmx of course; every app needs to work the same way.
> In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this.
You can refer to the WAI-ARIA standards.
> Leaving accessibility up the end developer feels like a genuine missed opportunity.
This doesn't compute for me. What would HTMX even provide? It's a set of attributes that extend the behavior of form submission to other elements and all request methods.
> HTMX or jQuery or React/Vue
These aren't the same kinds of tools. They address fundamentally different things. Handling ARIA automatically for you isn't in scope for any of them.
> > In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this.
> You can refer to the WAI-ARIA standards.
Every time someone asks for concrete a11y advice for concrete situations, some joker refers them to WAI-ARIA. This is ridiculous! That document is extremely hard to parse, and it offers absolutely no guidance wrt which parts matter the most, or, say, how the various real screen readers used in the wild behave. Please stop doing this. Accessibility is hard to get right! Making people feel like they're idiots for trying is very unhelpful.
And then you get to WAI-ARIA's practical examples and they have a yellow warning intoning "not intended for production environments" and there "may be support gaps" in assistive technology: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/c...
> That document is extremely hard to parse, and it offers absolutely no guidance wrt which parts matter the most, or, say, how the various real screen readers used in the wild behave.
No, but it does enumerate what is available which is the starting point for figuring out what is relevant to your use case.
If you want tutorials or guides relevant to your particular use case you can seek those out, but to understand them you will need familiarity with the set of available attributes and where they are or are not permitted.
Many (most?) tutorials online have flagrant violations of the specification. We need better ones that actually emphasize understanding WAI-ARIA and not cowboy markup recipe books.
> Please, stop doing this.
No, I will not stop telling people to familiarize themselves with the primary reference material. Reading technical documentation and specifications relevant to a project is not an optional step.
It is not complete in the ways you describe (actually testing real screen readers is crucial), but it is absolutely essential reading to begin with.
> Reading technical documentation and specifications relevant to a project is not an optional step.
Well, I'm competent at HTML and CSS yet I never properly read the HTML or CSS specs either. Specs are generally a terrible place to learn a technology.
I simply don't understand how it's possible that the people who seem to care most about accessibility also seem to deeply, strongly believe that doing good accessibility ought to be very hard and time-consuming, and you don't deserve to call yourself a proper web dev without going through the rites. It's... not very accessible!
> Well, I'm competent at HTML and CSS yet I never properly read the HTML or CSS specs either.
I would strongly recommend you do! Most web developers are unaware of a good deal of just what all is available to them in those specs (especially HTML).
Referring to the ARIA standards doesn't help me answer the more important question: will what I'm doing work in screen readers or not?
I feel completely starved of information here. I care about accessibility. I want to build a web page where clicking on a tab refreshes a subset of that page... and I still can't find a really good guide on how to do that in a way that works in screen readers, that's accompanied by a video (ideally multiple videos, one for each common screen reader) showing the experience I can expect my users to have from that pattern.
HTMX actively encourages that pattern, so I'd love to see the project also embrace helping developers do The Right Thing with regards to the accessibility of that pattern.
> I feel completely starved of information here. I care about accessibility. I want to build a web page where clicking on a tab refreshes a subset of that page... and I still can't find a really good guide on how to do that in a way that works in screen readers
More generally, I often see people calling others "lazy" for not making websites accessible, but I personally found it hard to get my head around the WCAG recommendations, and I work with designers/developers all the time that don't know how to follow the WCAG recommendations even when you point them to documents and tutorials.
It's like nobody wants to admit it's difficult, and that's not even getting into screen readers still having many inconsistencies for basic UI patterns.
There are some sites that try to document what works and doesn't in different screen readers (e.g. https://a11ysupport.io/tests/), but even then it's still not easy knowing what to do and I don't know of an authoritative up-to-date site.
> I work with designers/developers all the time that don't know how to follow the WCAG recommendations even when you point them to documents and tutorials.
> It's like nobody wants to admit it's difficult, and that's not even getting into screen readers still having many inconsistencies for basic UI patterns.
Accessibility IS hard.
It feels sometimes like nearly everyone involved thinks they'll just read a few good blog posts and know how to make sites accessible. Then the struggle is due to not having read good enough blog posts.
Everyone wants a quick "fix" to a lack of education. Nothing replaces familiarizing one's self with primary source specifications, and most crucially, spending significant time trying out real screen readers.
I think what they are trying to say is that it has very little to do with htmx or react of whatever framework. None of it can handle accessibility automagically. Its like asking if it can write html for you - its different problem and a skill. But skills in accessibility apply to all frameworks.
Pointing at the ARIA spec as a way of writing code that’ll work with all assistive tech is like pointing at the HTML and CSS specs circa 2005 and saying that following them will make your site work in all browsers.
> I feel completely starved of information here. I care about accessibility. I want to build a web page where clicking on a tab refreshes a subset of that page... and I still can't find a really good guide on how to do that in a way that works in screen readers, that's accompanied by a video (ideally multiple videos, one for each common screen reader) showing the experience I can expect my users to have from that pattern.
I completely agree that this is a pain point. In general, high quality documentation is lacking. I am not however convinced that this is a problem that can be automated and abstracted away. Neither am I convinced that it's one we should necessarily try to hide. It won't win me any favors but I think the issue here is simply an endemic skill and knowledge gap. Shifts in culture via higher educational curricula and stated quality attribute priorities within companies will do more good here than anything else.
Accessibility is a quality that needs to be built in from the start. The good news is that provided your HTML is sane and not a mess of class tagged DIVs, or you're building a pretty straightforward document-like navigation/content/etc site, you really only need to declare attributes to handle the places you do something unusual. The defaults are generally correct.
Much of this "unusual" behavior that needs special treatment is within custom components (e.g. a custom date selector widget with plenty of invisible divs used for layout of the calendar days can be inscrutable to a screen reader without hinting) and is the responsibility of component library or framework producers. Some issues here run deeper, like properly correlating ARIA attributes in shadow and light DOM. But that being the case, such component libraries aren't even necessarily suitable for many sites (either too complex, or make too many mismatching assumptions).
The bulk of the remaining accessibility attribute slinging that needs to happen has to do with the overall site layout (especially reactive layouts). I don't know of any framework that will handle this for you in a satisfying way for anything sufficiently sui generis.
I think the tough but true answer here is "the people building the site should have at least skimmed the WAI-ARIA standard, and be using an auditing tool, and know what to be thinking about as they design the site from the start".
Everyone needs to read this spec and then live and breathe its tenets … sure. This reminds me of the time when we fixed the footguns with C by making everyone into better developers.
That guy is asking you if replacing a part of the html with some other html alerts screen readers to the change.
It’s a reasonable question and you could share what you know about how screen readers react when this replacement happens. You could write some documentation on how to alert them, some best practices to follow.
Instead you say read the fucking manual, as if that
helps. You put on a veneer of caring for accessibility but it seems you care about the “purity” of htmx more.
Frontend frameworks often do spend a lot of time thinking about the accessibility concerns associated with client side routing, so it's not absurd to consider this question in scope for a frontend library that handles DOM updates.
Some of this will have to be bespoke work done on a per-site basis, but I'm not sure I'm comfortable with the idea of completely punting this responsibility to developers using htmx, even if it does make philosophical sense to say "this is scope creep", because ultimately users with disabilities will end up being the ones whose experience on the web is sacrificed on this altar of ideological purity.
> That guy is asking you if replacing a part of the html with some other html alerts screen readers to the change....It’s a reasonable question
Of course it is, but it's like asking if using React.js will prevent SQL injection attacks. They are orthogonal things. Making screen readers announce things is controlled by the HTML you write, not by htmx.
It's actually like asking what a database library will do to prevent SQL injection attacks. And the answer is simple - "don't do string interpolation yourself, instead use the `(?, ?)` syntax". If you use that the SQL escaping will be taken care of automatically by the library. If the database library said something idiotic like "read the spec and implement your own SQL escaping logic" it would be a dereliction of duty.
Make no mistake, a frontend library like htmx has a responsibility to not break the front end from an accessibility perspective. If existing screenreaders break when you replace HTML then the htmx approach is broken and htmx needs to address that.
Conceptually htmx is closer to Fetch API + set innerHTML than it is to a 'frontend library' like React.js. Do people complain that setting innerHTML from JavaScript breaks screen readers? Of course not, they set up aria-live regions correctly as shown in plenty of accessibility documentation. htmx can't make the decision for you what your aria-live regions are and what text should be read out when the content changes, you need to decide that yourself.
Do people go after these frameworks saying they need to handle breaking screenreaders by dynamically updating content? Of course not. Setting live regions is the responsibility of the web page creator, not the framework.
Yes, I do go after those frameworks saying they need to at the very least help their users understand what they should do. I'm disappointed by any JavaScript library or framework that doesn't provide good documented examples for this, which is almost all of them.
"It won't win me any favors but I think the issue here is simply an endemic skill and knowledge gap."
My problem with that is that, as you can hopefully see, I am very motivated to learn how to do this... and yet I have not managed to learn it.
"Learn how to do it" only works if there are clear and obvious resources we can point people to that will help them learn what the need to learn. The ARIA spec is not that.
This also feels like an inherently solvable problem, which is why I always take any opportunity to put it in front of people that might feel incentivized to help solve it.
There was a time when I didn't know anything about web accessibility. But I learned by reading, trying out small experiments, and using a screen reader to check my work. If I can do it, you can certainly do it.
> This also feels like an inherently solvable problem
It shouldn't, especially if you don't know anything about web accessibility. It's hubris to think that something we know nothing about should already have been solved, why hasn't it? Is everyone else just an idiot? No, of course not. It's a complex and nuanced problem. Not the basics like always put an `alt` attribute in your `img` tag, those things are easy. But when you insert dynamic updates with JavaScript into the mix, it gets more complex.
The thing I was describing as a solvable problem was the lack of easily discoverable, clear tutorials - especially for the various libraries and frameworks that encourage patterns like updating small areas of a page that can cause problems.
And yes, I agree it is not the clear and obvious resource we can point people.
We DO need better "guide" format documentation, rather than dry technical reference. Nearly everything I've seen online is in very poor shape or outright wrong.
I share your feeling that it is solvable, and I also hope that people will help solve it.
But I'm sure of one thing: the people who write that documentation will be familiar with the specifications and refer to them (among other sources) while writing.
An "Accessibility Book" (like sections of the Python and Django docs, or the Rustonomicon for unsafe Rust) would be a fantastic resource and I hope someone writes it.
I understand screenreaders have a set of standards, aria tags etc - but are the next generation of AI screenreaders (I’m sure some already use AI?) going to replace the need for these tags, and just read a page as a human would?
I’m very grateful for how htmx by focussing on a very specific part of “interactive JavaScript on the page” was able to shift a whole bunch of similar JavaScript actions into an elegant abstraction that rested so neatly on all the existing work that had/has gone into developing html. And even for having the clarity to name it as such.
In a way it’s a bit of a lesson in managing complexity, rather than seek to be “the next JavaScript framework to replace all the others with its theory of the universe”, it instead carved off a smaller slice and said these Thich are related, we’re just for dealing with these thing, nothing more.
In one swoop a whole raft of manual developer programming workload was packed up with a new easier to understand abstraction.
Kudos to the team, I’m grateful for the considered way you’ve developed this tool for the rest of us.
how do you feel about its adoption in things like https://fastht.ml/ ? i was open to the idea at first esp with jeremy howard's endorsement, but once you start updating multiple things on a page at once i felt like i was fighting htmx rather than it helping me. components are a really neat paradigm and just bc react is currently in a complexity upswing doesnt mean we want to throw the baby out with bathwater
thats not what the js world traditionallyunderstands as a component - eg - it doesnt take an argument that, when the argument value changes, the component rerenders. you still have to wire all that up with htmx (again, as far as i undersatnd it, having spent a week with htmx)
You can do that with HTMX through events and hx-trigger but it just sounds like HTMX isn't the right tool for what you're trying to do. I've seen a lot of instances of people trying to use HTMX to replace react/vue/etc. and not understanding that they're trying to solve for very different things.
HTMX highly encourages client side scripting for dynamic updates if that's what your UI needs. It's very pro-JavaScript even though a lot of people get confused and try to use it to fully replace JavaScript
I think web components would be an excellent pairing with htmx. You get some kind of component abstraction (admittedly janky in some ways, though libraries like lit or atomico make this much better). But crucially you get automatic upgrade/initialize behaviour whenever the browser encounters a custom element. So the backend can just send down the custom elements as plain html, you don't need to wire anything up, the browser will bring them to life.
The problem is web components (which are great) are not so good for seo. You would be losing the auto SSR benefits of using your own component abstraction in any backend language.
That to me sounds external/additional to the idea of a component.
You can do the component side on your backend language of choice, and output html like htmx likes it, and it works (have done it in Python, for example).
It is extra work, but it works with a bit of programming.
I am still trying to get HTMX adopted in a ~ 800 employee software development company. And while we do not yet have a project using HTMX in production, I like to use it a lot in thought experiments with mentees: Could you do it with HTMX / Fragments? If yes, how would you design it? Do we REALLY need an SPA?
I do think "use HTMX" is a tough sell for a 800 employee company, just because it doesn't really solve issues on it's own. (Imagining the pitch is "add HTMX to an existing project") Going all-in on hypermedia definitely means the service that serves your application needs to be more than just a JSON parrot. Templating HTML and sending the right chunks back is hard to do if those services aren't built around being hypermedia services.
I really like turbo-rails [0] (the ruby gem that Rails 7+ bundles in for turbo support, meaning helpers that make turbo frames/responses a native "thing" rails understands) because it's a complete solution. There's at least some obvious structure to build off of, and I'm not stuck trying to build up my own framework on the BE for my newly simpler FE.
django-htmx [1] also fits in this case too. I feel like any honest pitch of HTMX should involve some BE solution as well.
I dont intend it to be an all-in, but I do believe it could do the job in 50% or more cases just as well as any SPA framework. A lot we do is "just crudl" with some sprinkles on top.
A large chunk of our business comes from Spring Boot, so we are experimenting with JTE - looks decent so far (Thymeleaf feels just old nowadays).
My sell is pretty simple: You have regulations coming up in europe which will require you to keep applications up-to date and secure. Extending your SBOM by 1k NPM libraries is a huge cost. I want to get rid of that.
I tried to get HTMX adopted for a new project but the unanimous response was "what is this? why not React? everyone knows React. period" and most of my arguments for HTMX were ignored, because to most people, HTMX looked like some obscure, yet another JS framework created last week, with questionable future.
The reason is because all new technology is a staffing and training problem management needs to solve. Someone has to maintain your thing after its built and be ready when you leave the organization. If React can solve the issue in a similar timeframe and level of effort and it is easy to source React developers then obviously your proposal will be rejected because React is simply far easier to deal with from a training and staffing perspective for what you are trying to do. You need more merits to warrant the introduction of new languages and frameworks.
Of course you get pushbacks. Is there any *real* advantage, technical or otherwise, at an organization level, of adopting this new model of creating web pages, other than your personal preferences? You are moving away from an established system with tools that everyone is familiar with, to a system that much fewer people use, with no clear performance/maintenance/management benefit (at least not demonstrated). Maybe you don't like writing JS/TS, but plenty of other people do, and they don't need to cater to your preferences.
People need to spend time learning this tool. They need to be proficient with it. Your new stack might need to still work with existing code at some point. That means training, overhead, ramp up and potential risk in a less established area. Why would people do that?
You should be thankful you didn't get warnings from your boss for messing around instead of actually pushing features out.
Very anti React person went for Svelte but the kind of modularity React offers, HTMX can't hope to match especially on larger projects.
Modern React is too simple. A component is just a pure function taking arguments and returning UI as JSX. The only other thing you need to know is few hooks.
maybe you can send me to the right tutorial. I'm a backend, distributed systems engineer. I have worked on eye-watering scale. React is anything but simple to me.
I tried create-react-app, the thing built and downloaded for several minutes, and then there was a nest of file relationships that I didn't grok. It seemed like any change required three files to be updated. Lots of ancillary things like bundlers, packers, tree shakers, lions, tigers, and bears, oh my. After an hour, I didn't get what I was doing. Somehow, altering this function over here made this other thing over there go "moo."
I used to do web development back in like 2001. I understand the web, http, css, html, and basic js. I'm not up on all the latest, but I have a very firm base.
I got htmx working and pretty much fully digested in the same amount of time I wasted on React and have produced a working prototype. I find htmx to be like how the web used to be. It makes sense.
FWIW, create-react-app is overloaded with every package you could ever potentially want to use for some weird reason. It's way overkill and I wouldn't recommend using it.
It's much better just to use Vite with React as a plugin. Then you only need to install three React packages to get your app going.
The best tutorial I've used was "Road to React" by Robin Weiruch. His example app you learn is how to build a Hacker News front page. Very clear and it goes step by step.
Most of the tutorials online are all over the place, or mix Class tutorials with Hooks tutorials, or starts adding in things like Redux (which aren't needed).
The person you're responding to is correct, at it's core React is very simple, especially if you just stick to hooks. Most of my code is just bog standard HTML (as JSX), CSS and JS with a few React hooks thrown in.
FWIW, I've been doing frontend dev since '94 and personally find React jives the most for me and how normal HTML/JS/CSS work. I can see why people would like HTMX, but I've never liked overloading HTML attributes as some strange event model. But it's good there are choices.
Create React App should not be used because it is no longer maintained. Here is its GitHub repro: https://github.com/facebook/create-react-app/commits/main/ . It has had very few updates since July 2022. This is bad because it needs constant updates because it depends on a large number of packages and those packages are constantly releasing security updates.
React has very good documentation and an excellent tutorial. Here is a link to it: https://react.dev/learn . I recommend doing the exercises. They really help you learn React.
> Modern React is too simple. A component is just a pure function
React is simple only in some mathematical theoretical sense, but not for understanding by human minds which fundamentally operate imperatively ("if I click on this, load data X from the server and show them to the user...").
You can get some hello world example relatively easily, but you hit the complexity wall quite quickly (need to know "some hooks" - some, like useEffect() are very complex, yet often needed for basic things). The worst of all is debugging with stacktraces making no sense with it all being from the React itself, not your code, not tracking some logical pathway.
(I'm saying that as someone who generally likes React and would choose it for a new project)
useEffect is simple. If I recall correctly, with no arguments it is like onMount and with the dependent variables listed in array, it would be executed every time any of the listed variables change.
try passing state around the component hierarchy and see how simple it is. HTMX makes it easy but centralising the state in one place ie the server. try coming back to your code base in a year or two and see how simple it seems then :D
Fully ack. But this can actually be turned into something good imho: I try to challenge all layers (Analysis, UI / UX design) on simplicity: "Do we really need X parts of the page all be affected / updated by something? How could we design it differently with locality in mind? Can we simplify the state somehow?" -> I think that the resulting solutions are often simpler, cheaper, and work just as well.
> It is not good for "and these other related elements need to update"
That seems a bit backwards, no? Why can't those other elements manage their own updates? You can have the server respond with an `HX-Trigger` header to dispatch an event and any elements that care about that event can listen for it. Far simpler than trying to coordinate surgical DOM updates in a single HTTP request.
Events form the backbone of the browser environment and leaning into that model makes a lot of things much easier
To a certain extent, it works, but there's definitely a point of complexity that you can hit in the app at which it becomes painful. Those are the kinds of apps where htmx is just not a good fit.
To be fair, it's not an unfair response. Being able to hire for a technology, and having a large community around the tech stack you use has tangible value.
HTMX might not be something that will vanish in a week, but it's also nowhere close to a mainstream framework.
the reality is that the only way to prove htmx is around for the long term is to stick around for the long term, and I hope this essay contributes towards that.
We'll see how this years JS rising stars shakes out.
I built an HTMX fragment framework for Django. It allows you to render a fragment, and automatically serves the fragment separately for live-updates. I'll open source it tonight and post back.
In my opinion, HTMX + custom elements does everything React does but better, and is a billion times cleaner.
People are commenting about "no new features as a feature", and I agree, but even better is this:
> People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed
Frickin A! Nice to see somebody pushing back against the trend of "if you haven't updated your software in the last five minutes you're on an unsupported configuration".
Why programmers like cooking: You peel the
carrot, you chop the carrot, you put the carrot
in the stew. You don't suddenly find out that
your peeler is several versions behind and
they dropped support for carrots in 4.3
A) New library versions are roughly as likely to introduce new bugs, as they are likely to fix old bugs. (If not, why are there still so many updates, you should be running out of bugs ...)
B) If you run into a bug, update that library, then look into fixing it and offering a PR with the fix. Easy-peasy.
Compared to: oh this is a bug in a library that's fixed in an update ... but then we need to update another library it depends on, but that requires an update to nodejs, but that requires us to update some other libraries, which introduce a new more serious regression, so we can't unless we re-write to remove that dependency ...
More reason to prefer a more deliberate release cycle! Focusing on security and stability restricts the area available to bugs significantly more than chasing hot new features all the time.
And also helps make for minimal changes when you ultimately find you need to move on from your current version. Probably why a lot of people stick with emacs/vim/whatever over every new fangled editor that comes out
>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.
I have been calling for this for a very long time even during pjax era. I hope that is not only an ideal but a realistic pathway forward. Chrome / Blink or Safari / Webkit. If we could just get one of them to implement it as experimental feature. How could we push this forward?
JPEG XL and HTMX in HTML, along with some sort of basic rich text editor for everyday writing is what I want browser to be included by default.
I don't want to bring politics into this, but I find the hype behind HTMX eerily similar to the populist vibes I get reading what their voters write.
There's this vague general sense that the "Web used to be simple" and that "Everything is so complex now". There's even an enemy that can be pointed at: React and various other frameworks/libraries and JS tools. Sometimes even JS itself isn't safe from this.
Though I can never find myself agreeing with the arguments (if any get presented at all). There's a reason we're writing web APPS instead of web SITES now even if you might dislike it. Just as there's a reason the world itself is now more complex now.
Ultimately I don't hate HTMX or the people who want to use it. Though to me the experience of actually using it is awful. I would ask people that they don't pretend that the backend ecosystem is any different from JavaScript. By the time you've chosen the language, debated the backend framework/chosen your templating solution and DB library and build system you could have gotten through the decision paralysis for JS too.
i think i've been open and honest about when the hypermedia approach is appropriate and when it isn't and I've been open about posting bad experiences with the library:
populist or not, i think the htmx website holds up pretty well when compared with other libraries/frameworks with respect to honestly outlining its pros and cons
When you are writing web APPs, you don't have to move as much logic to client as possible.
I was writing web apps in 1998, with table layouts, almost no CSS and no JS.
Of course, it was simple. It was so simple you can't imagine how. And it was the simplest in the golden age of MVC frameworks (like Django, Rails, Symfony) some 10-15 years ago. Since that, everything went downhill.
Building sign in form or some simple form with validation and saving in database was 2 hours of work, 4 hours with testing and deployment. Salaries of devs were 1/4. Now, it takes 2 days to make a simple form, backend API, sync two states, run it via myriad of builders and minimisers and deploy it to production.
Development now is 4 times less productive, 16 times more expensive for marginally better UX.
This simply isn't true.
You are stuck in the past and unwilling to adapt and learn new, in fact, better alternatives.
I'm currently using Go with Ent and Gqlgen and Relay extension on the backend and React vite with Relay graphql client as well as React-oidc-context for oidc with zitadel as the oidc idp.
It doesn't take 2 days to make a simple form.
You need to get put your comfort zone and learn.
I built a classifieds site in 3 weeks. Including admin ui.
I'd call that as productive as it gets.
There's currently as library in the works where you will be able to tell generative AI to make a frontend just from showing it the graphql schema.
I am not stuck in the past. I moved to Clojure and jumped to devstacks just like everyone else.
Speaking of generative AI, I use and pay for v0 for frontend generation, tried Contember to generate backends from specification (the CEO is a guy I know for almost 2 decades), I pay for Cursor, ChatGPT, Claude Sonnet. I moved from Bootstrap to TailWind (which I don't like, to be honest).
But honestly, many things are just much slower than something like Rails/Django/Laravel+Bootstrap.
I mean webpack is slow, and css can be annoying sure, but c'mon, 2 days? I'm having trouble seeing that take two days unless you're doing a lot more than a form with two text input boxes and a button for signup and one for login in the modern version, which would make it an apples to oranges comparison.
2 days is fast. OP left out that most companies nowadays run a separate front end team, so now you need your backend team and front end team to have a meeting about what proper JSON should be returned, then the front end mocks that response and implements the form behavior, all the while the backend implements server functionality, then someone else (usually) tests this integration, then someone else deploys it. If nothing in that multi-team communication pipeline breaks you’re very lucky.
If you can all get that done in 2 days you’re running a very fast dev team. Minus the QA and DevOps team my point is that a SPA/JavaScript-heavy web app is not only a technological choice but an organizational one. Things used to be faster because there were fewer divisions in the software, therefore fewer divisions in the organization.
Expectations have also changed in various ways since "the simple days" when devs were the product managers, the implementors and testers all in one. Some things are better now, some things are worse.
I used to be able to churn out a form, naively, in two hours because I could just implement the elements, inline style them, give them a name and then go implement the backend form handler. Now there's a checklist of requirements: does it implement our design system, does it have test id attributes, is it responsive, does it work with password managers and auto populating form fillers, does it support internationalization, does it support multiple languages correctly, does it provide client side data validation, does the server return errors correctly and how should they be displayed, does it have rendering tests, does it have end to end tests, and so on and on and on.
Most of this isn't needed for a personal project or proof of concept but for a reliable product that millions of people use globally, a lot of it is table stakes or legal liability. You can certainly do it server side too, but the two hour effort window is still gone.
It's not just 2 input boxes, unfortunately. It's also a backend part, adding sessions, requiring the user to be signed in. It is also sign out functionality.
In MVC framework, you just annotate a bunch of controllers, import Sign In and Sign Out functionality, and you are all set.
Another examples might be building data grids, CRUD functionalities, or more complex validation situations. Back then, you designed database, generated CRUDs, it automatically added Bootstrap CSS compatible classes. You added one beforeSave handlers to add extra logic, and it was done.
We web developers had to be competitive, because our competition were people using tools like Delphi, where you could drag'n'drop 30 screens in a day. It was ugly (default Windows 98 WinAPI look), it wasn't responsive, it wasn't prepared for people with disabilities, but it was hyperproductive.
Right… I think HTMX is cool and would like to try it. But the argument that “we need to go back to when things were simpler” just falls so flat to me. I remember the Web 20 years ago. It was pretty bad and ugly and slow and clunky and unintuitive.
We’ve made a lot of progress since then thanks in part to the powerful front-end state management and rendering solutions that are now standard. And if the argument is “we don’t need all that, I prefer simpler web pages…” then I just think you may have a totally different preference set from the average user. Normal non-engineers like sleek modern interfaces, not Web 1.0 forms and links and reloads
20 years ago we were using the likes of PHP4 or Classic ASP or perhaps Perl for server-side languages. Possibly the early days of VB.NET (ASP.NET) being a thing.
Some sites created 20 years ago were still not making use of AJAX, either. If they were, in very specific ways. It is more likely to be using IFRAMEs back then to achieve partial refresh.
Today, the difference is that we still apply "the old ways" building websites but with modern languages + htmx. This is the difference.
When I look at websites I have created or inherited, all I see if bloat crossing between code written on the server-side... and code on the client-side. The further back in time I go the more it was server-side but, as mentioned, begin to lack the AJAX side of it.
Personally, I prefer to be back to the vast majority being server-side code. Sure, the amount of Views (and Partial Views) on my backend codebase is much higher than before but it is still organised code and testable without even using a browser. I then let htmx do the magic onto the webpage.
I have success stories but I also mock some things I did in the past but with htmx and it is very promising!
Sure I am still using Javascript but it is not ready about the data anymore - mostly additional libraries used for better drop down features or other cosmetics/UI things.
EDIT - ADDED:
It is worth noting that the last 20 years, despite various javascript frameworks from React to Angular to knockout to jQuery to MooTools, etc..... we also had Flash and Silverlight and other things. We also have HTML5, CSS3, etc.
I have tried many things in the last 20 years. I also accept that htmx, while my goto choice for todays web development... is not going to be the best choice in my future.
Web Assembly (WASM) is going to get better and more popular. It will not be about HTML coding like today or even javascript in many ways. They will still be there, of course.
(Javascript will always be there but its use will get smaller and smaller)
As someone else wrote: we have apps and not websites now and if you look at what was named "HTML5" it is basically a software platform where you can run applications on. It really is client application development today, html is just the UI lanuage for historic reasons, but even that is no longer true in all cases (I'm thinking of Flutter or Compose). So, maybe even HTML is not that relevant in many cases.
> I don't want to bring politics into this, but I find the hype behind HTMX eerily similar to the populist vibes I get reading what their voters write.
Funnily I get quite irrationally conservative vibes the other way around. People clinging to their tools. All this complexity I learned must have been for a reason! We are building webapps for a reason (and that reason is valid for absolutely everybody and their use case)! "You youngsters do not remember the bad old days when everything was made of spaghetti, never again!"
Fortunately this is not a struggle for democracy but only a quibble in web development.
Your abstractions live either in the frontend or in the backend. For most cases, either will be quite fine.
> All this complexity I learned must have been for a reason!
It doesn't have to be so emotional.
Htmx can be helpful to keep all your state in one place, it's simpler to reason about and make changes. Lower cognitive load for the system is better for smaller teams and particularly lone developers.
You can accomplish the same thing by going full front end and minimize backend code with a similar small library that takes care of most to all of it for you.
Living in the front end, with all app state in the front end, has distinct advantages. Lower latency for interaction. Lower server costs. Offline capable. It has some cons like slower initial render. If you don't like JavaScript, JavaScript.
As a fullstack dev doing roughly 50/50 of both, massive agree. At least in JS land it's just JS, in the backend you even have to choose between entirely different languages sometimes, all of which have similar complexities to deal with.
By comparison, especially these days, making something like a Vue or React app couldn't be simpler. You run a single command and get everything generated for you, then you point it to one of a million free hosting sites out there and boom presto, you're live.
I feel like people are just afraid/cocky to admit they're too lazy to think about the frontend for whatever reason. All the arguments I've ever heard have been quite shallow and easily disproven if you spend, like, 5 minutes reading through some docs.
I think it's less of a distinctly populist thing and more of a "convert's zeal". I have seen this type of language used with a lot of different technologies over the years when there's a lot of hype and momentum around them.
Ultimately there's just a lot of tradeoffs to make in this space and I'm glad that we have more options now. For awhile it seemed like you were either doing SPAs or everyone thought you were doing it "wrong", but things like HTMX, LiveView, Livewire, and Hotwire make it much easier to build good backend driven web apps.
Inertia.js 2.0 is a really compelling middle ground as well & IMO is the best thing to come out of Laravel. You can get most of the benefits of a JS "metaframework", but you have adapters for many different backend and frontend frameworks.
As a React developer, I love that HTMX is trying to aim for stewardship and "No new features as a feature". IMO, page router NextJS is perfect (and in line with the original API it pitched), and the bifurcation to app/page router has been complicated. Yes, I am fully aware that NextJS works with both app/page. I just find it mentally confusing to wrap my head around both worlds.
I feel this way about base React too, including -- functional/class components, hooks/non-hooks, and more recently, RSCs/Client components. Although I'm more willing to see React as an evolving research project, as contradictory as this may sound.
I’ve been bitten so many times with the app/page router thinking I was looking at docs for one but I was actually looking at them for the other. So annoying.
No new features is such an underrated feature. It's funny sometimes when people see some Common Lisp or Clojure library with no commits in the last X period of time, and people immediately come to the conclusion that something must be wrong.
In the world of AI tooling, "completed" should have a huge advantage over libraries with lots of churn. Maybe a positive side-effect of new AI tooling is that there will be competitive pressure for libraries to reach a completed, no-new-features state.
I've found Htmx to be smug and misleading. "Look how simple it is! No JavaScript! Ignore the fact that you need a complex backend in a separate language and environment to generate your html."
Separate language is fine for those of us willing to write anything but JS. As long as it means writing less JS, a separate backend isn’t that big of a deal.
There's nothing philosophically or aesthetically good about
<button hx-get="/confirmed"
hx-trigger='confirmed'
onClick="Swal.fire({title: 'Confirm', text:'Do you want to continue?'}).then((result)=>{
if(result.isConfirmed){
htmx.trigger(this, 'confirmed');
}
})">
Click Me
</button>
or about
<div hx-get="/clicked" hx-trigger="click[ctrlKey]">
Control Click Me
</div>
or
<form id="example-form" hx-post="/test">
<input name="example"
onkeyup="this.setCustomValidity('') // reset the validation on keyup"
hx-on:htmx:validation:validate="if(this.value != 'foo') {
this.setCustomValidity('Please enter the value foo') // set the validation error
htmx.find('#example-form').reportValidity() // report the issue
}">
</form>
Htmx's own examples push you to code that is unorganized and inaccessible.
Any non-standard HTML attributes look cursed to me, it seems like HTMX claims to be a solution for JavaScript excessive complexity but at the same time creating complexity in another place where is doesn't belong. There is a reason not XML but imperative C-like syntax stuck around for doing procedural things on the web
Ironically I can read through this code and know exactly what it does with no other context. I don’t even know what swal is but I can still tell what it does.
Sorry was typing that on my phone so got lazy, `doThing` would be a method/function of some sort. You can also write it inline if you so wish, like `@click="console.log('hello')"`
I feel like there is a middle ground which is being excluded. I'm leaning towards alpine.js or similar lightweight JS frameworks which have better ergonomics than react or plain JS. Webcomponents also without Vue or React are a nice solution.
Oh definitely - I'm not an absolutist. I just want to have the least amount of contact with those aspects of the Javascript ecosystem that take me further away from HTML over HTTP and progressive enhancement.
And I fully accept that "web apps" probably need complex frameworks. I just think most people aren't really building web apps - they are building web sites.
Dunno where you got the first example from, but in idiomatic htmx it would be:
<button hx-get="/confirmed" hx-trigger="Do you want to continue?">Click Me</button>
Hardly the horror story you are trying to write.
The second example: really? The words 'get' and 'trigger' don't tell you what it's going to do?
> Htmx's own examples push you to code that is unorganized and inaccessible.
You realize these are demo, ie sample code right? No one is forcing you to write exactly that code? You can write organized and accessible code in your own project?
> htmx supports the hx-confirm attribute to provide a simple mechanism for confirming a user action. This uses the default confirm() function in javascript which, while trusty, may not be consistent with your applications UX....In this example we will see how to use sweetalert2 to implement a custom confirmation dialog.
It's implementing a custom confirmation dialog. Customized, non-default UI/UX usually means custom-written code in any framework I'm aware of. Maybe React has implemented magical customizations since the last time I checked.
React doesn’t require you to both abandon the principles of the library and write an inline string of code to run something slightly custom when you click a button.
htmx doesn't require you to write inline code in strings either, it's just a convenient compact way to do it in a demo. Also, it's not 'abandoning' any 'principles' because the 'principle' is to leverage small bits of JavaScript in a high-impact way. Eg, https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg
So where else will you put this code? A separate file? Multiple files? Maybe specific files for specific bits of UI? Maybe then you’ll need to handle bundling, transpiling, minification? Oops, we’re back to an evil pile of JS code that needs to be built.
Not really? HTTP/2 and ES Modules exist now, lol. And so does brotli compression done by my CDN. Bundling/transpiling/minification are basically obsolete technologies.
you can take anything in this type of context and it will look unorganized and inaccessible. react, angular, svelte, whatever-framework-du-jour … and much much worse than these examples
Why does it have to be a separate language? You can serve templates with javascript, thus it works just fine with HTMX. I think you have some fundamental misunderstanding.
> No JavaScript! Ignore the fact that you need a complex backend in a separate language
Backend in a language that isn't JavaScript is a feature.
Also, a backend where you just serve a template instead of full layout (server-side rendered app) or JSON (client-side rendered app) is not more complex in most of scenarios.
Nowhere does htmx say 'No JavaScript'. We say 'targeted, high-leverage use of JavaScript'. And neither do we say 'ignore' that you need a 'complex' backend (backends do complex work, they will be incidentally complex to a certain extent anyway). We say HOWL–Htmx On Whatever you Like. It works with any backend and language you prefer and that's strength. Believe it or not, people use languages other than JavaScript.
Except you bill yourself as a replacement for React, Next, etc. No more components! No more state! No more crazy logic or builds or code or maintenance! Just use htmx, everything becomes so simple!
None of that goes away, of course, it just moves to a different repo.
We don't bill htmx as a replacement for React or Next, only for the use cases that make sense for its capabilities, which often happen to be things people are using React and Next for because that's all they know.
Actually, duplication of state, routing logic, auth logic, etc. really do get eliminated. Because we're maintaining all that on the server-side only and not having to reproduce it on the client side. It's a huge win.
I don't need to keep track of it, because that state is embedded in the hypermedia ie HTML page itself. Eg, I implemented a pagination component in htmx. It has a 'prev' button, a page display, and a 'next' button. If I'm on page 1 and I press the 'next' button, then I have my backend server respond with the next page and also a re-rendered pagination component with all three elements now pointing at their new correct pages.
Except these aren't pages. They're slides in a carousel. There's no data to load. The markup isn't substantively changing. But instead of just translating an element, if a user clicks on the next button, we make an http request to a server, wait for the server to receive it, wait for it to generate a snippet of html, wait to get it back, and then drop it in. That's a pretty laggy UI. And as a result of that replacement, you lose the focused element and any possibility for animation.
What happens when you click quickly? Does the UI just freeze until it eventually loads... some slide? What if you want a touch carousel using scroll-snap? How do you destroy and replace the entire section without interrupting the user?
If you want to have a purely client-side carousel then this is outside the domain of htmx :shrug: You implement the carousel on the client-side. Use whatever library you like. Personally I think web components are a great complementary fit with htmx. But here you've just moved the goalpost. What you said earlier:
> No more state!...Just use htmx, everything becomes so simple!...None of that goes away, of course, it just moves to a different repo.
With a purely client-side component, the state is managed purely on the client side, and the server would not touch it anyway. So it didn't have duplication of state to begin with, and htmx is solving (among other things) the duplication of state problem. So again–this example is not relevant to htmx.
"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."
This argument is that jQuery is still very popular compared to JS frameworks like React, etc.
What about vanilla JS?
As someone who isn't that experienced with JS, my understanding is that modern vanilla JS is "about as good as" jQuery. i.e. if you don't need much JS these days, just choose vanilla JS.
However to this day I still find jQuery to be one of the nicest APIs to ever be used on the frontend stack. It is legitimately just more pleasant to write.
(Yes yes I am more than aware of how to shim a lot of it for vanilla JS)
Those stats are pretty meaningless. How many of those websites haven't been updated in the last 7 years? Not that there's anything wrong with that, but the decisions they made a decade ago aren't necessarily still the best ones today.
How is that meaningless? It seems that web users of the site at least find it acceptable and aren't complaining enough to the site builders that they feel the need to change the website. AKA the website is standing the test of time. That's kind of a huge bonus when it comes to saving money and time to the website maintainers.
The point is that if you were to start building a new website from scratch today, the best tools for you aren't necessarily the most widely used ones. You have the option to start with a clean slate without any baggage. There are no upgrade costs. There are no customers who will get inconvenienced. There is no inertia. You are in a very different position than someone who has a website with millions of lines of jQuery already in use.
Congrats you're reinventing jQuery. With a worse and more limited API.
Plus jQuery is one of the most battle tested libraries in the world.
That "ops" you made with classlist, you're bound to repeat these mistakes ad infinitum. And they can bite in subtle ways only your users might experience.
People rarely report broken websites unless they really need to.
> That "ops" you made with classlist, you're bound to repeat these mistakes ad infinitum. And they can bite in subtle ways only your users might experience.
People rarely report broken websites unless they really need to.
I think those two sentences are out of bounds, but I somehow get you. Yet I don't get the 'broken website' remark (took it condescending, or is it from experience?).
Mainly, I was replying to the affirmation that javascript is not chainable which is (imho) an indication of how one could get disconnected to the underlying lang by simply relying on libs such as jQuery (and I am thinking the same about htmx).
Thanks for your reply!
I view JQuery as similar to C in some ways: It's been around forever, it's mature, and it works. It gives a good experience to get something up and running quickly: it's lightweight and simple.
But if you're working on bigger projects: It is possible, but have have to be very principled in how you use it, otherwise you're going to end up with either a massive spaghetti codebase and lots of edge cases in your app that breaks.
Alternatives like React and Rust may add more complexity upfront, but the improved structure and safety it gives has big benefits in all but the smallest projects.
Not so sure about that. You can easily write horrible code in React: Too complex, inefficient, and/or resource-intensive.
If you don’t know the tools and have good theoretical programming knowledge, all code will be spaghetti code in the long run.
I'm no fan of React, but these aren’t equivalent. If you follow the rules, react (or any of its alternatives) will manage stateful changes like adding and removing components and event listeners. JQuery is more similar to doing manual memory management in C. It’s extremely easy to get it wrong and introduce leaks and other non-local errors.
Can you give an example? I mean I know you can shoot yourself in the foot with any UI framework, but jQuery has no way of managing state, everything just leaks by default. Unless they’ve added something.
I don't disagree, but this is not relevant for the vanilla JS vs. jQuery discussion, since vanilla JS has exactly the same problems you mention as jQuery.
Vanilla JS, as an experienced dev, is the best thing for now. You can write your proxy functions, and globally you get the control over every little thing.
> The View Transition API gives you the power to create seamless visual transitions between different views on your website. This creates a more visually engaging user experience for users as they navigate your site, regardless of whether it's built as a multi-page application (MPA) or a single-page application (SPA). Typical situations where you would use view transitions include:
> A thumbnail image on a product listing page that transitions into a full-size product image on the product detail page.
> A fixed navigation bar that stays in place as you navigate from one page to another.
> A grid with items moving positions as you filter through.
So this would cover a few uses of HTMX?
Recent Safari and Chrome now have decent support. Sounds like Firefox are working on it but I couldn't find an expected release date.
i think the transition API, when it is broadly available for MPAs, could replace a fair number of simple UI use cases of htmx. The main feature it would likely obsolete is the `hx-boost` feature:
If that goes away, htmx will be useful for smaller transclusional features at a lower level of complexity, so the two should complement one another in my opinion.
> 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.
I feel that is misleading. I worked on a lot of websites and none of them included jQuery willingly or sometimes even knowingly.
Either it's shipped as a peer dependency or we're talking about wordpress and the like which use it (and drives much of the web!).
I've seen it frequently shipped because of scripts embedded into a larger frontend codebase. Stuff they really don't want there to begin with.
I do not for a second believe that 75% of frontend dev work is in jQuery. In fact, I'd be surprised if it's more than 5% of all frontend engineering work is using jQuery.
Obviously some people might still use it for whatever reason; but those are a tiny majority (and probably quite vocal about it / over represented if they still prefer it).
So yes, to all intends and purposes I would claim jQuery is legacy software. Current usage (wherever they got that number from) does not mean it's still the preferred choice for the majority of web developers.
That number definitely needs some clarification. My guess is that if a single page uses jQuery on a domain, it counts, even though very little of the functionality depends on it. For a large organization with decades of legacy content, it's not hard to imagine jQuery is still used here and there.
I've been a Vue user for years, I do automations and glue code mostly, and most of the times using Vue is a bit too much, for my last project I used https://github.com/guyroyse/htmx-tailwind-vite and been delighted about it, it's exactly what I need.
I'd love to use HTMX at work. Sadly the security folks would probably balk at checking in JS code that uses eval(), even though you can disable eval at runtime in the HTMX config.
I thought about writing a script to remove all references to eval (and all tests relying on eval), but at that point it would probably be easier to just rewrite the library.
I see so many people praising the "no new feature as a feature" part, but hasn't semantic versioning already solved that problem? If you are on version 3.x.x of a library, why do you care if 4.x or 5.x or 6.x is launched, other than FOMO? Just keep using whatever version you want and let others have shiny new things.
There are so many sites out there using 4-5+ year old versions of React, and they all work perfectly fine. There's no compulsion to upgrade if you don't want to.
Because your potential dependencies will require 5.x as a peer dependency, so you have to use 5.x. Because your current dependencies will fix bugs or introduce features that you need in versions that upgrade their peer dependency to 5.x, so you have to use 5.x. Because the package itself will fix certain bugs that exist in 3.x but will only fix them in 5.x, so you have to use 5.x.
Ignoring security vulnerabilities tends to not work out so well. And sure, you can submit a PR. It might not get merged. Sure, you can just fork it. At that point you might as well use htmx.
I really wish htmx would use fetch rather than xhr, and now it looks like that won’t happen. Fetch is easier to proxy, so it would open up a lot more possibilities for backends, like ones running in browser or a native process. I had to hack together a xhr fetch proxy to make this happen.
I value the hard stance on stability and backwards compatibility over the constant churn that some JS libraries/frameworks have. I understand the need both approaches, but this is a breath of fresh air.
I also happen to think that most web apps have no business being so complex, and that too much work goes into dealing with the added complexity of running SPAs where an SPA is not needed.
Because then I can keep the bulk of the logic in a language that’s better designed than JS. Not having to write JS is a huge feature. The added complexity of HTMX is abstracted behind a single library, and the bulk of the logic stays in a better-designed language—Go, Python, Java, Kotlin, Rust, Zig, C#, anything.
It is clear that htmx has a growing community, but it still feels a bit too backend-minded to convince frontend developers to adopt it. I tried it in a prototype, and it was quite pleasant until I realised I needed to account for additional state management and backend wrangling to be able to provide some dynamic features. That was the moment I realised htmx is not a fully fledged product but rather a core feature that sits neatly atop a traditional server-driven setup.
That's why I think their roadmap looks right. I believe the way to broader adoption is to improve tooling, encourage standardisation, and integrate htmx more closely with well-known frameworks. That's the only way I can see dev teams buying into the paradigm change and htmx jumping into mainstream usage.
The idea is to have fat backends and dumb clients. It’s definitely a different way of building things and not everyone’s cup of tea. For me, the biggest selling point is getting to write less JS.
Writing the bulk of the logic in Go, Python, Kotlin, Rust, or Zig is a huge plus, as I consider them better-designed languages with easier maintainability.
I'm huge a supporter of the HTMX philosophy. I highly recommend reading Hypermedia Systems especially for people that are just beginning doing web development. I've purchased the book and it was a wonderful read especially for its explanations and pragmatism.
> This means accepting and documenting the quirks of the current implementation.
If you're planning no new features as a feature, why not first remove those quirks? Why keep them around?
> People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed
Truly, there exists a middle path: you can make breaking changes and user still can upgrade at their own pace (using future flags, codemods, etc.), you don't have to refuse progress - it's just a "more" work for the creator.
> why not first remove those quirks? Why keep them around?
To preserve backward compatibility.
> there exists a middle path:...it's just a "more" work for the creator.
I think you just answered your own question. Unpaid maintainers of a free open source software project are trying to reduce their maintenance burden. This is normal and actually a good thing if it means they will be able to stick around for the longer term. Consider that you are asking a guy who has been maintaining open source projects for more than a decade, with some degree of success. So his strategy is probably working for him.
Then why v2? If there are no breaking changes, why increase the major version? And if there are breaking changes, why not fix the quirks? Seriously, decisions like this show me the maintainers are just blinded by their lack of front-end skills, whining about JavaScript and striving for questionable "purity" - it's the same with the codebase (as mentioned by other commenters): one large unmaintainable file, because build step is too complex or whatever nonsense.
Anyway, excellent article and discussion that showed me I can forget about HTMX :D
Did you read the v2 release notes? The big thing they got rid of was IE11 support. Everything else was relatively minor. Having a bunch of breaking changes in v2 would have made the upgrade much more difficult for users, and a big part of their philosophy is making upgrades easy.
Of course, no one is forcing you to use htmx. Please use whatever you like.
I briefly evaluated htmx with a go backend - and for simple navigation etc it works quite well. where I struggle is using more advanced web-components like datepickers etc. - as I dont want reimplement it from scratch.
any advise from others how they handle complex client side components?
I'm the creator of https://htmgo.dev and I'll say that is definitely the biggest issue I've run into with htmx. It's definitely not an overall replacement, you will have to either rebuilt the date picker from scratch in js, or find a vanilla js library
so unfortunately the major downside I see so far is it's fairly hard to find good open source vanilla js libraries for things, as most things seem to be written for react.
other examples include:
- virtualized list
- combobox
Iam using templ https://templ.guide/ in combination with htmx.
I rebuilded various of html components of https://www.patternfly.org/components/all-components/ - but as you mentioned, I also couldnt find good vanilla JS libraries for more complex components - and I dont feel I am capable to build a e.g. battle tested datepicker from scratch.
If you like this approach but want a full-stack JS solution, check out Joystick [1] (the philosophy [2] page echoes a lot of the same sentiments here).
It could be my inexperience, but something that helps manage state would be awesome. I’ve found myself having to do some pretty wild things to maintain a certain UI state server side. It could be that’s just the way it is too. Otherwise, I’ve used htmx a decent amount and really like it.
I am a fan of this approach. About to launch a SaaS now and htmx powers much of the interaction so far.
Tools like htmx make it easier for solo founders and small teams who don't have the bandwidth or the desire to manage all the churn. Keep the dependencies tight and ship!
Overhyped, back to 20 years ago.
No proper framework in any language.
And no it's not the new jquery.
You can't do real time time tickers. You can't call client side functions.
It's hyped by entry level web devs, because they don't know any better.
You get all the baggage with it, that you hoped to be rid of with the separation of data provider and client consumer.
Session management, path parsing and matching, flash messages, complicated nested
if else blocks. Argh.
Search engines can crawl js nowadays.
It's like going back to sysinit when you have systemd only worse.
But HN never fails to hype bs tech
I’ve heard this kind of pushback from k8s wranglers whenever a small-scale alternative is proposed. The big win here is writing less JS and more of a language that’s better designed (aka not JS).
No, it's hyped by people like me, who were writing web applications more than 25 years ago. We want to do backend because a big part of frontend is complex for no good reason.
But it's not complex when you use the right tools.
I did PHP professionally for 11 years and I waa bored out my mind of it.
The repetition, the boilerplate, the stupid dogma and OO fetishism.
And everyone in their freshman year suddenly knew better and tried to preach what they learned in Uni.
"But that's not SOLID and not OOP". But it's simple and does the job.
I moved to Go and AngularJS. That was 2013.
I did full backend aka full ssr with Go, and it's a PITA.
I did try htmx with a jinja like template language in Go, with templ and in Rust and ... I forgot the library, it's the go to library in Rust for htmx.
All the annoyances are still there.
Session management, service oriented design, if else blocks between and inside html tags.
Path parsing and comparison. Template macros. And now also fragments.
Now I use a graphql backend for data, and react consumes it while the ide supports intellisense for queries. It's more simple than writing your queries by hand on the backend. You have interactivity for free. And you let the client worry about how the data is displayed.
Also you let the oidc server worry about users.
Concerns are separated. I have authz middleware on the graphql backend, easily written.
Everything has layers and there's order and a clean structure.
As a plus I don't have to annoy my users with captcha. And I have reduced infrastructure costs as well as traffic.
I'm 50. My internet journey began 1995.
I did enough of the old way to hate it and to know when something is better.
I have met my share of fanatics, of language and framework Nazis.
You have to stay curious. I have tried htmx multiple times and found it inadequate, not good enough, too limited.
Like I wrote there are no frameworks in any language for it.
It's just JS hidden behind html attributes, claiming it isn't JS.
I hate deception, the zealots are deceptive as all zealots in any language, package or framework are. Angular Nazis holy crap. Or React retards where you mention how Vue has simple SSR adaption and Rract doesn't, and are labeled as a React hater.
I'm pragmatic. I like clean structure and efficiency as well as simplicity. Sometimes you have to learn a bit of complexity to have it simple and efficient in the long run.
I have tried many things. Ruby on Rails, Elixir.
You know what, I have started programming at the age of 11 on the cpc 464 in basic, at 12 I cracked c64 games and wrote cracktros in asm. I'm one of the first cheat creators for MMORPGs ever.
I don't consider myself super smart, but I have seen a lot and tried a lot. I also struggle with learning new things. But you have to.
Htmx is not the way. It's a step back. It's only for simple things.
I do believe the hype when it's reasonable. Like with MVC. It was the natural way to write SSR websites. This is the way.
But then something better came along and it took a while to solve the inadequacies it had.
But now it's at a point where SPA + graphql + oidc = awesomeness.
And it's going to become better.
And I'm not talking about the Nextjs crap, those fake backend libraries that are hugely overcomplicated.
Greatly appreciate this philosophy and what htmx brings to the table. It is very simple and quick to pick up, and the longterm stability and simplicity are major advantages for web development.
I have, many times in the last 2 or 3 years... I still do... It's cheap and easy to implement, it's easy to use and it ads just as much cruft as I'm willing to tolerate. I build boring software, average CRUD applications for government departments, people in this line of work don't give a shit about millisecond delays or reactivity, hell, they don't even care about responsiveness... jQuery facilitates high speed development, provides neat functionality that doesn't get in the way, it's easy to maintain, and keeps people happy.
Even if you did give a shit about those things, all that can be achieved with jQuery. IMO the real downside of jQuery is not being as opinionated as other mentioned "technologies", which leaves too much room for thinking
That said, back in the day it provided functionality that JS just didn't, or was quite cumbersome.
With recent JS versions, JS can do a lot of what JQ did for it, but JQ's API or "surface area" is still syntactically smaller and (IMO) more sane than those JS improvements.
I dunno, but it is included in many commercial libraries (free ones tend to be less reliant on large dependencies); a lot of people know it and a lot of people don't even know how to start bundling a node (or dino? what are people using now?) project; and it has a lot of extensions that really impress some people.
Besides it having a way more convenient API than bare JS. (That honestly, I only don't use because bare JS is conveniently documented by MDN, otherwise I think I'd be fully on it too.)
~43% of the internet runs on WordPress[1] while ~75% of the internet uses jQuery[2], so even if you took out every website that used jQuery due to being built on WordPress, the number of websites using jQuery would be over six times higher than the number of sites built using react.
"I know it well" is really the only motivation you need. Why learn a new tool when you have used this one a hundred times before and know it'll get the job done?
If you are brand new to the space and looking to learn, then yeah stay away from jquery.
Start? Not really. However that doesn't mean there isn't active development and new features happening on projects that are already using jQuery, and so the expectations from that library matter.
If you haven't started your dev journey with React or some other framework like it, you actually know for a fact that they are not necessary an probably an overkill for a lot of web apps. Websites were built with interactivity, were lighter and worked better, before the dawn of slop-assisted SPAs and developers who don't even know how the browser and hypermedia actually works.
Yes, my site appears a bit clunky (this is intentional), but as a solo, full stack developer working on a personal project, I wanted things to be stipped down and focus on having a solid backend and significant tests.
Htmx is perfect for this.
Is it elegant? Yes and no. Is it ideal? No. But what it does very well is let me focus on the code I'm writing (python/flask), without having to put three different hats on (frontend, backend, and interactive js), and it lets me code in the language I love (python) without forcing me into a gigantic javascript platform I don't actually want to be in.
I'm not getting paid for this, and I won't actually spend my time coding if I'm not excited about the way I'm working. Htmx let's me code the way I want to code and that's why I'm a big fan.
This is a great site, honestly the only thing to push it to the next level is to just polish up the styling. Aside from that it loads instantly and never had an issue clicking around.
Thanks! Like I said, yes, the style could easily be improved, but it's really difficult to spend time on that when I'm working so hard on the backend. It's a low priority, even if it's a bad first impression for some people.
For example, the most recent update completely changed the way the index page loads, as I reverted it from Leaflet -> Maplibre so that I could use OpenFreeMap, saving $20+ per month in hosting costs, and allowing for vector maps to be used: https://openfreemap.org/
In that same update, I was able to add the "most recent week/month/year" for new and updated courses. After that update, I was overloading my flexible server instance with too much memory (oh, those for-loops and large lists). So, I then rewrote a significant section of the caching system!
The important thing is the "recent updates" lets people know the site is active. I got more than a few emails about whether it was a dead site in the last year (followed by random middle-man advertising pitches).
The reason why I think the styling is a low priority is that the site is targeted (for content creation) at older, non-computer literate folks at small clubs that would like to share their knowledge for posterity. It's also targeted at Wikipedians who justifiably know that this kind of detail about golf is inappropriate for Wikipedia, but still love golf. I'm not sure either demo cares too much about a site being super pretty.
The information ideally is targeted at golf nerds, but mainly junior golfers, looking for available information about relatively unknown course that they will be playing on in tournaments (hence the printable course guides).
I use alpine and htmx. God above I have no idea how the more complex pages work. They're a maintainability nightmare. Still, Claude can write both and it works, soo...
Htmx always sounded nice and I always wanted to give it a try - yet, paradoxically, I always had my reservations about it on the conceptual level.
With something like Elm, I'm basically thinking of the frontend as a state machine (composed of smaller state machines). I always know what's [supposed to be] going on exactly, and assuming that all the underlying machinery is working as expected and that I haven't messed up anywhere, I can be sure that everything is consistent. Basically, things are data-driven.
Htmx feels like a step back in this regard. Let's say https://htmx.org/examples/delete-row/ - something back in my mind yells at me that I don't really know what I'm presenting in that table. The state is in DOM, all "inverted" as the frontend is not really aware what it's displaying (it can figure it out by introspecting the DOM, but that's exactly what feels off). I'm just concerned that it'll end up like my ancient Delphi or Visual Basic projects, where it was impossible to understand what's going on, because everything got tangled up in a ball. This is opposite of data-driven approach that I don't really know a name for... "shape-driven"?
I look at examples like https://htmx.org/examples/sortable/ and I just can't shrug off the feeling that with such design the frontend has no idea about what's going on, and while it's fine if all I ever need is a small sorted list (that I can pull back from DOM - which acts like a weird pseudo-database), if it grows it becomes error-prone, difficult to comprehend and maintain.
I suspect this is because HTML was always about documents, and never about interactive applications, so there's this fundamental impedance mismatch when one tries to build an application in a browser. I thought the solution was to build a new abstraction replacing HTML - with things like React being intermediate steps, still using HTML/CSS for rendering, and canvas-based GUIs being the way to go, unburdened by the document-based foundations anymore. In other words, I'm not really convinced that Hypermedia is a suitable foundation for a lot of the things people actually build online.
Htmx surely has appeal in simplicity, but doesn't this simplicity brings back all the complexity people tried to get rid of all this time? Is there something I'm missing? Should I possibly think of the frontend as a terminal-like system that can run small programs but is not an application so it's never aware of what's going on? Or is it something else?
My apologies for the confusion, or if I wrote something weird (I sure babbled a lot). I'm just trying to keep up with the world and understand it.
(And, of course, no doubt, one can write crappy incomprehensible mess of a codebase using any technology. Maybe all my issues is that I have no idea how to write good Htmx code that wouldn't bloat and rot over time?)
> Should I possibly think of the frontend as a terminal-like system that can run small programs but is not an application so it's never aware of what's going on?
Kinda? Where HTMX sits in my head is on a different evolutionary path starting from server rendered pages back in the 1990's. Instead of doing full page renders, HTMX lets us update discrete portions of the DOM from server rendered content... and that's all. It's like heavy client JS apps never existed. IMO, the key here is that the browser is assumed to be mostly just for display, and the backend is still expected to be inside the user interaction loop.
The last time I tried to do anything with HTMX, the technology practically resisted any attempt to add any substantial state management on the client-side (which is kinda/sorta by design). As you mention, complex controls that do this like fully-featured tables, are a poor fit. It's possible, but not elegant or easy. Meanwhile, fetching an updated fragment from the server to do those kinds of jobs on user input, is trivial. It's super inefficient for bandwith, but way easier to code and maintain (IMO). To me, that's the core tradeoff here.
The server-rendered web app (without htmx, think crusty PHP router admin panel) is actually very similar to the Elm architecture.
The database is the Model.
The server is the update function.
The HTML template is the view function.
HTTP requests are the Msg.
Database/API calls are the Cmd.
The problem with this model is that recreating the whole UI every time is slow and clunky.
Elm and most JS frameworks fix this by running the `Model` and `update` function on the user device and doing tree diffing. This is reasonably performant if you do it well, but it's also hard to do well (see: every website ever these days) and introduces complexity, particularly because the client-side `Model` almost always needs to be synchronized with a database or some other "canonical" model.
As pragme_x touched on in a sibling comment, what htmx does is not an iteration on the framework model; it's an alternate solution to the original problem. What it does to avoid the clunkiness is let the server to return `Delta HTML` instead of `HTML`, and for the slowness, it leaves the vanilla-JS escape hatch open for things that can be done without altering the Model (database). This model also has its flaws, especially if you need to use that escape hatch a lot, but it's also a lot simpler conceptually and keeps the `Model` and `update` function in a trusted computer, meaning you don't need to marshal and validate stuff between two models.
> how to write good Htmx code that wouldn't bloat and rot over time?
- Don't try to perform fine-grained updates if you don't have to. It's fine to replace a little more than you absolutely need to, and htmx takes care of some of the things you might worry about like preserving focus. For example, in the "delete row" example, it might be more robust to replace the whole table.
- Use htmx for anything "side-effecty", i.e. anything where a network request is compulsory. Relegate JavaScript to "micro-interactions". I consider a code smell in an htmx application any time I need to add new elements to the DOM via JavaScript, most of it should be manipulating classes, attributes and styles.
- For those micro-interactions, the "component" model heralded by the big three JS frameworks doesn't work as well here, since components have their own state, which is another "shadow-Model". Instead, try the RSJS methodology (https://rstacruz.github.io/rsjs/) with "behaviors".
- To wire up that JS to your app, reach for custom events. The `hx-trigger` attribute is the "port" that translates JS-based interactions to Msg.
> I suspect this is because HTML was always about documents, and never about interactive applications
This is a really common refrain and it peeves me, but I don't have a good rebuttal to it yet so I won't weaken my comment by trying to make one. I don't have good explanations for a lot of things about htmx and hypermedia, actually. The code of htmx is mostly complete, but the theory is still WIP.
Off topic but the other day I tried again to build a vanilla JS application.
By the end of the day having built quite a lot I then converted the entire thing to react within half an hour stopped wasting my time and got in with the job of building the thing.
I like to try library free JS every now and then and yet again it was not competition for react.
I know react, it makes sense to me, I find it easy and powerful, I know how to fix most issues and probably most importantly Claude is able to write react for me almost without me intervening at all.
I’m not saying react is for everyone but for me it’s a power tool that I know and the AI knows very well and it gets big stuff built quick.
I did something similar but I took it entirely the other way, I built a full CRUD application with no javascript.
The app is fully SSR and integrates with a fairly complex inline data enrichment and analysis system. I used Tailwind alongside regular CSS for the layouts and some visual enhancements. Eventually, I gave in and added a bit of JavaScript to submit a form when a dropdown is selected—usability is important to me. Other than that, everything works as needed.
You didn't really set the scene. What kind of application was it? If it's a fully interactive rich application with real time multi user handling, then sure. If it was a static page blog, then that's a problem (yet I see people do that anyway). There's a whole spectrum of interactivity and expectations here.
Question is, can you have a super thin layer that gives you the reactivity we all crave and don’t want to reimplement in vanilla ourselves without using legacy tech React.
In a way, it’s depressing that the thing that holds developer minds hostage gets even more hold over devs, because the frickin AI knows it best.
Just a reminder: React was created as a not-a-framework-but-a-view-library but everybody writes React apps, not JS apps.
> React was created as a not-a-framework-but-a-view-library
Honestly, I think this was the biggest mistake the React team made. It was never intended to be this way. It was just marketed this way in order to convince people to try it.
Once you started to use it you could very easily tell how it never fit in the traditional MVC model.
That’s great for you. But every single react project I’ve seen or inherited has been a steaming pile of shit.
All these new front end developers who jumped in on react with no other experience have no idea how web works are struggle to build without react.
Anyone competent in web development prior to react could build with htmx or even vanilla js just as fast without react as they could with react. Won’t stop the brainwashed react devs coming out defending their only source of income tho.
I feel this article makes the same mistake many technical articles make.
What does it do? After reading a large chunk of the article, I have no idea. No, wait it "enables behavior".
Maybe it's only relevant to people that are already familiar with it. But it would seem that a hacker news front page would be a great opportunity to let more people know about your product.
This isn't an announcement of a project. This is more a statement of their philosophy and what they are doing. This is targeted towards people familiar with the project.
This is just people's subconsciousness fighting against the rolling progress. It's trying to avoid learning new things and trying to preserve the status quo where you can keep rolling using the already acquired knowledge. It's anti-thetical to being a hacker.
The modern way is to use LLMs to auto generate all this code and do some small corrections in the process. So you wouldn't have to worry about the underlying tech and would only be concerned about the core functionality and actual mechanics of the product rather than being interested and spending efforts on memorization of the specific instructions for the machine. The whole evolution of the programming languages is a process in that direction and new technologies that were embraced by the newer generation like React and Vue.js is the way to go. You can't run geosites forever.
The philosophy of a tool like htmx encourages the opposite of "avoiding learning new things". The reality is that there is not often anything that is truly novel. We waste time by failing to recognize patterns and abstractions that persist over long periods of time and in many cases that are even foundational knowledge.
A foundational fact by definition does not need to be constantly scrutinized as if it were not. Rather it is something that can be relied upon stably until such a time that a change in a core assumption forces us to reevaluate the foundation if and when that scenario occurs.
It’s about using the right tools for the job. FAANG and developer advocates made the web needlessly complex for most people. The over-engineered tools and frameworks became the “default” way of programming for the web, loosing some strong key features that were good about it: simplicity, transparency, and speed.
> It's trying to avoid learning new things and trying to preserve the status quo
Well, yeah. Sometimes the status quo is good. Sometimes you don't want to learn how to do simple async page updates for the thousandth time.
Because many of us here have been there, done that. Over dozens of years. With dozens of libraries.
It's a hamster wheel. It's boring. It's pointless.
In the end, if your website/app does what HTMX is good at, just use it.
I learn dozens of new things every day as a solopreneur SaaS guy. I don't want to relearn how to make async page updates ever again, unless there is a very, very compelling reason to do so.
I’ve just completed a port from HTMX to Hotwire (Stimulus, Turbo). HTMX is a great idea, but in my experience it’s a poor execution.
It’s really quite buggy, in my experience it plays poorly with fundamental web and browser features (relative links are broken in at least 2 ways, I fixed a third way). One of the events just stopped working at all in the most recent release. The docs are lacking. And where it promises to let you write less JS, if you ever do need to write some JS you’re on your own in structuring that, and you’ll be fighting against HTMX (who gets to update the DOM, maintaining event handlers, etc).
As a (brief) contributor to HTMX, I also feel like these issues were all inevitable. It’s a single 5k line file with 190 top level functions in it meaning it’s pretty impenetrable to get up to speed on. When proposing a bug fix the maintainers weren’t sure if it would have other consequences. Tests didn’t cover the functionality. I’ve been mostly a backend engineer in my career, and I empathise with not wanting the complexity of a modern frontend, but that doesn’t mean we can’t have some basic organisation of the code to make it approachable and more obvious whether changes will work or not.
After porting to Turbo and Stimulus I have a more reliable code base, I have significantly less JavaScript, and I have a JS code base that much easier to reason about. I really wanted to like HTMX but the execution is not there. A focus on stability is a great fit for the project, but it’s most certainly not there yet and has quite a way to go in my experience.
Hey Dan, htmx maintainer here.
I would love to know in what other two ways relative links are broken, and which event stopped working, so we can get those fixed. With respect to the fix you PRed (thank you, by the way), we did get that merged very quickly, and would love to do the same for whatever is broken here, even (especially) if you are no longer interested in doing the fix yourself. [0]
As for the DX of making changes to htmx: absolutely true! The single file is a DX we've chosen, and it has both costs and benefits, which we've written about in "Why htmx doesn't have a build step". [1]
[0] https://github.com/bigskysoftware/htmx/pull/1960
[1] https://htmx.org/essays/no-build-step/
Hi Alex, thanks for the reply and for your work on HTMX. I love the idea and think there's a strong need for something like HTMX, and if HTMX can live up to those promises then great. For me it doesn't, currently, but it sounds like it does for others.
The relative link bugs are [0] and [1], and I fixed [2]. My fix was merged quickly, but the other two bugs of what appears to be similar significance, have been open for well over a year each. My issue however is less about these specific issues, and more the general lack of support for hypermedia, which speaks to a general state of HTMX not living up to its promises.
As for the DX, I think not having a build step, and code structure, are somewhat orthogonal. I agree with much of that essay, but most of it is about issues with complex build systems and the use of Typescript. It's not about having 190 top-level functions, which, with all due respect, I think indicates a lack of architecture. Again, the issue is less about the specifics, and more about the fact that HTMX is not living up to its promise of simplicity because of how impenetrable the codebase is in this regard.
As mentioned, so far I have found Stimulus and Turbo to be better implementations of what HTMX appears to promise to be. More activity in this space from anyone and everyone is great here though!
[0]: https://github.com/bigskysoftware/htmx/issues/1476 [1]: https://github.com/bigskysoftware/htmx/issues/1736 [2]: https://github.com/bigskysoftware/htmx/pull/1960
Why is the number of top level functions a problem? As long as they are named and organized appropriately I don't see the issue
I love writing prototypes as a single file as much as the next guy, but there's almost 5k lines of code in this one file: https://github.com/bigskysoftware/htmx/blob/master/src/htmx....
They're sectioned off, so "event/log support" and "AJAX" and such are grouped by the type of method, but they're not prefixed so there's no way for your editor to help you explore grouped functionality.
Given that the code isn't particularly organized or structured in any way that I could quickly glean (aside from the aforementioned grouping of related functionality, which is only so helpful), I think I'd be put off from wanting to contribute to this codebase.
De gustibus, but after taking a look personally I think it's pretty good. It's typed to the extent allowed by js, sections are clearly delineated, and if you collapse all the functions you can get a quick overview of every section. I personaly would use a different naming convention, but still their functions look reasonably named.
See: php.
190 functions at a single level strongly implies that they're not named and organized appropriately.
Naming doesn't have anything to do with the number of functions. They section things off in the file, so if you prefer things split into multiple files I can understand, but it's a personal perference in something this size
If you're not using more common organization tools like modules, naming tends to be where organization is implemented: common prefixes, etc. Even if they're carefully done, you still end up with a long list of names, with a lot of implicit rules to keep in mind to decode the name (this is why Hungarian notation seemed like such a good idea in the beginning, and a bad idea once it was actually extensively used). Names shouldn't need decoding.
I haven't looked deeply at HTMX, so I won't claim they're falling prey to this exact problem. But it's definitely a code smell that's concerning.
i don't mind a lot of functions in a single file:
https://htmx.org/essays/codin-dirty/#i-prefer-to-minimize-cl...
The more you need to hold in your head at once to understand code the harder it is to do understand, and the harder it is to contribute or onboard to a codebase.
A lot of functions doesn't necessitate a lot of things to hold in your head, but in my experience, HTMX hasn't got enough other structure to prevent this. I was not confident about the changes I made, and the reviewer was not confident about the changes. In a well architected codebase the goal is for these things to be obvious.
As for minimising classes? Sure. I can get behind that. But I think it's orthogonal to having a lot of top level functions with no clear naming or sorting.
If the goal is to have a single-file codebase, I'd suggest considering the following (you may already have done so, but I haven't noticed consideration in the few documents I've read):
- Structuring the file into clearer regions – there is already some of this, but comment blocks are easy to miss in a 5.2k file, and utilities are everywhere.
- Adding named closures for grouping related functionality – "classes lite", at least gives some function namespacing and code folding.
- Ordering the file to help direct readers to the right bit, literate-programming style, so that there's a sort of narrative, which would help understand the architecture.
- Function name prefixes to indicate importance – is something the entrypoint to core functionality? is it a util that should be considered a sort of private function?
- Pure functions – so much of the code is state management performed in the DOM, which makes it hard to test, hard to know if it's working, hard to know what interactions will be introduced, etc. State management is always hard, but centralising state management more would be good.
- (That said... arguably library internals are the place to have make the low-abstraction high-performance trade-off with a bunch of mutable state. However, this makes it hard to have other Javascript that co-exists with HTMX, because it's too easy to stomp over each other's changes. A better integration path, like Stimulus, might alleviate this and retain HTMX's control over the DOM).
- I understand the preference for longer functions, but `handleAjaxResponse` is a lot. More abstraction would really help make this more understandable.
I get that personal preferences are key to why HTMX is the way it is, but I think it's important for the general health of open source projects that others are able to contribute, safely and effectively, and I'm not sure the current choices are most conducive to that. Hopefully some sort of middle ground can be found where HTMX doesn't lose its "personality"(?) but where some of these things can be improved.
Obviously it's an idiosyncratic way to organize code, and I get that someone coming in and making a one-time contribution might be a bit overwhelmed by how different it is than other codebases, but I've been happy with how easily i've been able to come into it after taking time off and figure things out, particularly when debugging.
We have other people contributing on an ongoing basis and i've had people (mostly non-JS people) comment on that they find the codebase easy to navigate, since you don't have to rely on IDE navigation.
There isn't a lot of state involved in htmx: it's mostly passed around as parameters or stored on nodes. History, where you ran into a problem, is a tricky part of the library that's hard to test, and that's where most of the problems have cropped up. I could probably factor that better to make it more testable, at the cost of more abstractions and indirection.
In general, I'm not inclined to change the organization much (or the codebase, per the article above) so that we can keep things stable (including the behavior of events, which apparently changed on you at one point.) I'll sand it, but I'm not going to do a big refactor. We've had people come in and propose big changes and reorganizations, and we've said no.
https://data-star.dev is a result of someone proposing a big htmx rewrite and then taking it and doing their own thing, which I think is a good thing. htmx will stay boring, just generalizing hypermedia controls.
I did a walk through the codebase here:
https://www.youtube.com/watch?v=javGxN-h9VQ
Given the lack of API changes going forward, I hope that artifacts like that, coupled with overall stability of the implementation, will mitigate risks for adopters.
I think an opinionated stance is in general a good thing when it comes to open source project. I just worry that contrarianism in frontend development is being conflated with contrarianism in general programming. The former being the intention of the project that I support (yay hypermedia!), and the latter most likely not being the goal.
Maybe the sanding will help, and if HTMX is not going to change much then maybe not much is needed, but I think there's still a way to go to stability and feature completeness.
> https://www.youtube.com/watch?v=javGxN-h9VQ
Thanks for the link, I'll definitely give this a watch!
i'm pretty contrarian in programming as well, so it tracks:
https://htmx.org/essays/codin-dirty/
https://grugbrain.dev/
htmx is feature complete (see the article)
we can argue about stability, but we have lots of happy users
> The relative link bugs are [0] and [1],
Thanks. Genuinely asking something here: are relative links actually common in frontend? I've only ever used absolute URLs for static assets. Actually I even made tooling that ensures that static asset paths will always be correct: https://yawaramin.github.io/dream-html/dream-html/Dream_html...
Of course, this kind of tooling exists for many frameworks. But I've never seen frontend frameworks suggest using relative links for static assets, they always seem to put them in a separate subdirectory tree.
Relative links are common in the Microsoft ecosystem; the IIS webserver, in its default configuration, serves websites at a subpath named something like /Our.App/ instead of at /. Frontends often use the <base> tag so that they can refer to assets by relative path, allowing different environments to have different base paths.
Random developer here: in my code, yes they are common. I tend to write modules so that I can route to them from wherever, reuse them, and move them around as I please. Relative links help greatly with such things.
Besides that, they are a very basic part of the spec, and I consider anything that breaks them to be truly fundamentally broken.
Understood, but how do you deal with static asset caching and cache-busting with version markers or similar? Does your framework/build system/whatever automatically add version markers to static assets that are bundled directly with your module?
I tend to keep statics consolidated and slap middleware on those routes to handle expiration headers and whatnot. Versioning is handled where links are generated; an href="{{ linkfor(asset) }}" style resulting in generated urls complete with content hash tacked on. I almost never construct asset links without some form of link generator function because said functions give me a centralized place to handle things just like this.
(edit: I should clarify that I'm mostly working in Go these days, and all my assets are embedded in the binary as part of compilation. That does make some of this much easier to deal with. Javascript-style build mechanisms tend far too much toward "complex" for my tastes.)
OK, wait, you said earlier that you bundle static content like images in the same module as the feature itself, but now you're saying you keep them consolidated in a separate place? You also said earlier that you commonly used relative links but now you're saying you generate them with a link generator function? I'm confused about what you're actually doing...if you look at the link I posted earlier, you can see how I'm doing it. So...are you using relative links like <img src=dog.png> or not?
I was unclear; I bundle them per-module; each module has an asset route with attached middleware. So for a users module, there will be users/assets or some such route, to which various static-related middleware gets attached.
The link gens inherently accept relative paths (foo) and output relative links with appropriate adjustments (foo.png?v=abcdef), though they can generate fully-qualified links if circumstances warrant (eg I often have a global shared css file for theming, though that's all I can think of offhand other than "/" for back-home links). The module can then be mounted under /bar/blort, or wherever else, and the links remain relative to wherever they are mounted.
On occasion I do hardcode links for whatever reason; my rule of thumb is relative links for same level or deeper, or root-anchored if you're referencing a global resource outside the current path, but there aren't many of those in my apps. A rare exception might be something like an icon library, but I tend toward font-based icons.
To put the rule more succinctly, I never use "../foo". Going up and then over in the hierarchy strikes me as a recipe for bugs, but that's just instinct.
I also never use fully-qualified (including hostname) urls to reference my own assets. That's just madness, though I vaguely recall that WordPress loves to do crap like that; there's a reason I don't use it anymore. :)
So the main difference if I understood your link correctly, would be that I would have maybe one or two items in /static/assets by root-anchored urls, and the rest accessed as /path/to/module/assets/whatever (edit: or just assets/whatever from within the module).
Because I'm doing this in go, the module's assets live where the code does and gets embedded in a reasonably standard way. I actually tend to use git commit as my cache buster to avoid having to hash the content, but full hashing can be done as well very easily just by changing the generator functions.
I can then just import the module into an app and call its associated Route() function to register everything, and it just works. Admittedly it's very rare that I reuse modules between apps, but it's easily possible.
For background to my thought process, I originally started using the link gen paradigm long ago to make it easy to switch CDN's on and off or move between them, back before whole-site proxying was considered best-practice. The rest is just a desire for modularity/encapsulation of code. I like to be able to find stuff without having to spelunk, and keeping assets together with code in the source tree helps. :)
Thanks for the explanation!
Sorry, forgot about this bit:
> and which event stopped working
It was `htmx:load`. On 1.x this fired on first page load, which I used to do a bunch of setup of the other little bits of JS I needed, and which would cause that JS to re-setup whenever the page changed.
On 2.x this never fired as far as I could tell. Maybe I got something else wrong, but only downgrading to 1.x seemed to fix it immediately, I didn't investigate further.
I did wonder if there were breaking changes in 2.x, but as far as I could tell from the release notes and documentation there were not.
Maybe I'm missing something here, but JS modules do not require a build step.
* Note to non-JS hackers: JS module symbol scope is per-source file.
JS modules can't be imported with a plain script tag.
Script type=module doesn't work?
Not if you want to support the 0.2% market share that IE 11 has.
That's true, but also a trade-off that is a perfectly valid engineering choice for many or even most teams.
HTMX 2 stopped IE support, so that shouldn't be an issue.
we don't :)
we want to support the traditional script tag w/ a src attribute and nothing else
Why?
idk just like it better that way
Chiming in to say modules are awesome and you shouldn't be so scared.
I'm not scared, I just want people to be able to include htmx on their page the same way, for example, good ol'jQuery is included.
We generate esm and cjs modules for people who want to use htmx in that manner though:
https://github.com/bigskysoftware/htmx/tree/master/dist
you can define import maps in a separate <script> tag and reuse the module name elsewhere
sure, but I wanted the same experience of, say, jquery, where you just drop in a script tag w/ a src attribute and it just works
an aesthetic decision, I suppose
Depending on the import tree depth, it significantly increases latency.
(Which is why bundlers still exist.)
Last time i tried it, i couldn't get hotwire to work with a non-ruby backend.
HTMX had no issue, tho
It’s definitely documented as Rails first, but so far I’ve had no compatibility issues using it with my Swift backend.
I’m curious about your Swift backend stack, if you’re willing to describe it. I’ve become quite fond of the language after writing a few small desktop apps & command-line tools with Swift.
I love the language. I'm using Vapor+Fluent+Leaf, but I've had a few issues with them, I think they're fine, but if I was making decisions again I'd probably choose something else. I think the problem is that Vapor is trying to be a Django/Rails style, batteries-included framework as opposed to a Flask-style library (if those terms help you at all), but they've not quite nailed it to the Django/Rails level yet. For my project I'd have been better off with less framework, as most of my code is not strictly web code. I've ended up changing the Vapor application architecture a bit and pulling lots out into non-web-specific Swift Modules. If I were choosing again I'd give consideration to Hummingbird.
Library availability has mostly not been a problem for me, there are some really high quality libraries, particularly open source ones from Apple. Quality is high compared to other ecosystems.
I'm targeting Linux/Docker for deployment and while I don't have the project running in production yet, I've been running CI builds and it so far seems fine. It's fairly clear when things are Linux compatible and when they're not. Most things you'd expect to be are compatible. Some third-party libraries are accidentally not Linux compatible, but it hasn't been much of a problem for me.
The new Swift Testing library is really nice, and I'm using that for all my server tests with no real problems. Vapor could have more testing support (Django's is excellent and my bar for comparison), but it all works.
Overall it's just a lovely language to work in, and I'm enjoying server side development with it.
no doubt there was something small that i was missing, but i was doing a rapid, time-boxed experiment and didn't have time to get deeper into it, at the time
I use it at work with asp.net MVC, no issues either. I did have to use Webpacker though...
Symfony (PHP) and it's UX packages are all based on Stimulus
I have had a great experience with Astro and HTMX. When the first time I tried, I didn't think much about HTMX and thought it was an Astro thing, about a year or over. But this time, I had a great experience and I understand the power of htmx and native web only JS, no framework when building simple sites is much refreshing.
> It’s a single 5k line file with 190 top level functions in it
That's interesting. Do some people prefer this style? If yes, how come?
I prefer this style. I primarily use Emacs as someone else mentioned. I feel like it's sort of similar to editor tabs vs buffers. Like, once you have a good way of switching between buffers, separate editor tabs seem like a superfluous UI element. In a similar way, if you have powerful ways of navigating to the function definition you want, then everything being in the same file doesn't seem to matter.
Also, having all the code in a single file helps expression exposition of the code. You can sort of captivate the reader of your code, and present the code in the order of your choosing.
Really appreciate the reply. Thanks.
I do. I've always felt that I'm doing something wrong when I do this, but I much prefer not having to switch files all the time and navigate folders etc. looking for things. With everything in one file, I can just use regular within-file search (and M-x occur in emacs which is a bit like clickable (and editable) grep). If I need "focus", I just use narrowing in Emacs (shows only the highlighted part of the buffer, with handy shortcuts for narrowing to current function/class). If I need to see something side-by-side, just split or clone the buffer. I loathe working on those java etc. projects where you have a zillion classes each in their own file, many with maybe a handful of members each; whenever I switch files I feel like I'm losing context.
If you look at the end-user API documentation[1] it's pretty good.
But the htmx.js file itself seems to struggle from a certain type of internal naming scheme that will take a while to get up to speed with and doesn't really lend itself to being easy to context switch in & out of it, where you might simply forget that things exist and end up re-writing or inlining these fragments.
This naturally stems from a very organic development process, where something starts out as a quick prototype, then the functions get too big so you split fragments out into things like `shouldProcessHxOn` and `processHXOnRoot` which absolutely make sense at the time where you're avoiding duplication, and trying to turn it into something 'more proper' with 'better abstractions' would actually cause the code to balloon in size and make it much bigger and much more like object spaghetti.
On the whole though, a large amount of the file is type documentation, e.g. `/* @param {Node} start */` which is more a failing of JavaScript itself than anything else, and honestly a 5k self-contained file with good public documentation of what's user-facing vs internal is pretty easy to grok if it's something you work with frequently.
If you were to rewrite this in a saner language like Python with a more functional style, you could probably condense it down to 1000 lines or less.
[1]: https://htmx.org/api/
Just a note to other readers, Turbo doesn't require Stimulus... I use Turbo mainly with AlpineJS and it works just as well since Turbo is the just tag driven side of things.
I wanted to use Hotwire but it felt like it was made for Rails as backend? This probably needs to be fixed because if the DX is as good as you say then its disservice to be tied to Rails.
Which leads to the appeal of HTMX. It promises no other dependence. It just does exactly what it advertised. I'm not sure whether your issues were due to implementation or specific known bugs in HTMX not covered.
I am curious to know more about Hotwire, I'm just worried about state management and this is greatly overlooked when it comes to adding application logic beyond just hydration of specific components on page.
So far I have not seen anything that competes with Sveltekit.
Hotwire is designed for good integration with Rails, but Rails is not required. In a similar way, HTMX works better with various server-side libraries, but none are required.
Personally I'm using Hotwire (was using HTMX) with a Swift backend with no issues.
Backend dev here. Give yourself a break and use sveltekit
Fun fact: Svelte doesn't allow the <title> tag to have any attributes: https://github.com/sveltejs/svelte/issues/5198
Full stack polyglot dev here, the relentless pressure to use Sveltekit that has utterly destroyed plain Svelte docs, IMO, coupled with the koolaid kult around v5 is why i finally ditched svelte.
I have backend solutions and existing databases and existing backends. I would never consider a Js backend in a production app to begin with, despite the benefits an isomorphic approach offers. I dislike when physical actual boundaries in code execution contexts are obfuscated, for one...
But not everyone is building SPAs, and my dev server is my actual backend, thanks
Remember Meteor?!
Yeah, Svelte5 said "away with these pesky svelte users, lets market to React devs and make everyone realize that Vue3 has a bigger ecosystem, since you are gonna have to do a rewrite anyway "
Basically the opposite of this principled stance here on this htmx missive
Frontend framework churn costs money and lives
It doesn't have to, you can just start using a piece of technology 5-10 years after everybody else, you know.
We started using react a couple of years after hooks were introduced when there were millions of ready libraries, all major design patterns were established, tons of docs were written, etc., and although there's still major churn, it's nothing like it was when react first came out.
I looked at svelte when the hype circle started and decided to postpone using it for at least five years — these comments show it was a right decision.
It saves money and time to be conservative with these things.
> ...you can use as much or as little of it as you like... Stability as a Feature... No New Features as a Feature...
This is the way.
Having lived the alternative, I won't consider building anything significant on top of an abstraction that doesn't credibly promise these.
When the abstraction you've built on changes or fails, the thing you built breaks. When you choose an unstable abstraction, you're creating future bugs you'll have to spend future time on to resolve (and if it wraps the lower layer rather than sitting beside it, you have fewer options to fix them).
These aren't concerns for things that will be short-lived, or are small enough to replace if needed. But I've seen plenty of small and temporary things turn into large and permanent things when they end up being useful.
> ...you can use as much or as little of it as you like... Stability as a Feature... No New Features as a Feature...
Given my experience with node ecosystem, react, and nextjs, I am inclined to agree.
I agree about react and nextjs.
But the node ecosystem includes essentially everything that touches on javascript, both the bad and the good.
I don't think there are very many ecosystems that are guaranteed to have only good stuff. Regardless of ecosystem, the developer has to examine what is available and make wise choices.
I think the culture is so prevalent that I have to defend parent’s statement. Node itself, and npm which is a node project, are some of the worst offenders. It’s had abysmal stewardship imo, and one could argue this sets the tone for the ecosystem at large. Hack upon hack, config files of doom.
There are exceptions, but at this point the verdict is clear. It’s like the meme about Java being enterprisey and over-abstracted with factories. As far as stereotypes go, it’s true. (Or was, haven’t used it in forever)
I’m not even against JS, and much less the web. I think it’s the 7th wonder of the world. But the developer practices makes me want to tear my hair off.
> the verdict is clear
Not to me.
I know there's plenty of junk, but if you opt out of the node ecosystem in its entirety, you're essentially opting out of most of javascript development as well, which is a substantial part of web development.
That's your choice, but you're missing out on a lot of good and useful things... just in terms of software development but also in terms of meeting whatever your business needs are (if you're trying to make money).
Javascript static analysis tools can be very useful (like TS and eslint). app frameworks can provide routing, UI frameworks, UI controls, validation libraries, etc. that you would otherwise have to implement on your own.
These are all part of the node ecosystem. htmx is part of the node ecosystem. IDK, lumping it all together doesn't make sense to me because there's a lot lost and little gained.
There is a great way to combat this, use libraries you've reviewed to have proper design and implementation, then ignore the rest. People rely on libraries for the stupidiest shit, and also are really afraid to go against the current flow. If you're not doing TypeScript/VueJS/$POPULAR_THING you don't know anything about JS and you're a dumb developers, which of course is very wrong. And stop listening to recommendations from lifestyle developer streamers who most likely got paid to recommend whatever they're babbling about.
Till they change, see Svelte 3,4,5
I quite liked svelte 4. Svelte 5 might be even better, but I'll probably never find out.
I won't touch it if I can help it. No matter how good it is, I'm fairly certain there will be a svelte 6, 5 will be abandoned, and whatever issues crop up in it will not be addressed unless I move to 6... probably just in time for 7 to come out. I know this because that's what happened before, repeatedly.
I don't know if htmx is actually any good, but they are saying all the right things.
Major versions that change basically everything should be considered different projects and require a re-review. I remember I did this early with react-router, and I think when they changed the public API for the second time, we forked it and left it as-is, because they made their goals apparent.
If Svelte version 4 and 5 are very different, then they're "SvelteV4" and "SvelteV5", both on version 1.0.0, in my mind :)
Based
Nextjs is a nightmare. React is pretty good nowadays imo.
"Pretty good" is good enough for most developers, but React has some issues that reduce developer experience (having to do your own memoization and a lot of hidden complexity that can impact performance) that require a huge engineering effort to solve (React Compiler has been in the works for years).
I'm also not sure whether the move from class- based components to functional components with hooks should've been part of the "regular" React or if it would've been better to do a hard break (e.g. a version 2.0), but I think the collective front-end developer world is still traumatized from the AngularJS -> Angular transition.
>But I've seen plenty of small and temporary things turn into large and permanent things when they end up being useful.
My experience is that probably more than 9/10 temp projects end up forever projects. My goal is never to work anywhere again that insists on just get it done quick and dirty "its temporary" ever again.
I don't remember where I stole it from but at work any time we're discussing something temporary I like to drop in a "remember there's nothing more permanent than a temporary fix" and it usually gives us at least a few more minutes of considering things carefully before pulling the trigger. Makes me feel better anyway.
I have a wood block wedged between my car's battery and battery mount because the new battery was smaller and I couldn't get the mount to adjust down. I cringe whenever I get the oil done but I don't fix it because it is good enough. I do feel dirty about it and every other weekend I think, "I should install a proper sized mount." But the battery doesn't wiggle. It works. It is a temp fix that has been there half a year. Code is even less visible to most, so even more out of sight and out of mind.
In modern development best practice, you'd refactor that bug fix, by moving the block of wood to underneath the battery where you can't see it any more. (And writing "node_modules/" on it with crayon...)
This perfectly captures the node_modules / JavaScript experience, because being underneath the battery would also stop it from working as intended and the battery would be loose again.
I've created a Django application using HTMX. Usually I'd jump to React or Vue. It was a great exercise and I can see where HTMX would be a great fit.
1. If you consider yourself a "backend developer" only and want to write the minimum amount of JS/TS.
2. If your application is simple. Yes you can do more complicated interactivity with oob swaps, but you end up with more complexity than you chose HTMX for.
For my next projects, I will still use Django but with React/Vue for pieces that need interactivity. As an example in my HTMX app, I wanted to add a profile image uploader. Lots of great frontend libraries exist to resize / modify your image before even uploading it to your server.
Finally, HTMX is just not testable the same way modern frontend libraries are. I've managed to write some decent tests using beautifulsoup, but it's night and day compared to vitest or jest.
This was my exact experience - loved it as a backend developer wanting to build simple frontends with minimal JavaScript (and I still recommend it for many use cases) but when I then tried HTMX to build a more complex application I found that the complexity that would normally be handled by a JavaScript framework ultimately grew and shifted to the HTML and, surprisingly, the backend as well.
For example, error handling in complex forms. When you have React handling errors you simply return a 400 JSON response with fields and reasons, or some other error message, and React decides what to do depending on the context, which it knows. When this responsibility is moved to the backend you now need to track the request location, state etc. and find the right fragment, which very quickly turned the code into a mess.
I think the choice of backend is also important. I suspect that Java (Spring Boot) made using HTMX much less pleasant than it would have been with something else, especially when it comes to templates and routing. Using Java for HTML templates (Thymeleaf or any of the other popular libraries) is something I will never do again.
Edit:
The analogy with jQuery is interesting. I feel the same way about HTMX now as I did about jQuery ten years ago. I used to plug jQuery into every project even if it was just to select elements or whatever, but whenever I used jQuery entirely over the frameworks that were popular at the time (Ember, Angular) I ended up with way messier code.
> When this responsibility is moved to the backend you now need to track the request location, state etc. and find the right fragment,
Maybe not? I'm just returning a 422 JSON response with fields and reasons and I have a tiny bit of JavaScript in the frontend that just plugs them in to the form with the built-in Constraint Validation API.
https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg
> I suspect that Java (Spring Boot) made using HTMX much less pleasant than it would have been with something else, especially when it comes to templates and routing.
I strongly agree with that and created a library to help with those aspects: https://github.com/yawaramin/dream-html?tab=readme-ov-file#f...
IMHO one of the biggest advantages of using HTMX is not having to maintain three layers of test suites (backend, frontend, end-to-end). You just need to test that your endpoints return the right HTML piece. You don't need unit testing the frontend since you don't have that much logic there. Just rely on end-to-end tests as a complementary tool to check small pieces of logic on the HTMX code.
I’m not sure I’d agree. The HX attributes encode a lot of functionality and you want to check that they do the right thing together. You can test you get the right attributes in a response, but that’s only a proxy for the application doing the right thing, so you most likely still need the end to end tests.
The problem is that end to end tests are the hardest kind to write. At least if you have a frontend code base you can have some tests there and get some confidence about things working at a lower level.
> You just need to test that your endpoints return the right HTML piece. You don't need unit testing the frontend since you don't have that much logic there.
Only using the standard Django test client? I don't find this myself when I've had to work with HTMX code e.g. if you're using HTMX for your sign up form, it can be completely broken on the happy path and on form errors if the HTMX attributes are wrong, and the standard Django test client won't let you know, so you lose a lot of confidence when making refactors/changes.
That honestly sounds like a downside. Having to verify HTML as an output (in comparison to e.g. JSON) is brittle since it will often change just for presentation reasons. Having a clear and somewhat stable API (which is a boon for testing) is IMHO a strong reason for the SPA model.
> Having to verify HTML as an output (in comparison to e.g. JSON) is brittle since it will often change just for presentation reasons.
For HTML tests, if you target elements by their ARIA role, semantic tag, or by matching against the text/label/title the user would see, it should be robust to a lot of presentation changes (and does some accessibility checks too). It's much more robust than e.g. `body > div > div .card > h2` which are sure to break in tests and slow you down when you make changes later.
See Playwright locators for example:
https://playwright.dev/docs/locators
Not sure if this is what you meant, but you can't rely on only the JSON because you can't assume it's been properly transformed into the expected HTML.
htmx moves the data -> html transformation to the server side and thus should be more testable
It's standard practice in the frontend world https://jestjs.io/docs/snapshot-testing
In my experience snapshots have largely fallen out of vogue, at least as far as them blocking deploys goes. They're usually flaky, change often, are slow to test and it's way too easy to have false positives which lulls people into complacency and just regenerating the snapshots as soon as they reach a failure. I'm guilty of that myself, unless I can spot the breakage immediately I pretty much just regen the snapshot by default subconsciously because of how often I've had to do that for false positives
Then what's to stop you from making any unit test pass by just changing the expectations? The best testing technique in the world can't save us from developer error.
The problem with snapshot tests is that they tend to fail when something is changed.
One property of good tests is that they only fail when something is broken.
Snapshot tests aren't really automated tests, because you have to manually check the outputs to see if failures are genuine. It's a reminder to do manual checking but it's still not an automated process.
> The best testing technique in the world can't save us from developer error.
Sure, but using a testing technique that increases developer error is unwise, and snapshot testing has done that every time I've seen it used, so I don't use it anymore.
> they tend to fail when something is changed.
Then fix the test so that it fails only when something breaks? Do people not fix flaky, overly broad, or incorrect unit tests? How is a snapshot test any different?
A fix here would be to drop snapshot testing altogether, since being flaky and overly broad is a natural result of dumb diffing of your app's output.
I'm not sure you understand what snapshot testing is. It's a form of testing where you render frontend components and take a "snapshot", storing the output and saving it for later, then on the next test run, the component is rendered again and compared to the saved snapshot.
Any change that modifies the rendering of any component under test will break snapshot tests. It's literally just a test that says, "Is this render function still the same as it used to be?"
I'm not sure you understand how to capture snapshots at the correct level of granularity. If you have snapshots that are breaking for irrelevant changes, then by definition those changes don't need to be snapshotted, do they? Cut down the snapshot to only the relevant part of the rendered HTML so that when it fails, you know something broke.
Eg in htmx we can add a snapshot test for the pagination component I mentioned in this comment: https://news.ycombinator.com/item?id=42619553
This snapshot will break if I have a bug in my pagination logic implementation, and it's highly unlikely to fail for random irrelevant changes.
It would still break if you need to modify that output in any way. Need to add a class for styling? The snapshot breaks. Need to add a new hx-attribute? The snapshot breaks. It's not tied to the logic, it's tied to whatever markup you output. You've reduced the surface area of the problem, but not eliminated it.
> If you have snapshots that are breaking for irrelevant changes, then by definition those changes don't need to be snapshotted, do they?
You're so close to getting it.
> Need to add a class for styling?
How often? All the time? Or relatively rarely? For most projects, it's the latter. We are not constantly churning the styling.
> Need to add a new hx-attribute? The snapshot breaks. It's not tied to the logic
An `hx-` attribute is logic. That's the point of htmx.
> You've reduced the surface area of the problem, but not eliminated it.
That's a risk of any kind of unit test. You can always have false positives.
> You're so close to getting it.
That tests should be fixed until they're robust? I'm not a fan of the learned helplessness of the 'We couldn't figure out how to do XYZ, therefore XYZ is a bad idea' approach.
Do you have experience with snapshot tests? If not, you should try it out for a bit and see what we mean, you'll quickly run into the situation we described.
If you introduce a new feature and have a new button on the page, for example, the snapshot test will fail (by necessity, you're changing what's on the page) because the snapshot doesn't match the current version with the new button, for example. So, what you have to do is regenerate the snapshot (regenerating it will always make it pass).
The problem is in my experience, that these kind of tests are massively unreliable. So you either fiddle with tolerances (most testing libraries let you set a threshold for what constitutes a failure in a snapshot) a lot, or you manually have to hunt down and pixel peek at what might've happened.
As an example of what usually happens is that, at some middle step of the test an assert fails because some new code causes things to render slightly out-of-order or delayed in some way. Ultimately the final product is good and if it was an intelligent system it would give it a pass. The unit tests pass. Even the integration and E2E tests pass, but the snapshot tests fail because something changed. The chance that this test failure is a false positive is much, much higher than the chance of it being a legitimate failure, but let's assume it's legitimate like the good citizens we are and try to hunt it down.
So, you go through the snapshots, 1-by-1, setting breakpoints where you think things might break - note that this process by itself is painful, slow and manual, and often running snapshot tests on your local machine can break things because things get rendered differently than how they would in CI, which leads to an extra set of headaches - What happens here is that you're testing an imperfect reflection of what the actual underlying app is, though, because a lot or most of it will be mocked/hoisted/whatever. So sifting through what is a potential breakage, and what is just the quirk of the snapshot test is basically a gamble at best. You spin up the app locally and see that nothing looks out of the ordinary. No errors to be seen. Things look and behave as they should. You have your other tests, and they all pass. So, you chalk it up to a false positive, regen the snapshots, and go on with your day.
The next day you add some other thing to the page. Uh oh, snapshots fail again!
Rinse and repeat like this, and after the 50th time sitting there waiting for the snapshot to be captured, you decide there are better ways to spend your limited time on this mortal plain and just say "Fuck it, this one's probably a false positive as well" after taking a 2 minute look at the page locally before hitting the repacture command again.
I legitimately don't think I've ever actually seen a non-false positive snapshot test failure, to be honest.
Snapshot tests are even more sensitive to flakiness than E2E tests but flakiness is still a bug that can (and probably should) be fixed like any other.
As an example - the different browser you have running locally and in CI? That's a bug. The fix is to run the browser in a container - the same container in both environments. You can probably get away without this with an E2E test. Snapshot test? No way.
Ive seen people decry and abandon E2E tests for the same reason - simply because they couldnt get flakiness under control and thought that it was impossible to do so.
I dont think it's intrinsically impossible though. I think it's just a hard engineering problem. There are lots of nonobvious points of flakiness - e.g. unpinned versions, selects without order bys, nondeterministic JavaScript code, etc. but few that are simply IMpossible to fix.
Theres a big payoff if you get it right, too.
https://news.ycombinator.com/item?id=42625155
Not really unstable since you generate it and there's no browser modifying it. However you'd still lack client functionality testing.
> 1. If you consider yourself a "backend developer" only and want to write the minimum amount of JS/TS.
This is a great point and should be underscored more. I think generally the HTMX vs React/Vue/Svelte argument gets undercut when people don't express their innate bias on which part of the stack they want to give more control to. HTMX is great if you're pro-expanding the server; JS Frameworks if you're trying to expand it from the application layer.
You don't have to write your own using beautifulsoup. There are test frameworks like https://www.cypress.io/ and https://playwright.dev/ that work great there.
With the BeautifulSoup tests I can run 1000s of tests in seconds. Cypress/Playwright are wonderful for e2e tests, but not comparable to simple unit tests you'd have in React/Vue. I find that the BeautifulSoup tests are a decent middle ground.
But with beautifulsoup you don't test the interactions at all. You only test the rendered template which is nice, but doesn't tell you if any button actually works the way you expect.
Why is that a good thing when testing a web app? You want to see if the browser is executing your code with the correct intent.
Seems very brittle and may not catch actual regressions browsers introduce.
I've successfully used (for 3+ years in multiple projects) an approach similar to BeautifulSoup's get_text() function to assert the whole visible text of a component. You can implement it in other languages with a few regexes.
One addition makes it an order of magnitude more versatile: a way to visualize non-textual information as text in the tests. For example add a data-test-icon attribute which contains the replacement text that should be shown in tests. Another method is to parse the HTML and write custom visualization for some elements, so that you get useful default visualization for at least form elements and such, without having to repeat the data-test-icon attribute every time.
See https://martinfowler.com/articles/tdd-html-templates.html#Bo...
I’ve done something similar, but using pandoc to convert the html to text, so tables and bullet points are rendered appropriately.
> For my next projects, I will still use Django but with React/Vue for pieces that need interactivity
What's your plan for "plugging" these into your HTML? Web components?
Does Django have some kind of integration with Vite for hot reload during dev?
Check out my project, built exactly for this: https://www.reactivated.io
I'm all in on Hotwire, which is pretty similar.
They're both fantastic expansions of what server-side rendering can do. They can't really do work as nice as what React can, but you can get perhaps 85% of React for 5-10% of the development time. And a big increase in usability of your app.
As I dont do frontend work, how do you "test" anything without an insane amount of browsers/hardware realistically ?
If I was to write tests, it'd be basically http get/post/put/delete requests and measuring the responses are what I expect.. how can HTMX be any different here ?
How do you "test" a button works without a browser engine ? Every browser engine ?
We do have pseudo-browsers written in pure js that you can theoretically use:
https://github.com/jsdom/jsdom
https://github.com/capricorn86/happy-dom
but they're about as reliable as you can expect: it's difficult to keep up the pace with the big three (or two) on standards compliance, and they usually don't even try.
So the only reliable solution is a headless Chromium, Firefox, and/or WebKit-based noname browser like the sibling says.
https://pptr.dev/guides/what-is-puppeteer
https://playwright.dev/
https://www.selenium.dev/documentation/
You throw headless browsers into your CI/CD pipeline and try not to think about how many resources you're burning.
Might work for a small project, but a nightmare for medium to large projects. Imagine Microsoft tests their Outlook (web app) like that.
Microsoft tests Outlook?
Anyone got a good feel for the htmx accessibility story at the moment?
I'm interested in using it more, but I want to be 100% confident that I understand how to get htmx sites to work well with screen readers. I worry about things like fetching new data into a page not altering the screen reader user in the same way as refreshing a page completely would.
I'm not interested in whether or not htmx uses the correct ARIA attributes - I want to be confident that those ARIA attributes (or similar) do the right thing.
My ideal is still to use JavaScript libraries where the documentation not only describes how they work with screen readers, but is accompanied by video evidence showing the experience a screen reader user gets for different problems solved by that library.
This is one reason I created https://alpine-ajax.js.org. A few years ago there were a lot of examples in the HTMX documentation that discouraged accessibility and progressive enhancement. Stuff like like clickable <div>s, ignored keyboard focus, lack of screen reader announcements. There’s been some improvement latel, but I still think the library has a lot of foot guns for new web developers.
Thank you for alpine-ajax! It's amazing as an HTMX-lite or HTMX-just-right in many many use cases.
You made my day! thanks
Hey Simon, maintainer + article co-author here.
tl;dr htmx is better than a lot of alternatives, but Simon is right, it can improve this story and it has a responsibility to do so.
As a framing device: any interactivity that is not described with HTML is interactivity that someone is responsible for making accessible (which you correctly pointed out). Unlike JS frameworks, htmx encourages the developer to solve problems with HTML first, so the inaccessible surface area that the developer has to worry about is going to be much smaller on htmx-based applications than it is with JS-based applications. That's a pretty strict win from where a lot of the industry is right now.
That having been said, I agree with you (and disagree with a lot of our defenders in the comments) that thinking about this is in-scope for htmx. In fact, I'm a firm believer that libraries are exactly where responsibility for implementing ARIA attributes live. The average web developer should not have to think about this at all—they should be able to use declarative abstractions and trust that they are annotated correctly for screen readers. This is the only system that scales, and htmx should adhere to it as much as possible.
Ideally, htmx would just add the polite notification attribute to the elements it processes, and give an easy way to customize that. I think it's basically possible to do this in a backwards-compatible way (first as an extension) that aligns with the maintenance strategy outlined in this essay. And I do think we can improve the documentation as well.
I would argue that frontend libraries like htmx and React are not the place to build in ARIA attributes patterns/behaviours. In fact, none of the Big Ones do anything specifically w.r.t. announcing changes. See https://news.ycombinator.com/item?id=42625070
What would be the appropriate place, imho, would be component frameworks that are built on top of htmx. FastHTML is an example; they already have htmx integration and they talk about server-side components. If we look at a popular one in React, this is what they do: https://blog.logrocket.com/aria-live-regions-for-javascript-...
Thinking about it in terms of dream-html[1], it might look like:
[1] https://github.com/yawaramin/dream-htmlI'm thrilled to hear you're thinking about this. I really like the philosophy of the project, very happy to hear that reducing accessibility friction is a value you care about too.
> I worry about things like fetching new data into a page not altering the screen reader user in the same way as refreshing a page completely would.
Isn't this more of a general browser question that would apply to any website that uses Javascript to load page elements?
How would using HTMX (as opposed to any other library, or plain old Javascript) affect the answer to the question?
Yeah, any website that uses JavaScript to load page elements needs to solve this. My hope is that a library like HTMX can help reduce the friction in implementing the best possible patterns for doing so.
See the proposed moveBefore API [1] which is meant to solve those issues at the platform level. In the meantime, htmx has their morphdom extension, which I’d say is a must when replacing any page content with interactive elements within. Aside from that one major gotcha, the main issues with htmx are the poor accessibility of the examples in the docs [2]. In particular seeing so much ARIA without the corresponding keyboard support.
[1] https://htmx.org/examples/move-before/ [2] https://github.com/bigskysoftware/htmx/issues/1431
Handling ARIA attributes is out of scope for HTMX. It is your responsibility to include ARIA attributes on the HTML you return and swap/transclude.
As for handling dynamic content for screen readers, focus management is already a thing, and is in the scope of browser standards and the HTML your backend returns. As before, it's your responsibility to manage this. HTMX will neither help you nor get in your way.
HTMX merely extends hypertext functionality to its (mostly) natural conclusion. It is not a component library, or a framework for building components, or a site building framework, or...
You can use other tools to enhance and audit accessibility, but their use is orthogonal to HTMX. I think web developers in general are very used to frameworks abstracting a ton of complexity, but HTMX is not a framework so much as a standardized set of tools for specific low level problems, it is not a one stop shop.
In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this.
Leaving accessibility up to the end developer feels like a genuine missed opportunity for me here. One of the great things about NOT using a JavaScript library is that you can rely on the browser's default accessibility features for forms and links. Those benefits are the thing I care most about when considering HTMX or jQuery or React or Vue or similar.
> it would be great if the HTMX documentation included worked examples and guidance for how to do this.
The htmx documentation does include examples with accessibility guidance. Eg https://htmx.org/examples/bulk-update/
> The server will bulk-update the statuses based on the values of the checkboxes. We respond with a small toast message about the update to inform the user, and use ARIA to politely announce the update for accessibility.
If you check the Server Requests panel it also shows the responses and the ARIA attribute they include.
EDIT: I've submitted a PR to fix the notification toast announcement, with this the screen reader announces the notification correctly: https://github.com/bigskysoftware/htmx/pull/3112
The key is to mark all live regions statically before doing any htmx requests, then injecting the response HTML inside those regions. Then they are announced by the screen reader. This is nothing special to htmx of course; every app needs to work the same way.
> In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this.
You can refer to the WAI-ARIA standards.
> Leaving accessibility up the end developer feels like a genuine missed opportunity.
This doesn't compute for me. What would HTMX even provide? It's a set of attributes that extend the behavior of form submission to other elements and all request methods.
> HTMX or jQuery or React/Vue
These aren't the same kinds of tools. They address fundamentally different things. Handling ARIA automatically for you isn't in scope for any of them.
> > In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this.
> You can refer to the WAI-ARIA standards.
Every time someone asks for concrete a11y advice for concrete situations, some joker refers them to WAI-ARIA. This is ridiculous! That document is extremely hard to parse, and it offers absolutely no guidance wrt which parts matter the most, or, say, how the various real screen readers used in the wild behave. Please stop doing this. Accessibility is hard to get right! Making people feel like they're idiots for trying is very unhelpful.
And then you get to WAI-ARIA's practical examples and they have a yellow warning intoning "not intended for production environments" and there "may be support gaps" in assistive technology: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/c...
I think everyone's afraid of getting sued.
This makes me think that we all need this tutorial to get rapidly on par and ready to read the whole spec
> That document is extremely hard to parse, and it offers absolutely no guidance wrt which parts matter the most, or, say, how the various real screen readers used in the wild behave.
No, but it does enumerate what is available which is the starting point for figuring out what is relevant to your use case.
If you want tutorials or guides relevant to your particular use case you can seek those out, but to understand them you will need familiarity with the set of available attributes and where they are or are not permitted.
Many (most?) tutorials online have flagrant violations of the specification. We need better ones that actually emphasize understanding WAI-ARIA and not cowboy markup recipe books.
> Please, stop doing this.
No, I will not stop telling people to familiarize themselves with the primary reference material. Reading technical documentation and specifications relevant to a project is not an optional step.
It is not complete in the ways you describe (actually testing real screen readers is crucial), but it is absolutely essential reading to begin with.
> Reading technical documentation and specifications relevant to a project is not an optional step.
Well, I'm competent at HTML and CSS yet I never properly read the HTML or CSS specs either. Specs are generally a terrible place to learn a technology.
I simply don't understand how it's possible that the people who seem to care most about accessibility also seem to deeply, strongly believe that doing good accessibility ought to be very hard and time-consuming, and you don't deserve to call yourself a proper web dev without going through the rites. It's... not very accessible!
> Well, I'm competent at HTML and CSS yet I never properly read the HTML or CSS specs either.
I would strongly recommend you do! Most web developers are unaware of a good deal of just what all is available to them in those specs (especially HTML).
Are you talking about the specs? The stuff on https://www.w3.org/WAI/ARIA/apg/ seems pretty scrutable to me.
As for "real screen readers", yeah. There needs to be a caniuse.com for assistive technology.
I’m not in a good place to check but what the various AI tools recommend?
Referring to the ARIA standards doesn't help me answer the more important question: will what I'm doing work in screen readers or not?
I feel completely starved of information here. I care about accessibility. I want to build a web page where clicking on a tab refreshes a subset of that page... and I still can't find a really good guide on how to do that in a way that works in screen readers, that's accompanied by a video (ideally multiple videos, one for each common screen reader) showing the experience I can expect my users to have from that pattern.
HTMX actively encourages that pattern, so I'd love to see the project also embrace helping developers do The Right Thing with regards to the accessibility of that pattern.
> I feel completely starved of information here. I care about accessibility. I want to build a web page where clicking on a tab refreshes a subset of that page... and I still can't find a really good guide on how to do that in a way that works in screen readers
More generally, I often see people calling others "lazy" for not making websites accessible, but I personally found it hard to get my head around the WCAG recommendations, and I work with designers/developers all the time that don't know how to follow the WCAG recommendations even when you point them to documents and tutorials.
It's like nobody wants to admit it's difficult, and that's not even getting into screen readers still having many inconsistencies for basic UI patterns.
There are some sites that try to document what works and doesn't in different screen readers (e.g. https://a11ysupport.io/tests/), but even then it's still not easy knowing what to do and I don't know of an authoritative up-to-date site.
> I work with designers/developers all the time that don't know how to follow the WCAG recommendations even when you point them to documents and tutorials.
> It's like nobody wants to admit it's difficult, and that's not even getting into screen readers still having many inconsistencies for basic UI patterns.
Accessibility IS hard.
It feels sometimes like nearly everyone involved thinks they'll just read a few good blog posts and know how to make sites accessible. Then the struggle is due to not having read good enough blog posts.
Everyone wants a quick "fix" to a lack of education. Nothing replaces familiarizing one's self with primary source specifications, and most crucially, spending significant time trying out real screen readers.
I think what they are trying to say is that it has very little to do with htmx or react of whatever framework. None of it can handle accessibility automagically. Its like asking if it can write html for you - its different problem and a skill. But skills in accessibility apply to all frameworks.
> will what I'm doing work in screen readers or not?
Why not try it? But also, why wouldn't it?
Pointing at the ARIA spec as a way of writing code that’ll work with all assistive tech is like pointing at the HTML and CSS specs circa 2005 and saying that following them will make your site work in all browsers.
Try in which screen reader?
The ones you want to support. htmx unfortunately can't tell you what that is.
iOS has a good one.
> I feel completely starved of information here. I care about accessibility. I want to build a web page where clicking on a tab refreshes a subset of that page... and I still can't find a really good guide on how to do that in a way that works in screen readers, that's accompanied by a video (ideally multiple videos, one for each common screen reader) showing the experience I can expect my users to have from that pattern.
I completely agree that this is a pain point. In general, high quality documentation is lacking. I am not however convinced that this is a problem that can be automated and abstracted away. Neither am I convinced that it's one we should necessarily try to hide. It won't win me any favors but I think the issue here is simply an endemic skill and knowledge gap. Shifts in culture via higher educational curricula and stated quality attribute priorities within companies will do more good here than anything else.
Accessibility is a quality that needs to be built in from the start. The good news is that provided your HTML is sane and not a mess of class tagged DIVs, or you're building a pretty straightforward document-like navigation/content/etc site, you really only need to declare attributes to handle the places you do something unusual. The defaults are generally correct.
Much of this "unusual" behavior that needs special treatment is within custom components (e.g. a custom date selector widget with plenty of invisible divs used for layout of the calendar days can be inscrutable to a screen reader without hinting) and is the responsibility of component library or framework producers. Some issues here run deeper, like properly correlating ARIA attributes in shadow and light DOM. But that being the case, such component libraries aren't even necessarily suitable for many sites (either too complex, or make too many mismatching assumptions).
The bulk of the remaining accessibility attribute slinging that needs to happen has to do with the overall site layout (especially reactive layouts). I don't know of any framework that will handle this for you in a satisfying way for anything sufficiently sui generis. I think the tough but true answer here is "the people building the site should have at least skimmed the WAI-ARIA standard, and be using an auditing tool, and know what to be thinking about as they design the site from the start".
Everyone needs to read this spec and then live and breathe its tenets … sure. This reminds me of the time when we fixed the footguns with C by making everyone into better developers.
That guy is asking you if replacing a part of the html with some other html alerts screen readers to the change.
It’s a reasonable question and you could share what you know about how screen readers react when this replacement happens. You could write some documentation on how to alert them, some best practices to follow.
Instead you say read the fucking manual, as if that helps. You put on a veneer of caring for accessibility but it seems you care about the “purity” of htmx more.
Agreed.
Frontend frameworks often do spend a lot of time thinking about the accessibility concerns associated with client side routing, so it's not absurd to consider this question in scope for a frontend library that handles DOM updates.
See for instance this 2019 study by Gatsby: https://www.gatsbyjs.com/blog/2019-07-11-user-testing-access...
Or even the modern Next docs on route announcements: https://nextjs.org/docs/architecture/accessibility#route-ann...
Some of this will have to be bespoke work done on a per-site basis, but I'm not sure I'm comfortable with the idea of completely punting this responsibility to developers using htmx, even if it does make philosophical sense to say "this is scope creep", because ultimately users with disabilities will end up being the ones whose experience on the web is sacrificed on this altar of ideological purity.
> That guy is asking you if replacing a part of the html with some other html alerts screen readers to the change....It’s a reasonable question
Of course it is, but it's like asking if using React.js will prevent SQL injection attacks. They are orthogonal things. Making screen readers announce things is controlled by the HTML you write, not by htmx.
You're wrong, and in a pretty obvious way.
It's actually like asking what a database library will do to prevent SQL injection attacks. And the answer is simple - "don't do string interpolation yourself, instead use the `(?, ?)` syntax". If you use that the SQL escaping will be taken care of automatically by the library. If the database library said something idiotic like "read the spec and implement your own SQL escaping logic" it would be a dereliction of duty.
Make no mistake, a frontend library like htmx has a responsibility to not break the front end from an accessibility perspective. If existing screenreaders break when you replace HTML then the htmx approach is broken and htmx needs to address that.
Conceptually htmx is closer to Fetch API + set innerHTML than it is to a 'frontend library' like React.js. Do people complain that setting innerHTML from JavaScript breaks screen readers? Of course not, they set up aria-live regions correctly as shown in plenty of accessibility documentation. htmx can't make the decision for you what your aria-live regions are and what text should be read out when the content changes, you need to decide that yourself.
EDIT: here's the one mention of `aria-live` in the React.js codebase defining it as a valid ARIA attribute for ReactDOM: https://github.com/search?q=repo%3Afacebook%2Freact%20%22ari...
The one mention in Vuejs core to define its accepted values: https://github.com/search?q=repo%3Avuejs%2Fcore%20%22aria-li...
The one mention in the Svelte runtime defining its accepted values: https://github.com/search?q=repo%3Asveltejs%2Fsvelte%20%22ar...
Do people go after these frameworks saying they need to handle breaking screenreaders by dynamically updating content? Of course not. Setting live regions is the responsibility of the web page creator, not the framework.
Yes, I do go after those frameworks saying they need to at the very least help their users understand what they should do. I'm disappointed by any JavaScript library or framework that doesn't provide good documented examples for this, which is almost all of them.
> Yes, I do go after those frameworks
I'll believe that once I see you file an issue which mentions accessibility against any of the projects I linked to ;-)
https://github.com/facebook/react/issues?q=is%3Aissue+author...
https://github.com/vuejs/core/issues?q=is%3Aissue+author%3As...
https://github.com/sveltejs/svelte/issues?q=is%3Aissue+autho...
Simon don’t waste your time with this guy. I thought he was affiliated with htmx but he’s just some jerk off trying to prove he’s “right”.
I encourage you to read the guidelines and familiarize yourself with what is acceptable in HN comments: https://news.ycombinator.com/newsguidelines.html
"It won't win me any favors but I think the issue here is simply an endemic skill and knowledge gap."
My problem with that is that, as you can hopefully see, I am very motivated to learn how to do this... and yet I have not managed to learn it.
"Learn how to do it" only works if there are clear and obvious resources we can point people to that will help them learn what the need to learn. The ARIA spec is not that.
This also feels like an inherently solvable problem, which is why I always take any opportunity to put it in front of people that might feel incentivized to help solve it.
> "Learn how to do it" only works if there are clear and obvious resources we can point people to that will help them learn what the need to learn.
There are. Start with MDN. There is no more clear and obvious resource than this: https://developer.mozilla.org/en-US/docs/Web/Accessibility
There was a time when I didn't know anything about web accessibility. But I learned by reading, trying out small experiments, and using a screen reader to check my work. If I can do it, you can certainly do it.
After a while you face issues like 'Why isn't the screen reader announcing the dynamic content update', you search for solutions, and you come across incredibly helpful content like this: https://tetralogical.com/blog/2024/05/01/why-are-my-live-reg...
> This also feels like an inherently solvable problem
It shouldn't, especially if you don't know anything about web accessibility. It's hubris to think that something we know nothing about should already have been solved, why hasn't it? Is everyone else just an idiot? No, of course not. It's a complex and nuanced problem. Not the basics like always put an `alt` attribute in your `img` tag, those things are easy. But when you insert dynamic updates with JavaScript into the mix, it gets more complex.
The thing I was describing as a solvable problem was the lack of easily discoverable, clear tutorials - especially for the various libraries and frameworks that encourage patterns like updating small areas of a page that can cause problems.
Oh yes, I can see :)
And yes, I agree it is not the clear and obvious resource we can point people.
We DO need better "guide" format documentation, rather than dry technical reference. Nearly everything I've seen online is in very poor shape or outright wrong.
I share your feeling that it is solvable, and I also hope that people will help solve it.
But I'm sure of one thing: the people who write that documentation will be familiar with the specifications and refer to them (among other sources) while writing.
An "Accessibility Book" (like sections of the Python and Django docs, or the Rustonomicon for unsafe Rust) would be a fantastic resource and I hope someone writes it.
I understand screenreaders have a set of standards, aria tags etc - but are the next generation of AI screenreaders (I’m sure some already use AI?) going to replace the need for these tags, and just read a page as a human would?
I’m very grateful for how htmx by focussing on a very specific part of “interactive JavaScript on the page” was able to shift a whole bunch of similar JavaScript actions into an elegant abstraction that rested so neatly on all the existing work that had/has gone into developing html. And even for having the clarity to name it as such.
In a way it’s a bit of a lesson in managing complexity, rather than seek to be “the next JavaScript framework to replace all the others with its theory of the universe”, it instead carved off a smaller slice and said these Thich are related, we’re just for dealing with these thing, nothing more.
In one swoop a whole raft of manual developer programming workload was packed up with a new easier to understand abstraction.
Kudos to the team, I’m grateful for the considered way you’ve developed this tool for the rest of us.
how do you feel about its adoption in things like https://fastht.ml/ ? i was open to the idea at first esp with jeremy howard's endorsement, but once you start updating multiple things on a page at once i felt like i was fighting htmx rather than it helping me. components are a really neat paradigm and just bc react is currently in a complexity upswing doesnt mean we want to throw the baby out with bathwater
You can build your own python component implementation on top of htmx, like in the example you show. That is not a failing of htmx IMO.
thats not what the js world traditionallyunderstands as a component - eg - it doesnt take an argument that, when the argument value changes, the component rerenders. you still have to wire all that up with htmx (again, as far as i undersatnd it, having spent a week with htmx)
You can do that with HTMX through events and hx-trigger but it just sounds like HTMX isn't the right tool for what you're trying to do. I've seen a lot of instances of people trying to use HTMX to replace react/vue/etc. and not understanding that they're trying to solve for very different things.
HTMX highly encourages client side scripting for dynamic updates if that's what your UI needs. It's very pro-JavaScript even though a lot of people get confused and try to use it to fully replace JavaScript
I think web components would be an excellent pairing with htmx. You get some kind of component abstraction (admittedly janky in some ways, though libraries like lit or atomico make this much better). But crucially you get automatic upgrade/initialize behaviour whenever the browser encounters a custom element. So the backend can just send down the custom elements as plain html, you don't need to wire anything up, the browser will bring them to life.
The problem is web components (which are great) are not so good for seo. You would be losing the auto SSR benefits of using your own component abstraction in any backend language.
That to me sounds external/additional to the idea of a component.
You can do the component side on your backend language of choice, and output html like htmx likes it, and it works (have done it in Python, for example).
It is extra work, but it works with a bit of programming.
I am still trying to get HTMX adopted in a ~ 800 employee software development company. And while we do not yet have a project using HTMX in production, I like to use it a lot in thought experiments with mentees: Could you do it with HTMX / Fragments? If yes, how would you design it? Do we REALLY need an SPA?
Kudos to the developers.
I do think "use HTMX" is a tough sell for a 800 employee company, just because it doesn't really solve issues on it's own. (Imagining the pitch is "add HTMX to an existing project") Going all-in on hypermedia definitely means the service that serves your application needs to be more than just a JSON parrot. Templating HTML and sending the right chunks back is hard to do if those services aren't built around being hypermedia services.
I really like turbo-rails [0] (the ruby gem that Rails 7+ bundles in for turbo support, meaning helpers that make turbo frames/responses a native "thing" rails understands) because it's a complete solution. There's at least some obvious structure to build off of, and I'm not stuck trying to build up my own framework on the BE for my newly simpler FE.
django-htmx [1] also fits in this case too. I feel like any honest pitch of HTMX should involve some BE solution as well.
[0] https://github.com/hotwired/turbo-rails
[1] https://github.com/adamchainz/django-htmx
I dont intend it to be an all-in, but I do believe it could do the job in 50% or more cases just as well as any SPA framework. A lot we do is "just crudl" with some sprinkles on top.
A large chunk of our business comes from Spring Boot, so we are experimenting with JTE - looks decent so far (Thymeleaf feels just old nowadays).
My sell is pretty simple: You have regulations coming up in europe which will require you to keep applications up-to date and secure. Extending your SBOM by 1k NPM libraries is a huge cost. I want to get rid of that.
I tried to get HTMX adopted for a new project but the unanimous response was "what is this? why not React? everyone knows React. period" and most of my arguments for HTMX were ignored, because to most people, HTMX looked like some obscure, yet another JS framework created last week, with questionable future.
The reason is because all new technology is a staffing and training problem management needs to solve. Someone has to maintain your thing after its built and be ready when you leave the organization. If React can solve the issue in a similar timeframe and level of effort and it is easy to source React developers then obviously your proposal will be rejected because React is simply far easier to deal with from a training and staffing perspective for what you are trying to do. You need more merits to warrant the introduction of new languages and frameworks.
Of course you get pushbacks. Is there any *real* advantage, technical or otherwise, at an organization level, of adopting this new model of creating web pages, other than your personal preferences? You are moving away from an established system with tools that everyone is familiar with, to a system that much fewer people use, with no clear performance/maintenance/management benefit (at least not demonstrated). Maybe you don't like writing JS/TS, but plenty of other people do, and they don't need to cater to your preferences.
People need to spend time learning this tool. They need to be proficient with it. Your new stack might need to still work with existing code at some point. That means training, overhead, ramp up and potential risk in a less established area. Why would people do that?
You should be thankful you didn't get warnings from your boss for messing around instead of actually pushing features out.
Very anti React person went for Svelte but the kind of modularity React offers, HTMX can't hope to match especially on larger projects.
Modern React is too simple. A component is just a pure function taking arguments and returning UI as JSX. The only other thing you need to know is few hooks.
maybe you can send me to the right tutorial. I'm a backend, distributed systems engineer. I have worked on eye-watering scale. React is anything but simple to me.
I tried create-react-app, the thing built and downloaded for several minutes, and then there was a nest of file relationships that I didn't grok. It seemed like any change required three files to be updated. Lots of ancillary things like bundlers, packers, tree shakers, lions, tigers, and bears, oh my. After an hour, I didn't get what I was doing. Somehow, altering this function over here made this other thing over there go "moo."
I used to do web development back in like 2001. I understand the web, http, css, html, and basic js. I'm not up on all the latest, but I have a very firm base.
I got htmx working and pretty much fully digested in the same amount of time I wasted on React and have produced a working prototype. I find htmx to be like how the web used to be. It makes sense.
FWIW, create-react-app is overloaded with every package you could ever potentially want to use for some weird reason. It's way overkill and I wouldn't recommend using it.
It's much better just to use Vite with React as a plugin. Then you only need to install three React packages to get your app going.
The best tutorial I've used was "Road to React" by Robin Weiruch. His example app you learn is how to build a Hacker News front page. Very clear and it goes step by step.
Most of the tutorials online are all over the place, or mix Class tutorials with Hooks tutorials, or starts adding in things like Redux (which aren't needed).
The person you're responding to is correct, at it's core React is very simple, especially if you just stick to hooks. Most of my code is just bog standard HTML (as JSX), CSS and JS with a few React hooks thrown in.
FWIW, I've been doing frontend dev since '94 and personally find React jives the most for me and how normal HTML/JS/CSS work. I can see why people would like HTMX, but I've never liked overloading HTML attributes as some strange event model. But it's good there are choices.
Create React App should not be used because it is no longer maintained. Here is its GitHub repro: https://github.com/facebook/create-react-app/commits/main/ . It has had very few updates since July 2022. This is bad because it needs constant updates because it depends on a large number of packages and those packages are constantly releasing security updates.
That doesn't sound like a good selling point for react.
create-react-app is not react
While true, if cargo was exploitable we'd say it was rust.
React has very good documentation and an excellent tutorial. Here is a link to it: https://react.dev/learn . I recommend doing the exercises. They really help you learn React.
> Modern React is too simple. A component is just a pure function
React is simple only in some mathematical theoretical sense, but not for understanding by human minds which fundamentally operate imperatively ("if I click on this, load data X from the server and show them to the user...").
You can get some hello world example relatively easily, but you hit the complexity wall quite quickly (need to know "some hooks" - some, like useEffect() are very complex, yet often needed for basic things). The worst of all is debugging with stacktraces making no sense with it all being from the React itself, not your code, not tracking some logical pathway.
(I'm saying that as someone who generally likes React and would choose it for a new project)
useEffect is simple. If I recall correctly, with no arguments it is like onMount and with the dependent variables listed in array, it would be executed every time any of the listed variables change.
> The only other thing you need to know is few hooks.
And where you can't use them. Hopefully there are zillions of YT videos from experts teaching you all react gotchas.
> The only other thing you need to know is few hooks.
...and then draw the rest of the owl.
try passing state around the component hierarchy and see how simple it is. HTMX makes it easy but centralising the state in one place ie the server. try coming back to your code base in a year or two and see how simple it seems then :D
Except when your state appears in many parts of the page, HTMX makes it hard to keep everything updated.
Fully ack. But this can actually be turned into something good imho: I try to challenge all layers (Analysis, UI / UX design) on simplicity: "Do we really need X parts of the page all be affected / updated by something? How could we design it differently with locality in mind? Can we simplify the state somehow?" -> I think that the resulting solutions are often simpler, cheaper, and work just as well.
agreed: htmx is good for "swap out this one element and its children". It is not good for "and these other related elements need to update"
> It is not good for "and these other related elements need to update"
That seems a bit backwards, no? Why can't those other elements manage their own updates? You can have the server respond with an `HX-Trigger` header to dispatch an event and any elements that care about that event can listen for it. Far simpler than trying to coordinate surgical DOM updates in a single HTTP request.
Events form the backbone of the browser environment and leaning into that model makes a lot of things much easier
To a certain extent, it works, but there's definitely a point of complexity that you can hit in the app at which it becomes painful. Those are the kinds of apps where htmx is just not a good fit.
Not any more complicated than passing parameters to a function.
If that is actually the case, there is an issue with your component design.
You pull the state up. Props down.
To be fair, it's not an unfair response. Being able to hire for a technology, and having a large community around the tech stack you use has tangible value.
HTMX might not be something that will vanish in a week, but it's also nowhere close to a mainstream framework.
That's a fair response:
https://htmx.org/essays/when-to-use-hypermedia/#if-your-team...
the reality is that the only way to prove htmx is around for the long term is to stick around for the long term, and I hope this essay contributes towards that.
We'll see how this years JS rising stars shakes out.
Same story here, although the poison of choice is angular.
I built an HTMX fragment framework for Django. It allows you to render a fragment, and automatically serves the fragment separately for live-updates. I'll open source it tonight and post back.
In my opinion, HTMX + custom elements does everything React does but better, and is a billion times cleaner.
> I'll open source it tonight and post back.
Would be interested in seeing this
Sounds great!
People are commenting about "no new features as a feature", and I agree, but even better is this:
> People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed
Frickin A! Nice to see somebody pushing back against the trend of "if you haven't updated your software in the last five minutes you're on an unsupported configuration".
The classical joke:
Why programmers like cooking: You peel the carrot, you chop the carrot, you put the carrot in the stew. You don't suddenly find out that your peeler is several versions behind and they dropped support for carrots in 4.3
So if you have a project that uses a (even small) number of libraries, how to you keep track of being affected of some specific bug of some library?
A) New library versions are roughly as likely to introduce new bugs, as they are likely to fix old bugs. (If not, why are there still so many updates, you should be running out of bugs ...)
B) If you run into a bug, update that library, then look into fixing it and offering a PR with the fix. Easy-peasy.
Compared to: oh this is a bug in a library that's fixed in an update ... but then we need to update another library it depends on, but that requires an update to nodejs, but that requires us to update some other libraries, which introduce a new more serious regression, so we can't unless we re-write to remove that dependency ...
You submit a bug report and (assumedly) get a fast response because they explicitly prioritize fixing bugs over adding new features.
I guess in most cases you will be affected by bugs that you did not notice let alone report.
More reason to prefer a more deliberate release cycle! Focusing on security and stability restricts the area available to bugs significantly more than chasing hot new features all the time.
And also helps make for minimal changes when you ultimately find you need to move on from your current version. Probably why a lot of people stick with emacs/vim/whatever over every new fangled editor that comes out
>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.
I have been calling for this for a very long time even during pjax era. I hope that is not only an ideal but a realistic pathway forward. Chrome / Blink or Safari / Webkit. If we could just get one of them to implement it as experimental feature. How could we push this forward?
JPEG XL and HTMX in HTML, along with some sort of basic rich text editor for everyday writing is what I want browser to be included by default.
you can support and publicize the triptych project:
https://alexanderpetros.com/triptych/
https://github.com/alexpetros/triptych?tab=readme-ov-file
I don't want to bring politics into this, but I find the hype behind HTMX eerily similar to the populist vibes I get reading what their voters write.
There's this vague general sense that the "Web used to be simple" and that "Everything is so complex now". There's even an enemy that can be pointed at: React and various other frameworks/libraries and JS tools. Sometimes even JS itself isn't safe from this.
Though I can never find myself agreeing with the arguments (if any get presented at all). There's a reason we're writing web APPS instead of web SITES now even if you might dislike it. Just as there's a reason the world itself is now more complex now.
Ultimately I don't hate HTMX or the people who want to use it. Though to me the experience of actually using it is awful. I would ask people that they don't pretend that the backend ecosystem is any different from JavaScript. By the time you've chosen the language, debated the backend framework/chosen your templating solution and DB library and build system you could have gotten through the decision paralysis for JS too.
Glad to hear that ultimately you don't hate htmx or the people that use it.
htmx is a good choice for some types of applications:
https://htmx.org/essays/a-real-world-react-to-htmx-port/
it isn't right for everything, as I try to outline here:
https://htmx.org/essays/when-to-use-hypermedia/
i think i've been open and honest about when the hypermedia approach is appropriate and when it isn't and I've been open about posting bad experiences with the library:
https://htmx.org/essays/#on-the-other-hand
populist or not, i think the htmx website holds up pretty well when compared with other libraries/frameworks with respect to honestly outlining its pros and cons
Just out of curiosity, do you know of any hypermedia/hateoas open source repositories that you'd recommend as good example implementations?
The best I've found is the github v3 API but it would be nice to review different approaches.
When you are writing web APPs, you don't have to move as much logic to client as possible.
I was writing web apps in 1998, with table layouts, almost no CSS and no JS.
Of course, it was simple. It was so simple you can't imagine how. And it was the simplest in the golden age of MVC frameworks (like Django, Rails, Symfony) some 10-15 years ago. Since that, everything went downhill.
Building sign in form or some simple form with validation and saving in database was 2 hours of work, 4 hours with testing and deployment. Salaries of devs were 1/4. Now, it takes 2 days to make a simple form, backend API, sync two states, run it via myriad of builders and minimisers and deploy it to production.
Development now is 4 times less productive, 16 times more expensive for marginally better UX.
This simply isn't true. You are stuck in the past and unwilling to adapt and learn new, in fact, better alternatives.
I'm currently using Go with Ent and Gqlgen and Relay extension on the backend and React vite with Relay graphql client as well as React-oidc-context for oidc with zitadel as the oidc idp.
It doesn't take 2 days to make a simple form.
You need to get put your comfort zone and learn.
I built a classifieds site in 3 weeks. Including admin ui. I'd call that as productive as it gets. There's currently as library in the works where you will be able to tell generative AI to make a frontend just from showing it the graphql schema.
I am not stuck in the past. I moved to Clojure and jumped to devstacks just like everyone else.
Speaking of generative AI, I use and pay for v0 for frontend generation, tried Contember to generate backends from specification (the CEO is a guy I know for almost 2 decades), I pay for Cursor, ChatGPT, Claude Sonnet. I moved from Bootstrap to TailWind (which I don't like, to be honest).
But honestly, many things are just much slower than something like Rails/Django/Laravel+Bootstrap.
I mean webpack is slow, and css can be annoying sure, but c'mon, 2 days? I'm having trouble seeing that take two days unless you're doing a lot more than a form with two text input boxes and a button for signup and one for login in the modern version, which would make it an apples to oranges comparison.
2 days is fast. OP left out that most companies nowadays run a separate front end team, so now you need your backend team and front end team to have a meeting about what proper JSON should be returned, then the front end mocks that response and implements the form behavior, all the while the backend implements server functionality, then someone else (usually) tests this integration, then someone else deploys it. If nothing in that multi-team communication pipeline breaks you’re very lucky.
If you can all get that done in 2 days you’re running a very fast dev team. Minus the QA and DevOps team my point is that a SPA/JavaScript-heavy web app is not only a technological choice but an organizational one. Things used to be faster because there were fewer divisions in the software, therefore fewer divisions in the organization.
Expectations have also changed in various ways since "the simple days" when devs were the product managers, the implementors and testers all in one. Some things are better now, some things are worse.
I used to be able to churn out a form, naively, in two hours because I could just implement the elements, inline style them, give them a name and then go implement the backend form handler. Now there's a checklist of requirements: does it implement our design system, does it have test id attributes, is it responsive, does it work with password managers and auto populating form fillers, does it support internationalization, does it support multiple languages correctly, does it provide client side data validation, does the server return errors correctly and how should they be displayed, does it have rendering tests, does it have end to end tests, and so on and on and on.
Most of this isn't needed for a personal project or proof of concept but for a reliable product that millions of people use globally, a lot of it is table stakes or legal liability. You can certainly do it server side too, but the two hour effort window is still gone.
Most of this is automatically provided in those classic MVC frameworks like Rails or Django.
It most definitely is not and I've used Rails extensively.
It's not just 2 input boxes, unfortunately. It's also a backend part, adding sessions, requiring the user to be signed in. It is also sign out functionality.
In MVC framework, you just annotate a bunch of controllers, import Sign In and Sign Out functionality, and you are all set.
Another examples might be building data grids, CRUD functionalities, or more complex validation situations. Back then, you designed database, generated CRUDs, it automatically added Bootstrap CSS compatible classes. You added one beforeSave handlers to add extra logic, and it was done.
We web developers had to be competitive, because our competition were people using tools like Delphi, where you could drag'n'drop 30 screens in a day. It was ugly (default Windows 98 WinAPI look), it wasn't responsive, it wasn't prepared for people with disabilities, but it was hyperproductive.
Right… I think HTMX is cool and would like to try it. But the argument that “we need to go back to when things were simpler” just falls so flat to me. I remember the Web 20 years ago. It was pretty bad and ugly and slow and clunky and unintuitive.
We’ve made a lot of progress since then thanks in part to the powerful front-end state management and rendering solutions that are now standard. And if the argument is “we don’t need all that, I prefer simpler web pages…” then I just think you may have a totally different preference set from the average user. Normal non-engineers like sleek modern interfaces, not Web 1.0 forms and links and reloads
20 years ago we were using the likes of PHP4 or Classic ASP or perhaps Perl for server-side languages. Possibly the early days of VB.NET (ASP.NET) being a thing.
Some sites created 20 years ago were still not making use of AJAX, either. If they were, in very specific ways. It is more likely to be using IFRAMEs back then to achieve partial refresh.
Today, the difference is that we still apply "the old ways" building websites but with modern languages + htmx. This is the difference.
When I look at websites I have created or inherited, all I see if bloat crossing between code written on the server-side... and code on the client-side. The further back in time I go the more it was server-side but, as mentioned, begin to lack the AJAX side of it.
Personally, I prefer to be back to the vast majority being server-side code. Sure, the amount of Views (and Partial Views) on my backend codebase is much higher than before but it is still organised code and testable without even using a browser. I then let htmx do the magic onto the webpage.
I have success stories but I also mock some things I did in the past but with htmx and it is very promising!
Sure I am still using Javascript but it is not ready about the data anymore - mostly additional libraries used for better drop down features or other cosmetics/UI things.
EDIT - ADDED: It is worth noting that the last 20 years, despite various javascript frameworks from React to Angular to knockout to jQuery to MooTools, etc..... we also had Flash and Silverlight and other things. We also have HTML5, CSS3, etc.
I have tried many things in the last 20 years. I also accept that htmx, while my goto choice for todays web development... is not going to be the best choice in my future.
Web Assembly (WASM) is going to get better and more popular. It will not be about HTML coding like today or even javascript in many ways. They will still be there, of course.
(Javascript will always be there but its use will get smaller and smaller)
As someone else wrote: we have apps and not websites now and if you look at what was named "HTML5" it is basically a software platform where you can run applications on. It really is client application development today, html is just the UI lanuage for historic reasons, but even that is no longer true in all cases (I'm thinking of Flutter or Compose). So, maybe even HTML is not that relevant in many cases.
> we have apps and not websites now
Is it too out there to say that we have both, and that's not a bad thing?
> I don't want to bring politics into this, but I find the hype behind HTMX eerily similar to the populist vibes I get reading what their voters write.
Funnily I get quite irrationally conservative vibes the other way around. People clinging to their tools. All this complexity I learned must have been for a reason! We are building webapps for a reason (and that reason is valid for absolutely everybody and their use case)! "You youngsters do not remember the bad old days when everything was made of spaghetti, never again!"
Fortunately this is not a struggle for democracy but only a quibble in web development.
Your abstractions live either in the frontend or in the backend. For most cases, either will be quite fine.
> All this complexity I learned must have been for a reason!
It doesn't have to be so emotional.
Htmx can be helpful to keep all your state in one place, it's simpler to reason about and make changes. Lower cognitive load for the system is better for smaller teams and particularly lone developers.
You can accomplish the same thing by going full front end and minimize backend code with a similar small library that takes care of most to all of it for you.
Living in the front end, with all app state in the front end, has distinct advantages. Lower latency for interaction. Lower server costs. Offline capable. It has some cons like slower initial render. If you don't like JavaScript, JavaScript.
As a fullstack dev doing roughly 50/50 of both, massive agree. At least in JS land it's just JS, in the backend you even have to choose between entirely different languages sometimes, all of which have similar complexities to deal with.
By comparison, especially these days, making something like a Vue or React app couldn't be simpler. You run a single command and get everything generated for you, then you point it to one of a million free hosting sites out there and boom presto, you're live.
I feel like people are just afraid/cocky to admit they're too lazy to think about the frontend for whatever reason. All the arguments I've ever heard have been quite shallow and easily disproven if you spend, like, 5 minutes reading through some docs.
People acting like web dev was "simple" never fail to baffle me.
Remember Flash? Java Applet? ActiveX? Adding interactivity to web pages has always been abominable work.
I think it's less of a distinctly populist thing and more of a "convert's zeal". I have seen this type of language used with a lot of different technologies over the years when there's a lot of hype and momentum around them.
Ultimately there's just a lot of tradeoffs to make in this space and I'm glad that we have more options now. For awhile it seemed like you were either doing SPAs or everyone thought you were doing it "wrong", but things like HTMX, LiveView, Livewire, and Hotwire make it much easier to build good backend driven web apps.
Inertia.js 2.0 is a really compelling middle ground as well & IMO is the best thing to come out of Laravel. You can get most of the benefits of a JS "metaframework", but you have adapters for many different backend and frontend frameworks.
Right?
Did we forget Spring was a thing?
Did someone solve async Rust?
And the only thing more numerous than JS frameworks is new databases.
Let’s not kid ourselves, this has always been hard.
As a React developer, I love that HTMX is trying to aim for stewardship and "No new features as a feature". IMO, page router NextJS is perfect (and in line with the original API it pitched), and the bifurcation to app/page router has been complicated. Yes, I am fully aware that NextJS works with both app/page. I just find it mentally confusing to wrap my head around both worlds.
I feel this way about base React too, including -- functional/class components, hooks/non-hooks, and more recently, RSCs/Client components. Although I'm more willing to see React as an evolving research project, as contradictory as this may sound.
I’ve been bitten so many times with the app/page router thinking I was looking at docs for one but I was actually looking at them for the other. So annoying.
> No New Features as a Feature
No new features is such an underrated feature. It's funny sometimes when people see some Common Lisp or Clojure library with no commits in the last X period of time, and people immediately come to the conclusion that something must be wrong.
In the world of AI tooling, "completed" should have a huge advantage over libraries with lots of churn. Maybe a positive side-effect of new AI tooling is that there will be competitive pressure for libraries to reach a completed, no-new-features state.
I've found Htmx to be smug and misleading. "Look how simple it is! No JavaScript! Ignore the fact that you need a complex backend in a separate language and environment to generate your html."
Separate language is fine for those of us willing to write anything but JS. As long as it means writing less JS, a separate backend isn’t that big of a deal.
Not everyone is so scared of JS that we need separate silos for rendering in the browser and rendering on the server.
It’s not being scared of JS. It’s a weakly typed, poorly designed, gotcha-ridden, hodgepodge of a language. What’s there to be scared of?
It’s just people would rather write a low level, well-designed language than maintain JS codebases.
Consider it might not be fear but a strong dislike based on solid philosophical and/or aesthetic reasons.
Some of the people you're dismissing have probably been using JavaScript for a lot longer than you have.
There's nothing philosophically or aesthetically good about
or about or Htmx's own examples push you to code that is unorganized and inaccessible.Any non-standard HTML attributes look cursed to me, it seems like HTMX claims to be a solution for JavaScript excessive complexity but at the same time creating complexity in another place where is doesn't belong. There is a reason not XML but imperative C-like syntax stuck around for doing procedural things on the web
Ironically I can read through this code and know exactly what it does with no other context. I don’t even know what swal is but I can still tell what it does.
I mean sure, but compare that to
<button @click="doThing">
In Vue. Or just plain old JS onclick in Svelte.
By comparison, HTMX is illegible
What does "doThing" do? I can't tell by reading. The above examples, while maybe slightly verbose, are completely self contained!
Sorry was typing that on my phone so got lazy, `doThing` would be a method/function of some sort. You can also write it inline if you so wish, like `@click="console.log('hello')"`
That's not a common case and it's not that horrific.
And even if it was - I would be prepared to suffer a lot of pain to avoid the javascript build pipeline and framework churn.
SPA frameworks drove me away from front-end dev and HTMX is making me consider returning.
I feel like there is a middle ground which is being excluded. I'm leaning towards alpine.js or similar lightweight JS frameworks which have better ergonomics than react or plain JS. Webcomponents also without Vue or React are a nice solution.
Oh definitely - I'm not an absolutist. I just want to have the least amount of contact with those aspects of the Javascript ecosystem that take me further away from HTML over HTTP and progressive enhancement.
And I fully accept that "web apps" probably need complex frameworks. I just think most people aren't really building web apps - they are building web sites.
Dunno where you got the first example from, but in idiomatic htmx it would be:
Hardly the horror story you are trying to write.The second example: really? The words 'get' and 'trigger' don't tell you what it's going to do?
> Htmx's own examples push you to code that is unorganized and inaccessible.
You realize these are demo, ie sample code right? No one is forcing you to write exactly that code? You can write organized and accessible code in your own project?
Got it from right here: https://htmx.org/examples/confirm/
And the second example is not accessible. It should be a button.
A library’s demo/sample code should present best practices, not worst.
It says right there:
> htmx supports the hx-confirm attribute to provide a simple mechanism for confirming a user action. This uses the default confirm() function in javascript which, while trusty, may not be consistent with your applications UX....In this example we will see how to use sweetalert2 to implement a custom confirmation dialog.
It's implementing a custom confirmation dialog. Customized, non-default UI/UX usually means custom-written code in any framework I'm aware of. Maybe React has implemented magical customizations since the last time I checked.
React doesn’t require you to both abandon the principles of the library and write an inline string of code to run something slightly custom when you click a button.
htmx doesn't require you to write inline code in strings either, it's just a convenient compact way to do it in a demo. Also, it's not 'abandoning' any 'principles' because the 'principle' is to leverage small bits of JavaScript in a high-impact way. Eg, https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg
So where else will you put this code? A separate file? Multiple files? Maybe specific files for specific bits of UI? Maybe then you’ll need to handle bundling, transpiling, minification? Oops, we’re back to an evil pile of JS code that needs to be built.
Not really? HTTP/2 and ES Modules exist now, lol. And so does brotli compression done by my CDN. Bundling/transpiling/minification are basically obsolete technologies.
you can take anything in this type of context and it will look unorganized and inaccessible. react, angular, svelte, whatever-framework-du-jour … and much much worse than these examples
None of those will eval element attribute strings as JS.
every one of them has warts and insane shit
Why does it have to be a separate language? You can serve templates with javascript, thus it works just fine with HTMX. I think you have some fundamental misunderstanding.
If you're using JavaScript to render templates, why have an awkward disconnect between what renders on the server and what renders in the browser?
> No JavaScript! Ignore the fact that you need a complex backend in a separate language
Backend in a language that isn't JavaScript is a feature.
Also, a backend where you just serve a template instead of full layout (server-side rendered app) or JSON (client-side rendered app) is not more complex in most of scenarios.
Nowhere does htmx say 'No JavaScript'. We say 'targeted, high-leverage use of JavaScript'. And neither do we say 'ignore' that you need a 'complex' backend (backends do complex work, they will be incidentally complex to a certain extent anyway). We say HOWL–Htmx On Whatever you Like. It works with any backend and language you prefer and that's strength. Believe it or not, people use languages other than JavaScript.
Except you bill yourself as a replacement for React, Next, etc. No more components! No more state! No more crazy logic or builds or code or maintenance! Just use htmx, everything becomes so simple!
None of that goes away, of course, it just moves to a different repo.
We don't bill htmx as a replacement for React or Next, only for the use cases that make sense for its capabilities, which often happen to be things people are using React and Next for because that's all they know.
Actually, duplication of state, routing logic, auth logic, etc. really do get eliminated. Because we're maintaining all that on the server-side only and not having to reproduce it on the client side. It's a huge win.
Really? You’re keeping track of which slide Jane Doe has switched Carousel X to on the server?
I don't need to keep track of it, because that state is embedded in the hypermedia ie HTML page itself. Eg, I implemented a pagination component in htmx. It has a 'prev' button, a page display, and a 'next' button. If I'm on page 1 and I press the 'next' button, then I have my backend server respond with the next page and also a re-rendered pagination component with all three elements now pointing at their new correct pages.
So before clicking 'next':
After clicking 'next':Except these aren't pages. They're slides in a carousel. There's no data to load. The markup isn't substantively changing. But instead of just translating an element, if a user clicks on the next button, we make an http request to a server, wait for the server to receive it, wait for it to generate a snippet of html, wait to get it back, and then drop it in. That's a pretty laggy UI. And as a result of that replacement, you lose the focused element and any possibility for animation.
What happens when you click quickly? Does the UI just freeze until it eventually loads... some slide? What if you want a touch carousel using scroll-snap? How do you destroy and replace the entire section without interrupting the user?
If you want to have a purely client-side carousel then this is outside the domain of htmx :shrug: You implement the carousel on the client-side. Use whatever library you like. Personally I think web components are a great complementary fit with htmx. But here you've just moved the goalpost. What you said earlier:
> No more state!...Just use htmx, everything becomes so simple!...None of that goes away, of course, it just moves to a different repo.
With a purely client-side component, the state is managed purely on the client side, and the server would not touch it anyway. So it didn't have duplication of state to begin with, and htmx is solving (among other things) the duplication of state problem. So again–this example is not relevant to htmx.
Do you do this in raw react, or use some third party carousel library? If so, maybe something like that can be used with HTMX as well?
But your larger point stands, HTMX is probably not a great fit for highly interactive webapps, even though you can push it pretty far
"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."
This argument is that jQuery is still very popular compared to JS frameworks like React, etc.
What about vanilla JS?
As someone who isn't that experienced with JS, my understanding is that modern vanilla JS is "about as good as" jQuery. i.e. if you don't need much JS these days, just choose vanilla JS.
It’s functionally as good as jQuery.
However to this day I still find jQuery to be one of the nicest APIs to ever be used on the frontend stack. It is legitimately just more pleasant to write.
(Yes yes I am more than aware of how to shim a lot of it for vanilla JS)
That may or may not be the case (see https://youmightnotneedjquery.com/) but the fact remains that jQuery is used on 75% of all public websites.
That might be related to Wordpress including jQuery.
Those stats are pretty meaningless. How many of those websites haven't been updated in the last 7 years? Not that there's anything wrong with that, but the decisions they made a decade ago aren't necessarily still the best ones today.
How is that meaningless? It seems that web users of the site at least find it acceptable and aren't complaining enough to the site builders that they feel the need to change the website. AKA the website is standing the test of time. That's kind of a huge bonus when it comes to saving money and time to the website maintainers.
The point is that if you were to start building a new website from scratch today, the best tools for you aren't necessarily the most widely used ones. You have the option to start with a clean slate without any baggage. There are no upgrade costs. There are no customers who will get inconvenienced. There is no inertia. You are in a very different position than someone who has a website with millions of lines of jQuery already in use.
That website is (inadverently) one of the most effective marketing campaigns for jQuery. Some of the vanilla JS examples are atrocious.
What it doesn't show is that vanilla JS is not chainable (jQuery is).
What do you mean ?
map, filter, ... Simple string DOM elements Using a classthat classlist example won't work: https://developer.mozilla.org/en-US/docs/Web/API/DOMTokenLis...
Oops. You are right, I beg your pardon. Here's a working example.
HTML
JSCongrats you're reinventing jQuery. With a worse and more limited API.
Plus jQuery is one of the most battle tested libraries in the world.
That "ops" you made with classlist, you're bound to repeat these mistakes ad infinitum. And they can bite in subtle ways only your users might experience.
People rarely report broken websites unless they really need to.
I am truly interested in your arguments on why using chainable DOM Elements leads to less buggy websites.
You're the only one making that claim.
Plus using a homemade alpha version of jQuery written by one dev leads to more bugs, not less.
> That "ops" you made with classlist, you're bound to repeat these mistakes ad infinitum. And they can bite in subtle ways only your users might experience. People rarely report broken websites unless they really need to.
I think those two sentences are out of bounds, but I somehow get you. Yet I don't get the 'broken website' remark (took it condescending, or is it from experience?).
Mainly, I was replying to the affirmation that javascript is not chainable which is (imho) an indication of how one could get disconnected to the underlying lang by simply relying on libs such as jQuery (and I am thinking the same about htmx). Thanks for your reply!
Thanks again for a nice demonstration of having to reinvent the wheel to produce a poor-man's buggy reimplementation of jQuery.
Notice how the “modern” is almost always more verbose than JQuery.
JQuery might as well be a shorthand JS library.
Have a look at jQuery 'load' :
<https://github.com/jquery/jquery/blob/main/src/ajax/load.js>
Then at the vanilla JS 'load' :
IDK, all in all it is a proxy functions lib.I view JQuery as similar to C in some ways: It's been around forever, it's mature, and it works. It gives a good experience to get something up and running quickly: it's lightweight and simple.
But if you're working on bigger projects: It is possible, but have have to be very principled in how you use it, otherwise you're going to end up with either a massive spaghetti codebase and lots of edge cases in your app that breaks.
Alternatives like React and Rust may add more complexity upfront, but the improved structure and safety it gives has big benefits in all but the smallest projects.
Not so sure about that. You can easily write horrible code in React: Too complex, inefficient, and/or resource-intensive. If you don’t know the tools and have good theoretical programming knowledge, all code will be spaghetti code in the long run.
I'm no fan of React, but these aren’t equivalent. If you follow the rules, react (or any of its alternatives) will manage stateful changes like adding and removing components and event listeners. JQuery is more similar to doing manual memory management in C. It’s extremely easy to get it wrong and introduce leaks and other non-local errors.
React is also extremely easy to get it wrong.
Can you give an example? I mean I know you can shoot yourself in the foot with any UI framework, but jQuery has no way of managing state, everything just leaks by default. Unless they’ve added something.
I don't disagree, but this is not relevant for the vanilla JS vs. jQuery discussion, since vanilla JS has exactly the same problems you mention as jQuery.
it's a good API! and consistent!
"What about vanilla JS?"
Vanilla JS, as an experienced dev, is the best thing for now. You can write your proxy functions, and globally you get the control over every little thing.
Anybody have any thoughts on if the View Transition API is going to replace a lot of HTMX usage?
This multi-page demo is decent, where each click is actually loading a new page: https://view-transitions.chrome.dev/stack-navigator/mpa-prer...
https://developer.chrome.com/docs/web-platform/view-transiti...
> The View Transition API gives you the power to create seamless visual transitions between different views on your website. This creates a more visually engaging user experience for users as they navigate your site, regardless of whether it's built as a multi-page application (MPA) or a single-page application (SPA). Typical situations where you would use view transitions include:
> A thumbnail image on a product listing page that transitions into a full-size product image on the product detail page.
> A fixed navigation bar that stays in place as you navigate from one page to another.
> A grid with items moving positions as you filter through.
So this would cover a few uses of HTMX?
Recent Safari and Chrome now have decent support. Sounds like Firefox are working on it but I couldn't find an expected release date.
i think the transition API, when it is broadly available for MPAs, could replace a fair number of simple UI use cases of htmx. The main feature it would likely obsolete is the `hx-boost` feature:
https://htmx.org/attributes/hx-boost/
There are already people, including people on the core htmx team, who think that hx-boost isn't a great feature:
https://htmx.org/quirks/#some-people-don-t-like-hx-boost
If that goes away, htmx will be useful for smaller transclusional features at a lower level of complexity, so the two should complement one another in my opinion.
> If that goes away, htmx will be useful for smaller transclusional features at a lower level of complexity
Thanks! Any examples here to help understand where View Transition doesn't help?
I think active search (submitting requests as you type) is an example of something that View Transitions don't help with:
https://htmx.org/examples/active-search
I have used and like HTMX. But I think Unpoly is more batteries included, in a good way:
https://unpoly.com/
It has more built-in functionality that most web applications are going to need.
Unpoly is a great library that I try to signal boost frequently:
https://x.com/search?q=from%3Ahtmx_org%20unpoly&src=typed_qu...
I interviewed the creator here:
https://htmx.org/essays/interviews/henning-koch/
Also: https://mizu.sh/
It embraces a more structured and composable approach and I love that it embraces web-components.
From the article;
> 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.
I feel that is misleading. I worked on a lot of websites and none of them included jQuery willingly or sometimes even knowingly.
Either it's shipped as a peer dependency or we're talking about wordpress and the like which use it (and drives much of the web!).
I've seen it frequently shipped because of scripts embedded into a larger frontend codebase. Stuff they really don't want there to begin with.
I do not for a second believe that 75% of frontend dev work is in jQuery. In fact, I'd be surprised if it's more than 5% of all frontend engineering work is using jQuery.
Obviously some people might still use it for whatever reason; but those are a tiny majority (and probably quite vocal about it / over represented if they still prefer it).
So yes, to all intends and purposes I would claim jQuery is legacy software. Current usage (wherever they got that number from) does not mean it's still the preferred choice for the majority of web developers.
That number definitely needs some clarification. My guess is that if a single page uses jQuery on a domain, it counts, even though very little of the functionality depends on it. For a large organization with decades of legacy content, it's not hard to imagine jQuery is still used here and there.
I've been a Vue user for years, I do automations and glue code mostly, and most of the times using Vue is a bit too much, for my last project I used https://github.com/guyroyse/htmx-tailwind-vite and been delighted about it, it's exactly what I need.
I'd love to use HTMX at work. Sadly the security folks would probably balk at checking in JS code that uses eval(), even though you can disable eval at runtime in the HTMX config.
I thought about writing a script to remove all references to eval (and all tests relying on eval), but at that point it would probably be easier to just rewrite the library.
eval can be disabled at the CSP level, which is much better than at the source level (which can always be obfuscated, missed in a version update, etc)
It can be, but then you discover how marketing added lots of gtag and other content which is already full of eval ;)
oof
I see so many people praising the "no new feature as a feature" part, but hasn't semantic versioning already solved that problem? If you are on version 3.x.x of a library, why do you care if 4.x or 5.x or 6.x is launched, other than FOMO? Just keep using whatever version you want and let others have shiny new things.
There are so many sites out there using 4-5+ year old versions of React, and they all work perfectly fine. There's no compulsion to upgrade if you don't want to.
Because your potential dependencies will require 5.x as a peer dependency, so you have to use 5.x. Because your current dependencies will fix bugs or introduce features that you need in versions that upgrade their peer dependency to 5.x, so you have to use 5.x. Because the package itself will fix certain bugs that exist in 3.x but will only fix them in 5.x, so you have to use 5.x.
You can always submit a PR upstream or just fork the dependency. Ignoring the problem or new feature works too.
Ignoring security vulnerabilities tends to not work out so well. And sure, you can submit a PR. It might not get merged. Sure, you can just fork it. At that point you might as well use htmx.
I really wish htmx would use fetch rather than xhr, and now it looks like that won’t happen. Fetch is easier to proxy, so it would open up a lot more possibilities for backends, like ones running in browser or a native process. I had to hack together a xhr fetch proxy to make this happen.
https://github.com/logankeenan/xhr-fetch-proxy
we've looked at doing it but unfortunately fetch() doesn't fire upload events which would make implementing some events triggered by htmx possible
it's too bad the two APIs have overlapping but not contained functionality.
Are the upload events specifically used for files or for most server interactions. I haven’t noticed any issues with my proxy yet…
I'd love to see the single `htmx.js` source file annotated and displayed like the classic `backbone.js` documentation[1]
[1]: https://backbonejs.org/docs/backbone.html
[2]: https://github.com/jashkenas/backbone/blob/master/backbone.j...
[3]: https://github.com/bigskysoftware/htmx/blob/master/src/htmx....
I value the hard stance on stability and backwards compatibility over the constant churn that some JS libraries/frameworks have. I understand the need both approaches, but this is a breath of fresh air.
I also happen to think that most web apps have no business being so complex, and that too much work goes into dealing with the added complexity of running SPAs where an SPA is not needed.
Why is the added complexity of running HTMX better than the complexity of an SPA?
Because then I can keep the bulk of the logic in a language that’s better designed than JS. Not having to write JS is a huge feature. The added complexity of HTMX is abstracted behind a single library, and the bulk of the logic stays in a better-designed language—Go, Python, Java, Kotlin, Rust, Zig, C#, anything.
None of those languages can do anything in the browser.
With HTMX they can, because they make server rendered pages more viable.
When someone swipes a carousel, how will C# update the dom attributes and labels on the fly?
For stuff like this you can always complement HTMX with stuff like Hyperscript [1], also from the htmx authors or AlpineJS
[1]: https://hyperscript.org
it is sometimes much lower, if it fits your use case:
https://htmx.org/essays/a-real-world-react-to-htmx-port/
Good. For a couple of seconds, I feared something like "The next step of our wonderful journey...".
The creator of HTMX likes to periodically troll people on Twitter like this.
troll? wdym?
Love this.
The attitude of the htmx developers is highly commendable.
It is clear that htmx has a growing community, but it still feels a bit too backend-minded to convince frontend developers to adopt it. I tried it in a prototype, and it was quite pleasant until I realised I needed to account for additional state management and backend wrangling to be able to provide some dynamic features. That was the moment I realised htmx is not a fully fledged product but rather a core feature that sits neatly atop a traditional server-driven setup.
That's why I think their roadmap looks right. I believe the way to broader adoption is to improve tooling, encourage standardisation, and integrate htmx more closely with well-known frameworks. That's the only way I can see dev teams buying into the paradigm change and htmx jumping into mainstream usage.
The idea is to have fat backends and dumb clients. It’s definitely a different way of building things and not everyone’s cup of tea. For me, the biggest selling point is getting to write less JS.
Writing the bulk of the logic in Go, Python, Kotlin, Rust, or Zig is a huge plus, as I consider them better-designed languages with easier maintainability.
I'm huge a supporter of the HTMX philosophy. I highly recommend reading Hypermedia Systems especially for people that are just beginning doing web development. I've purchased the book and it was a wonderful read especially for its explanations and pragmatism.
> This means accepting and documenting the quirks of the current implementation.
If you're planning no new features as a feature, why not first remove those quirks? Why keep them around?
> People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed
Truly, there exists a middle path: you can make breaking changes and user still can upgrade at their own pace (using future flags, codemods, etc.), you don't have to refuse progress - it's just a "more" work for the creator.
> why not first remove those quirks? Why keep them around?
To preserve backward compatibility.
> there exists a middle path:...it's just a "more" work for the creator.
I think you just answered your own question. Unpaid maintainers of a free open source software project are trying to reduce their maintenance burden. This is normal and actually a good thing if it means they will be able to stick around for the longer term. Consider that you are asking a guy who has been maintaining open source projects for more than a decade, with some degree of success. So his strategy is probably working for him.
> To preserve backward compatibility.
What backwards compatibility? There is already migration guide from v1 to v2.
And the guide is mostly 'Everything is pretty much the same, just a couple of minor tweaks and default changes'.
Then why v2? If there are no breaking changes, why increase the major version? And if there are breaking changes, why not fix the quirks? Seriously, decisions like this show me the maintainers are just blinded by their lack of front-end skills, whining about JavaScript and striving for questionable "purity" - it's the same with the codebase (as mentioned by other commenters): one large unmaintainable file, because build step is too complex or whatever nonsense.
Anyway, excellent article and discussion that showed me I can forget about HTMX :D
Did you read the v2 release notes? The big thing they got rid of was IE11 support. Everything else was relatively minor. Having a bunch of breaking changes in v2 would have made the upgrade much more difficult for users, and a big part of their philosophy is making upgrades easy.
Of course, no one is forcing you to use htmx. Please use whatever you like.
That's true but we're doing it this way instead.
Are you tired, distracted or answering on the go?
A couple of your replies in this thread have seemed a little half-hearted. Sometimes it's better not to reply at all - or to reply at a later date.
I do have a pretty bad knee injury I'm dealing with. Maybe that's distracting me.
I briefly evaluated htmx with a go backend - and for simple navigation etc it works quite well. where I struggle is using more advanced web-components like datepickers etc. - as I dont want reimplement it from scratch.
any advise from others how they handle complex client side components?
I'm the creator of https://htmgo.dev and I'll say that is definitely the biggest issue I've run into with htmx. It's definitely not an overall replacement, you will have to either rebuilt the date picker from scratch in js, or find a vanilla js library
so unfortunately the major downside I see so far is it's fairly hard to find good open source vanilla js libraries for things, as most things seem to be written for react.
other examples include: - virtualized list - combobox
Iam using templ https://templ.guide/ in combination with htmx. I rebuilded various of html components of https://www.patternfly.org/components/all-components/ - but as you mentioned, I also couldnt find good vanilla JS libraries for more complex components - and I dont feel I am capable to build a e.g. battle tested datepicker from scratch.
How others handle this?
P.S. I have seen some people using e.g. flowbite, but I havent tried it out: https://github.com/themesberg/flowbite/issues/812
If you like this approach but want a full-stack JS solution, check out Joystick [1] (the philosophy [2] page echoes a lot of the same sentiments here).
[1] https://cheatcode.co/joystick
[2] https://docs.cheatcode.co/joystick/philosophy
It could be my inexperience, but something that helps manage state would be awesome. I’ve found myself having to do some pretty wild things to maintain a certain UI state server side. It could be that’s just the way it is too. Otherwise, I’ve used htmx a decent amount and really like it.
I am a fan of this approach. About to launch a SaaS now and htmx powers much of the interaction so far.
Tools like htmx make it easier for solo founders and small teams who don't have the bandwidth or the desire to manage all the churn. Keep the dependencies tight and ship!
Overhyped, back to 20 years ago. No proper framework in any language. And no it's not the new jquery.
You can't do real time time tickers. You can't call client side functions.
It's hyped by entry level web devs, because they don't know any better. You get all the baggage with it, that you hoped to be rid of with the separation of data provider and client consumer. Session management, path parsing and matching, flash messages, complicated nested if else blocks. Argh. Search engines can crawl js nowadays.
It's like going back to sysinit when you have systemd only worse. But HN never fails to hype bs tech
I’ve heard this kind of pushback from k8s wranglers whenever a small-scale alternative is proposed. The big win here is writing less JS and more of a language that’s better designed (aka not JS).
No, it's hyped by people like me, who were writing web applications more than 25 years ago. We want to do backend because a big part of frontend is complex for no good reason.
But it's not complex when you use the right tools. I did PHP professionally for 11 years and I waa bored out my mind of it. The repetition, the boilerplate, the stupid dogma and OO fetishism. And everyone in their freshman year suddenly knew better and tried to preach what they learned in Uni.
"But that's not SOLID and not OOP". But it's simple and does the job.
I moved to Go and AngularJS. That was 2013. I did full backend aka full ssr with Go, and it's a PITA.
I did try htmx with a jinja like template language in Go, with templ and in Rust and ... I forgot the library, it's the go to library in Rust for htmx. All the annoyances are still there.
Session management, service oriented design, if else blocks between and inside html tags. Path parsing and comparison. Template macros. And now also fragments.
Now I use a graphql backend for data, and react consumes it while the ide supports intellisense for queries. It's more simple than writing your queries by hand on the backend. You have interactivity for free. And you let the client worry about how the data is displayed. Also you let the oidc server worry about users.
Concerns are separated. I have authz middleware on the graphql backend, easily written. Everything has layers and there's order and a clean structure. As a plus I don't have to annoy my users with captcha. And I have reduced infrastructure costs as well as traffic.
I'm 50. My internet journey began 1995. I did enough of the old way to hate it and to know when something is better. I have met my share of fanatics, of language and framework Nazis.
You have to stay curious. I have tried htmx multiple times and found it inadequate, not good enough, too limited.
Like I wrote there are no frameworks in any language for it. It's just JS hidden behind html attributes, claiming it isn't JS.
I hate deception, the zealots are deceptive as all zealots in any language, package or framework are. Angular Nazis holy crap. Or React retards where you mention how Vue has simple SSR adaption and Rract doesn't, and are labeled as a React hater.
I'm pragmatic. I like clean structure and efficiency as well as simplicity. Sometimes you have to learn a bit of complexity to have it simple and efficient in the long run. I have tried many things. Ruby on Rails, Elixir. You know what, I have started programming at the age of 11 on the cpc 464 in basic, at 12 I cracked c64 games and wrote cracktros in asm. I'm one of the first cheat creators for MMORPGs ever. I don't consider myself super smart, but I have seen a lot and tried a lot. I also struggle with learning new things. But you have to. Htmx is not the way. It's a step back. It's only for simple things.
I do believe the hype when it's reasonable. Like with MVC. It was the natural way to write SSR websites. This is the way. But then something better came along and it took a while to solve the inadequacies it had. But now it's at a point where SPA + graphql + oidc = awesomeness. And it's going to become better. And I'm not talking about the Nextjs crap, those fake backend libraries that are hugely overcomplicated.
But tell us how you really feel.
Really, back 30 years if you think about it.
> the front end world in particular, which has comical levels of churn
Unbelievably so
Greatly appreciate this philosophy and what htmx brings to the table. It is very simple and quick to pick up, and the longterm stability and simplicity are major advantages for web development.
I did stuff with intercooler a while ago and loved it, I never got around to htmx, maybe now is the time
Even better:
https://leanrada.com/htmz/
Let's talk when it sends a request header marking requests for partial HTML fragments and supports history push ;-)
I'm so in love with the philosophy of this project. It's one of the few frameworks that I feel can do no wrong.
Everything listed here is a great pitch for vanillajs with zero framework at all.
Is jquery something people start projects with today? If so, what is the motivation?
I have, many times in the last 2 or 3 years... I still do... It's cheap and easy to implement, it's easy to use and it ads just as much cruft as I'm willing to tolerate. I build boring software, average CRUD applications for government departments, people in this line of work don't give a shit about millisecond delays or reactivity, hell, they don't even care about responsiveness... jQuery facilitates high speed development, provides neat functionality that doesn't get in the way, it's easy to maintain, and keeps people happy.
Even if you did give a shit about those things, all that can be achieved with jQuery. IMO the real downside of jQuery is not being as opinionated as other mentioned "technologies", which leaves too much room for thinking
Start? Not generally I don't think.
That said, back in the day it provided functionality that JS just didn't, or was quite cumbersome.
With recent JS versions, JS can do a lot of what JQ did for it, but JQ's API or "surface area" is still syntactically smaller and (IMO) more sane than those JS improvements.
I dunno, but it is included in many commercial libraries (free ones tend to be less reliant on large dependencies); a lot of people know it and a lot of people don't even know how to start bundling a node (or dino? what are people using now?) project; and it has a lot of extensions that really impress some people.
Besides it having a way more convenient API than bare JS. (That honestly, I only don't use because bare JS is conveniently documented by MDN, otherwise I think I'd be fully on it too.)
Yep, works great for simple projects.
Wordpress Themes/Plugins are still all over it.
~43% of the internet runs on WordPress[1] while ~75% of the internet uses jQuery[2], so even if you took out every website that used jQuery due to being built on WordPress, the number of websites using jQuery would be over six times higher than the number of sites built using react.
[1] - https://colorlib.com/wp/wordpress-statistics/
[2] - https://w3techs.com/technologies/overview/javascript_library
"I know it well" is really the only motivation you need. Why learn a new tool when you have used this one a hundred times before and know it'll get the job done?
If you are brand new to the space and looking to learn, then yeah stay away from jquery.
Start? Not really. However that doesn't mean there isn't active development and new features happening on projects that are already using jQuery, and so the expectations from that library matter.
I use jQuery when I want to finish a web project, not leave it in perpetual development.
If you haven't started your dev journey with React or some other framework like it, you actually know for a fact that they are not necessary an probably an overkill for a lot of web apps. Websites were built with interactivity, were lighter and worked better, before the dawn of slop-assisted SPAs and developers who don't even know how the browser and hypermedia actually works.
You saw 'jquery' in the second sentence of the text, immediately closed the link and started a comment with this question?
I've built https://golfcourse.wiki with heavy use of htmx.
Yes, my site appears a bit clunky (this is intentional), but as a solo, full stack developer working on a personal project, I wanted things to be stipped down and focus on having a solid backend and significant tests.
Htmx is perfect for this.
Is it elegant? Yes and no. Is it ideal? No. But what it does very well is let me focus on the code I'm writing (python/flask), without having to put three different hats on (frontend, backend, and interactive js), and it lets me code in the language I love (python) without forcing me into a gigantic javascript platform I don't actually want to be in.
I'm not getting paid for this, and I won't actually spend my time coding if I'm not excited about the way I'm working. Htmx let's me code the way I want to code and that's why I'm a big fan.
This is a great site, honestly the only thing to push it to the next level is to just polish up the styling. Aside from that it loads instantly and never had an issue clicking around.
Great work!
Thanks! Like I said, yes, the style could easily be improved, but it's really difficult to spend time on that when I'm working so hard on the backend. It's a low priority, even if it's a bad first impression for some people.
For example, the most recent update completely changed the way the index page loads, as I reverted it from Leaflet -> Maplibre so that I could use OpenFreeMap, saving $20+ per month in hosting costs, and allowing for vector maps to be used: https://openfreemap.org/
Thanks hyperknot: https://news.ycombinator.com/item?id=41635592
In that same update, I was able to add the "most recent week/month/year" for new and updated courses. After that update, I was overloading my flexible server instance with too much memory (oh, those for-loops and large lists). So, I then rewrote a significant section of the caching system!
The important thing is the "recent updates" lets people know the site is active. I got more than a few emails about whether it was a dead site in the last year (followed by random middle-man advertising pitches).
The reason why I think the styling is a low priority is that the site is targeted (for content creation) at older, non-computer literate folks at small clubs that would like to share their knowledge for posterity. It's also targeted at Wikipedians who justifiably know that this kind of detail about golf is inappropriate for Wikipedia, but still love golf. I'm not sure either demo cares too much about a site being super pretty.
The information ideally is targeted at golf nerds, but mainly junior golfers, looking for available information about relatively unknown course that they will be playing on in tournaments (hence the printable course guides).
i love frontends like shadcn/ui too much to go away from react - AS MUCH as I'd love to do it since I hate npm cancer to death
This is so refreshing to read
I use alpine and htmx. God above I have no idea how the more complex pages work. They're a maintainability nightmare. Still, Claude can write both and it works, soo...
> No New Features as a Feature
> We are going to be increasingly inclined to not accept new proposed features in the library core
I deeply wish the C# team recognized the value of this.
Why? C# has added a lot of good features over the years including lamda functions, generics, private functions, string interpolation, LINQ, etc.
Htmx always sounded nice and I always wanted to give it a try - yet, paradoxically, I always had my reservations about it on the conceptual level.
With something like Elm, I'm basically thinking of the frontend as a state machine (composed of smaller state machines). I always know what's [supposed to be] going on exactly, and assuming that all the underlying machinery is working as expected and that I haven't messed up anywhere, I can be sure that everything is consistent. Basically, things are data-driven.
Htmx feels like a step back in this regard. Let's say https://htmx.org/examples/delete-row/ - something back in my mind yells at me that I don't really know what I'm presenting in that table. The state is in DOM, all "inverted" as the frontend is not really aware what it's displaying (it can figure it out by introspecting the DOM, but that's exactly what feels off). I'm just concerned that it'll end up like my ancient Delphi or Visual Basic projects, where it was impossible to understand what's going on, because everything got tangled up in a ball. This is opposite of data-driven approach that I don't really know a name for... "shape-driven"?
I look at examples like https://htmx.org/examples/sortable/ and I just can't shrug off the feeling that with such design the frontend has no idea about what's going on, and while it's fine if all I ever need is a small sorted list (that I can pull back from DOM - which acts like a weird pseudo-database), if it grows it becomes error-prone, difficult to comprehend and maintain.
I suspect this is because HTML was always about documents, and never about interactive applications, so there's this fundamental impedance mismatch when one tries to build an application in a browser. I thought the solution was to build a new abstraction replacing HTML - with things like React being intermediate steps, still using HTML/CSS for rendering, and canvas-based GUIs being the way to go, unburdened by the document-based foundations anymore. In other words, I'm not really convinced that Hypermedia is a suitable foundation for a lot of the things people actually build online.
Htmx surely has appeal in simplicity, but doesn't this simplicity brings back all the complexity people tried to get rid of all this time? Is there something I'm missing? Should I possibly think of the frontend as a terminal-like system that can run small programs but is not an application so it's never aware of what's going on? Or is it something else?
My apologies for the confusion, or if I wrote something weird (I sure babbled a lot). I'm just trying to keep up with the world and understand it.
(And, of course, no doubt, one can write crappy incomprehensible mess of a codebase using any technology. Maybe all my issues is that I have no idea how to write good Htmx code that wouldn't bloat and rot over time?)
> Should I possibly think of the frontend as a terminal-like system that can run small programs but is not an application so it's never aware of what's going on?
Kinda? Where HTMX sits in my head is on a different evolutionary path starting from server rendered pages back in the 1990's. Instead of doing full page renders, HTMX lets us update discrete portions of the DOM from server rendered content... and that's all. It's like heavy client JS apps never existed. IMO, the key here is that the browser is assumed to be mostly just for display, and the backend is still expected to be inside the user interaction loop.
The last time I tried to do anything with HTMX, the technology practically resisted any attempt to add any substantial state management on the client-side (which is kinda/sorta by design). As you mention, complex controls that do this like fully-featured tables, are a poor fit. It's possible, but not elegant or easy. Meanwhile, fetching an updated fragment from the server to do those kinds of jobs on user input, is trivial. It's super inefficient for bandwith, but way easier to code and maintain (IMO). To me, that's the core tradeoff here.
The server-rendered web app (without htmx, think crusty PHP router admin panel) is actually very similar to the Elm architecture.
The database is the Model.
The server is the update function.
The HTML template is the view function.
HTTP requests are the Msg.
Database/API calls are the Cmd.
The problem with this model is that recreating the whole UI every time is slow and clunky.
Elm and most JS frameworks fix this by running the `Model` and `update` function on the user device and doing tree diffing. This is reasonably performant if you do it well, but it's also hard to do well (see: every website ever these days) and introduces complexity, particularly because the client-side `Model` almost always needs to be synchronized with a database or some other "canonical" model.
As pragme_x touched on in a sibling comment, what htmx does is not an iteration on the framework model; it's an alternate solution to the original problem. What it does to avoid the clunkiness is let the server to return `Delta HTML` instead of `HTML`, and for the slowness, it leaves the vanilla-JS escape hatch open for things that can be done without altering the Model (database). This model also has its flaws, especially if you need to use that escape hatch a lot, but it's also a lot simpler conceptually and keeps the `Model` and `update` function in a trusted computer, meaning you don't need to marshal and validate stuff between two models.
> how to write good Htmx code that wouldn't bloat and rot over time?
- Don't try to perform fine-grained updates if you don't have to. It's fine to replace a little more than you absolutely need to, and htmx takes care of some of the things you might worry about like preserving focus. For example, in the "delete row" example, it might be more robust to replace the whole table.
- Use htmx for anything "side-effecty", i.e. anything where a network request is compulsory. Relegate JavaScript to "micro-interactions". I consider a code smell in an htmx application any time I need to add new elements to the DOM via JavaScript, most of it should be manipulating classes, attributes and styles.
- For those micro-interactions, the "component" model heralded by the big three JS frameworks doesn't work as well here, since components have their own state, which is another "shadow-Model". Instead, try the RSJS methodology (https://rstacruz.github.io/rsjs/) with "behaviors".
- To wire up that JS to your app, reach for custom events. The `hx-trigger` attribute is the "port" that translates JS-based interactions to Msg.
> I suspect this is because HTML was always about documents, and never about interactive applications
This is a really common refrain and it peeves me, but I don't have a good rebuttal to it yet so I won't weaken my comment by trying to make one. I don't have good explanations for a lot of things about htmx and hypermedia, actually. The code of htmx is mostly complete, but the theory is still WIP.
Off topic but the other day I tried again to build a vanilla JS application.
By the end of the day having built quite a lot I then converted the entire thing to react within half an hour stopped wasting my time and got in with the job of building the thing.
I like to try library free JS every now and then and yet again it was not competition for react.
I know react, it makes sense to me, I find it easy and powerful, I know how to fix most issues and probably most importantly Claude is able to write react for me almost without me intervening at all.
I’m not saying react is for everyone but for me it’s a power tool that I know and the AI knows very well and it gets big stuff built quick.
I did something similar but I took it entirely the other way, I built a full CRUD application with no javascript.
The app is fully SSR and integrates with a fairly complex inline data enrichment and analysis system. I used Tailwind alongside regular CSS for the layouts and some visual enhancements. Eventually, I gave in and added a bit of JavaScript to submit a form when a dropdown is selected—usability is important to me. Other than that, everything works as needed.
You didn't really set the scene. What kind of application was it? If it's a fully interactive rich application with real time multi user handling, then sure. If it was a static page blog, then that's a problem (yet I see people do that anyway). There's a whole spectrum of interactivity and expectations here.
Question is, can you have a super thin layer that gives you the reactivity we all crave and don’t want to reimplement in vanilla ourselves without using legacy tech React.
In a way, it’s depressing that the thing that holds developer minds hostage gets even more hold over devs, because the frickin AI knows it best.
Just a reminder: React was created as a not-a-framework-but-a-view-library but everybody writes React apps, not JS apps.
> React was created as a not-a-framework-but-a-view-library
Honestly, I think this was the biggest mistake the React team made. It was never intended to be this way. It was just marketed this way in order to convince people to try it.
Once you started to use it you could very easily tell how it never fit in the traditional MVC model.
That’s great for you. But every single react project I’ve seen or inherited has been a steaming pile of shit.
All these new front end developers who jumped in on react with no other experience have no idea how web works are struggle to build without react.
Anyone competent in web development prior to react could build with htmx or even vanilla js just as fast without react as they could with react. Won’t stop the brainwashed react devs coming out defending their only source of income tho.
That's the fault of bad developers, not React. There are bad developers for each and every language, library, framework, and stack.
There are no good react developers because react encourages you to abstract things into 1000s is tiny files.
Isn't that like saying that a "competent" woodworker has to know how to use handtools first before trying to build anything with power tools?
What's the problem with starting from an elevated starting point?
I feel this article makes the same mistake many technical articles make.
What does it do? After reading a large chunk of the article, I have no idea. No, wait it "enables behavior".
Maybe it's only relevant to people that are already familiar with it. But it would seem that a hacker news front page would be a great opportunity to let more people know about your product.
Why should every article on a site restate the premise of the project? After all, this article doesn't tell me what React is:
https://react.dev/blog/2024/10/21/react-compiler-beta-releas...
> But it would seem that a hacker news front page would be a great opportunity to let more people know about your product.
It's on the front page every other week…
https://hn.algolia.com/?query=htmx
This isn't an announcement of a project. This is more a statement of their philosophy and what they are doing. This is targeted towards people familiar with the project.
i would recommend the homepage & docs:
https://htmx.org
https://htmx.org/docs
and if you want a more in depth treatment, our book (free online):
https://hypermedia.systems
This is just people's subconsciousness fighting against the rolling progress. It's trying to avoid learning new things and trying to preserve the status quo where you can keep rolling using the already acquired knowledge. It's anti-thetical to being a hacker.
The modern way is to use LLMs to auto generate all this code and do some small corrections in the process. So you wouldn't have to worry about the underlying tech and would only be concerned about the core functionality and actual mechanics of the product rather than being interested and spending efforts on memorization of the specific instructions for the machine. The whole evolution of the programming languages is a process in that direction and new technologies that were embraced by the newer generation like React and Vue.js is the way to go. You can't run geosites forever.
The philosophy of a tool like htmx encourages the opposite of "avoiding learning new things". The reality is that there is not often anything that is truly novel. We waste time by failing to recognize patterns and abstractions that persist over long periods of time and in many cases that are even foundational knowledge.
A foundational fact by definition does not need to be constantly scrutinized as if it were not. Rather it is something that can be relied upon stably until such a time that a change in a core assumption forces us to reevaluate the foundation if and when that scenario occurs.
> The modern way is to use LLMs to auto generate all this code and do some small corrections in the process.
it sounds a lot like correcting the work of a junior developer and it's definitely not what I want to do for a living.
> new technologies that were embraced by the newer generation like React and Vue.js is the way to go.
IMO, anything that requires a build step to the browser runtime is at best a temporary solution waiting for a web standard and at worst a regression.
It’s about using the right tools for the job. FAANG and developer advocates made the web needlessly complex for most people. The over-engineered tools and frameworks became the “default” way of programming for the web, loosing some strong key features that were good about it: simplicity, transparency, and speed.
> It's trying to avoid learning new things and trying to preserve the status quo
Well, yeah. Sometimes the status quo is good. Sometimes you don't want to learn how to do simple async page updates for the thousandth time.
Because many of us here have been there, done that. Over dozens of years. With dozens of libraries.
It's a hamster wheel. It's boring. It's pointless.
In the end, if your website/app does what HTMX is good at, just use it.
I learn dozens of new things every day as a solopreneur SaaS guy. I don't want to relearn how to make async page updates ever again, unless there is a very, very compelling reason to do so.