One of the most frequent questions I've been asked over the last year is…
Have you heard of HTMX? What do you think about it?
Today, I'm finally going to answer that question.
(Spoiler alert: I don't like it.)
Let's dig in!
What is HTMX?
HTMX provides attributes that you can use to write interactive HTML components declaratively in your markup instead of separately in a JavaScript file.
Conceptually, I love that! It's a big part of what I love about Web Components, and why I advocate so strongly for them as the backbone of resilient, maintainable front end.
Quick aside: if you need help setting up, extending, or fixing your front-end architecture, I can help with that!
But in implementation, I think HTMX falls way, way short.
It has all the same problems as other frameworks: a big footprint, vendor lock-in, and seemingly no focus on accessibility.
The Motivations
The HTMX website lists four "motivations" behind the project…
- Why should only
<a>
and<form>
be able to make HTTP requests?- Why should only
click
&submit
events trigger them?- Why should only
GET
&POST
methods be available?- Why should you only be able to replace the entire screen?
By removing these arbitrary constraints, htmx completes HTML as a hypertext.
So let's talk about these questions, as well my comments around footprint, lock-in, and accessibility.
A bit footprint
The HTMX website says…
htmx is small
But, frankly, that's not true.
While the minified and gzipped version of 15.7kb, the actual uncompressed script is 47.8. Smaller than React, sure, but not "small" in my opinion.
Preact weighs less than 12kb without gzipping!
And for that size and abstraction you're getting stuff that you're probably not going to use. It's the Swiss Army Knife problem I talked about yesterday.
Vendor lock-in
This is "the big one" for me. HTMX uses an hx-*
syntax for its various attributes…
<button hx-post="/clicked" hx-trigger="click" hx-target="#parent-div" hx-swap="outerHTML" > Click Me! </button>
That means that once you start using HTMX, you're looking at a big rewrite if you want to move away from it.
That's true of any script or library, of course! But using smaller, more focused Web Components to do the same thing means you migrate or update that one component, without a dependency on a bigger library.
And, if you want a button to make a POST
request, like in that HTMX example, you could wrap it in a form and have meaningful HTML that has a server-based fallback!
<!-- A Web Component Alternative --> <ajax-form target="#parent-div" swap> <form action="/clicked" method="post"> <button>Activate Me</button> </form> </dynamic-button>
Accessibility
The documentation includes examples like this…
<div hx-get="/clicked" hx-trigger="click[ctrlKey]"> Control Click Me </div>
That div
reacts to click
events. But a div
isn't focusable, nor does it indicate to screen reader users that it's interactive.
The HTMX homepage asks…
- Why should only
<a>
and<form>
be able to make HTTP requests?- Why should only
click
&submit
events trigger them?
Some of this stuff is legacy architecture decisions, but some of it is driven by accessibility and how humans and machines interact with each other.
You can't ignore that stuff just because it's inconvenient.
By removing these arbitrary constraints, htmx completes HTML as a hypertext.
Is it arbitrary? Maybe, in some cases. But it's still important.
Valid questions
HTMX does ask some valid questions…
- Why should only
GET
&POST
methods be available?- Why should you only be able to replace the entire screen?
I'd love to see form
elements add support for PUT
and DELETE
methods, frankly.
Is it critical? Nope! You can still do all the same stuff you'd do with those methods without them. It would make things a bit nicer for for talking with APIs, though.
And a browser-native way to implement islands architecture could be interesting. I'm less convinced that's a critical need for the platform, but I do think it's a potentially useful addition.
If not HTMX, then what?
Web Components. Hands-down.
You can do all of the same stuff, but in a small, modular, portable way. Web Components work great on their own, and can also be mixed-and-matched with another library of your choice.
Cheers,
Chris
Want to share this with others or read it later? View it in a browser.
0 Komentar untuk "[Go Make Things] Why not HTMX?"