https://htmx.org/essays/when-to-use-hypermedia/
Also, please try unpoly:
It’s another excellent hypermedia oriented library
Edit: the article is actually not nearly as unreasonable as I thought based on the just-f*king-use template. Still prefer a chill vibe for htmx though.
Want to make a dropdown that updates a enumerated field on a record? Easy.
Want to make a modal dialog when users create a new content item? Easy.
Want a search box with autocomplete? Easy.
As I see it the basic problem of RIA front ends is that a piece of data changed and you have to update the front end accordingly. The complexity of this problem ranges from:
(1) One piece of information is updated on the page (Easy)
(2) Multiple pieces of information are updated but it's a static situation where the back end knows what has to be updated (Easy, HTMX can update more than one element at a time)
(3) Multiple pieces of information but it's dynamic (think of a productivity or decision support application which has lots of panes which may or may not be visible, property sheets, etc -- hard)
You do need some adaptations on the back end to really enjoy HTMX, particularly you have to have some answer to the problem that a partial might be drawn as part of a full page or drawn individually [1] and while you're there you might as well have something that makes it easy to update N partials together.
[1] ... I guess you could have HTMX suck them all down when the page loads but I'd be worried about speed and people seeing incomplete states
I'm currently working on a side project in Rails using Stimulus but sometimes I wonder if Stimulus is overkill with all of the controllers and stuff as well. Do you have an opinion on when you should reach for something like Inertia or Stimulus over htmx?
Said the horse with laser eyes (¬_¬)
Third link on the page ("read the long story") points to https://triskweline.de/unpoly-rugb/, which renders as a blank page with NoScript enabled.
Sigh.
Of course it will work. I can vibe code the most terrible web framework you have seen within 20 minutes and claim it is better than React, but what does it prove?
> You write zero JavaScript > The whole library is ~14kb gzipped
Oh sure, if there is nothing else in your UI, and if your Python/Go/whatever backend server has 0 dependency, which almost never happens.
I appreciate the basic demos, but I think what would really sell me is showing the extensibility story. Show me what it looks like when I need it to do something a bit beyond what it has in the box. Where do I add the JavaScript for that? Is it raw, inline, or are we back to packages and bundling and a build step? Am I building application JS, or some kind of extension or plugin to htmx itself? How chained am I going to be to its specific paradigms and opinions?
The page says htmx isn't for writing a true SPA like Google Docs, but where's the line? Show me an app that has pushed up against the limits of this system, and what happens in that scenario.
e.g. effect-ts which makes error handling, dependency injection, concurrency, retries, stack safety, interruptions, etc, simple but the hello world already hits people with "wait, it's 6 lines of code to print hello world!? Trash".
App (can take a few seconds to spin up if dormant): https://estimate.work/
source: https://github.com/basecamp/fizzy
I don't think this is a better approach than React. It's just an approach. It's viable. It's fine
Like c'mon, if I'm using Vue, I'm using Vue. Same for React. Strap me into the native state management solution for your framework, your router, your preconfigured bundler. I'm not here to mess about or I'd have just stuck with vanilla.
My startup did.
And now we’re going to rip it all out and move to a React front-end.
HTMX makes response handling much more complex. Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads.
And HTMX is still a fairly obscure library. The documentation and examples are lacking, there isn’t a real set of established best practices at scale, and not for nothing, LLMs aren’t great at it.
React is mature, used at scale, provides separation of concerns, and is great for agentic AI coding. HTMX has its place for simple projects, but for anything non-trivial, it’s a no for me.
Here is what my htmx apps have: - Single-purpose endpoints: Each endpoint returns ONE thing (a card list, a tag cloud, a form fragment) - Optimistic UI: Preferences like font/theme update the DOM immediately; the save is fire-and-forget with no response needed - Simple error handling: Most endpoints either succeed (return HTML) or fail (HTTP error code) - No fragment orchestration: Not returning 3-5 fragments; using hx-swap-oob sparingly
Here is how I update fonts on screen in user prefs: User selects font → JS updates body class immediately → htmx.ajax() saves in background → done
vs. the anti-pattern you're describing:
User submits form → backend validates → returns success fragment OR error fragment OR partial update OR redirect signal → frontend must handle all cases
No language or programming paradigm is perfect. All programming is an exercise in tradeoffs. The mark of a good CTO or architect is that ability to draw out the best of the technology selection and minimize the tradeoffs.
Well, frontend and backend always need to agree on every scenario, that's why I prefer to do validation on backedn and frontend to just display it and not do any validation.
Definitely sad to see this everywhere nowadays, tech choices made because of AI
When is this not the case?
Most of the frontend stuff I do is for internal pages on embedded devices, and I'm very happy with a structure where I have the frontend being a full React fancy component lib SPA that is eventually just compiled down to a zip bundle of files that the backend needs to know nothing about and can serve as dumb files. The backend is a JSON API of sorts that I would need to build anyway for other use cases.
You're argument is fine assuming you wish to become another react frontend in a sea of react frontends.
But the documentation example is a terrible argument, the benefit of HTMX is it is easy to understand what is actually happening. There is no magic, you don't need to dive through millions of lines of code to figure out what this is doing like react. It's very basic javascript. Just read the library, frankly you don't even need any documentation. Just take 15 mins and read the entire library.
And why would that differ from React?
When I was building a website with React, I needed to model a "apply coupon" endpoint with different states (coupon applied, coupon does not exist, coupon exists but has reached its max usage limit) and it was so annoying because you needed to
1. The backend route that returns JSON with a different model depending on the coupon state
2. The JSON models for each response type
3. And then on the frontend you need to load the data, parse the JSON, figure out which "response state" it is (http status code? having a "type" field on the JSON?) convert the JSON to HTML and then display it to the user
In my experience it added a lot of extra "mental overhead". It is something that should be extremely simple that ends up being unnecessarily complex, especially when you need to do that for any new feature you want to add.
When using htmx, a simple implementation of that would be
1. A backend route that returns HTML depending on the coupon state
2. Some htmx attributes (hx-post, hx-swap) on the frontend to make the magic happen
Don't get me wrong, there are places that you wouldn't want to use htmx (heavily interactive components) but that's why htmx recommends the "islands of interactivity" pattern. This way you can make the boring things that would add unnecessary complexity when using React with htmx, and then you can spend the unused "mental overhead" with the interactive components. (which, IMO, makes it a more enjoyable experience)
At the end of the day it is just choices: Some people may prefer the React approach, some people may prefer the htmx approach. All of them have their own upsides and downsides and there isn't a real answer to which is better.
But for my use case, htmx (truth to be told: I use my own custom library that's heavily inspired by htmx on my website, but everything that I did could be done with htmx + some htmx extensions) worked wonderfully for me, and I don't plan on "ripping it all out" anytime soon.
Whereas with HTMX you learn a very, very basic concept in 15mins, and you're good to go for the next decade(s), and it will be more than enough for 80% of your projects.
Same as with vim and Emacs vs. proprietary IDEs and text editors.
Because people don't like using heavyweight solutions needlessly. That's the logic that begat C++ and Ada and Multics and ASN.1 and CORBA. All of which were good solutions useful for "everything" in their domain. But people hate them, mostly.
Historically big "everything" solutuions end up losing in the market to lighter weight paradigms with more agility and flexibility. Almost every time. React[1] was such a solution once!
[1] Which really is a shorthand for "modern node-based web development with tens of thousands of npm dependencies and thirteen separately-documented API and deployment environemnts to learn".
Objection. Your React is ultimately turning into HTML so you DO have to learn HTML + CSS. You just have an abstraction over it.
No bundler required, no compilation step.
Alpine data objects can grow to be quite large, so you wind up inlining hundreds of lines of JS as strings within your HTML template, which often limits your editor's ability to do JS checks without additional config.
State management in Alpine is implicit and nested and not a serious solution for building commercial apps IMO.
And don't even get me started on unsafe-eval.
If it's your hobby app and you are the developer and the product owner, go for Alpine. If you're working at a company that is asking you to build a competitive web product in 2025, use a more robust tool. Hotwire and Stimulus has scaled much better from an organization standpoint in my experience.
And now I'm at the breaking point. So I'm planning to move to tailwind and Go templates, but honestly, i was hopeful for htmx, so I need to properly see the usecase. Which i don't know is this. It reminds me of Angular a lot...
HTMX is less noisy if you integrate it into your backend framework.
A contact of mine build a python/flask app. To simplify coding, he wrote a file to extend the flask framework to support the HTMX patterns he needed with just a single line of boilerplate. Took him about a day, his team is happy with the results.
If your solution is actually good, it will get adopted eventually...
Forget React, there's still stuff written in jQuery and JSP.
Why the rush to convert everything - you're not a missionary on a mission, just build your stuff in stuff you like?
The attack on npm is ridiculous, when (apart from introducing a permanent vulnerability in the form of a runtime dependency on a third party site), you still need npm for htmx.
I used to believe this when I first started in tech. The truth is even something as seemingly innocent as javascript runtimes now have an incredible amount of money behind them. And sometimes even marketing budgets. Deno released a high-production trailer for their 2.0 release last year
https://www.youtube.com/watch?v=swXWUfufu2w
I've also seen some really cool and well-thought out technologies simply not gain any traction.
The truth is you ultimately do need some big company behind you or major personality writing blog posts to ultimately make it.
Techies don't like to admit it but we're just as reliant on influencers as anyone else.
This has never been more incorrect. The entire world of software is people using garbage solutions because the CTO is convinced Oracle/Microsoft/what ever new random software is the best thing since sliced bread. In no fashion has the best software solution ever been a factor.
I wish this were true.
Unfortunately, often the things that get adopted are the things hyped up the most, not the ones which are technically superior.
Popularity, marketing budgets and inertia often dictate what's popular.
As with all biases, we need to actively and deliberately work against these forces, if we value craftsmanship and professionalism.
The idea that HTMX removes all the complexity is false. However it does remove some of it, and moves the rest onto the backend.
I find the backend easier to work with, so that's a win for me.
And a batteries included framework (like Laravel or Django) makes HTMX even more appealing. They already have everything you need! :)
In my experience, a lot of SPAs transfer more data than the front-end actually needs. One team I worked on was sending 4MB over the wire to render 14kb of actual HTML. (No, there wasn't some processing happening on the front-end that needed the extra data.) And that was using graphql, some dev just plunked all the fields in the graphql query instead of the ones actually needed. I've seen that pattern a lot, although in some cases it's been to my benefit, like finding more details on a tracking website than the UI presented.
Just look at the source code of amazon.com. It's a mess. But I bet it is more of an organizational problem than a tech stack problem, for a website worked on by literally hundreds of teams (if not more) where everyone crams their little feature in the website home page
However, I’ve recently made the difficult decision to rewrite the frontend in React (specifically React/TS, TanStack Query, Orval, and Shadcn). In a perfect world, I'd rewrite the python backend in go, but I have to table that idea for now.
The reason? The "LLM tax." While HTMX is a joy for manual development, my experience the last year is that LLMs struggle with the "glue" required for complex UI items in HTMX/Alpine. Conversely, the training data for React is so massive and the patterns so standardized that the AI productivity gains are impossible to ignore.
Recently, I used Go/React for a microservice that actually has turned into similarly complex scale as the python/htxm app I focused on most of the year, and it was so much more productive than python/htmx. In a month of work I got done what took me about 4-5 months in python/htmx. I assume because the typing with go and also LLM could generate perfectly typed hooks from my OpenAPI spec via Orval and build out Shadcn components without hallucinating.
I still love the HTMX philosophy for its simplicity, but in 2024/2025, I’ve found that I’m more productive choosing the stack that the AI "understands" best. For new projects, Go/React will now my default. If I have to write something myself again (God, I hope not) I may use htmx.
Any big reason to use HTMX instead? Is Turbo not really discussed much because of it's association to RoR?
I get server-side rendering. I can boot my server, and everything is there. If my model changes, I can update the view. It's cohesive.
I get client-side rendering. The backend returns data, the frontend decides what to do with it. It's a clear separation. The data is just data, my mobile app can consume the same "user" endpoint.
This seems like a worst-of-both-worlds paradigm, where the backend needs to be intimately aware of the frontend context. Am I not getting it or is there a massive implicit coupling?
Now if I need to display the same "user" data twice, in different formats, on my website. Say, as a table in "My account", and as a dropdown in the menu bar. Do I need to write two endpoints in the backend, returning the same data in two different formats?
Ultimately the frontend state cannot exist without the backend, where data is persisted. Most apps don't need the frontend state, all it really gives you is maybe a better UX? But in most cases the tradeoff in complexity isn't worth it.
The "two endpoints" concern assumes you're fetching fragments independently. If you're composing a full page server-side, the data is already there
Browsers keep changing along with people's expectation of what a website or app should be capable of.
Meanwhile on the backend land, the same MVC framework from 2 decades ago can still deliver acceptable results.
Why not "just use HTML"?
First - simple use cases sure great. But imagine you have to update some element out of the from tree. Now you need to have OOB swaps and your HTML must contain that fragment.
Not just that your server template code now has to determine if it is HTMX request and only render OOB fragments if so.
Even at decent size app, soon it turns super brittle.
Yet to talk about complicated interfaces. Let's not go complicated just think of variants in an E-commerce admin panel.
3 variants with 5 values each these are 125 SKU rows that must be collapsed group wise.
htmx can do it but it's going to be very very difficult and brittle.
So it is surely very useful but it is NOT the only tool for all use cases.
This is super simple to do if you are using a library to generate HTML in your backend programming language.
> Not just that your server template code now has to determine if it is HTMX request and only render OOB fragments if so.
This is literally just a function that checks for a couple of headers, chooses between two rendering options, and adds a `Vary` response header to take care of the caching. Hardly anything complicated.
> htmx can do it but it's going to be very very difficult and brittle.
The problem with this summary is that it misses the point–htmx is not doing backend stuff, your backend app server is. Htmx is just swapping in what the backend sends.
> it is NOT the only tool for all use cases.
The OP said exactly this, the htmx people have always said this, and no one ever claimed otherwise. There are people out there who don't think in absolute all-or-nothing terms.
The issue with htmx is that it is fairly prescriptive of how one should go about building dynamic interactions, and it becomes complex quickly if the dynamic interaction is more than trivial. I don't disagree with its philosophy at all (as I say, I use it for my own site) but it becomes an issue when my product owner tells me that I need to do some funny dynamic thing because it will make the business or clients happy (for some reason), and then it becomes a mission to wrangle it with htmx attributes. And I have to follow that, because as much as it pains me to say it, making stuff pretty and dynamic on the UI is an easy way to score points. It is one of those areas of enterprise software development which seems like a huge upgrade to non-technical people whilst not requiring too much effort.
The one thing raw JavaScript is quite well suited for is hacking together some DOM manipulation. I dislike JavaScript in every other domain except this - its in this arena where its leniency is very useful.
Okay, but on the other hand maybe you should do the right thing and say no.
I really liked HTMX, and I thank the authors for this marvelous library!
I switched from Turbo to HTMX because the latter is much more flexible, and I try to avoid Node.js as much as possible, only using it to compile some JavaScript code for Stimulus.
I finally moved from HTMX to Unpoly for the following reasons:
1. Layer support: Unpoly makes it easy to create layers and modal overlays, saving a lot of time and JavaScript code. You can achieve the same functionality with HTMX, but you have to write more code.
2. JavaScript code is better organized thanks to up.compile hooks.
3. HTMX and Unpoly treat fragments slightly differently. With HTMX, you have to use an out-of-band feature to update multiple fragments together. With Unpoly, you can easily add them to the response (and declare them in the front end, of course).
In my opinion, Unpoly has a better-organized approach to everything. On the other hand, apart from the official documentation, it is difficult to find examples for some edge-case features.
Given sufficient time and money (20+ years, and billions (trillions?) of dollars - which is what we've thrown at web apps) you could build GUI apps using the IRC protocol, but it will never work well.
LLM generated code probably tips the scales toward using react though. You can have the bots churn through all that boiler plate, it won't be any worse than what human react devs write, and keep the bots away from your mission critical code because it isn't all munged together like in a SSR app.
Ding! Ding! You win the prize. Absolutely correct.
The only reason react seems to look beautiful is because it's compared to custom JavaScript state management rather than the server-state paradigm that probably makes most sense for over 90% of apps.
The only real place it makes sense is when you're Google or Facebook and those 15 milliseconds actually translate to quantifiable lost user attention.
If your app is actually useful and not just an attention farm, those 15ms are almost never worth your engineering team's sanity.
Also, morphdom/idiomorph get you a long way even when you have highly interactive pages, especially if you have to hit the back end anyways. If you don't need to hit the back end then a front end lib is fine. But even then, the simpler pattern of hypermedia-driven applications can be better.
See https://github.com/jon49/Soccer as an example of this.
if you can imagine having just one "end", maybe you can use htmx
Well you didn’t write standard HTML attributes, you wrote custom attributes that are picked up by a JS framework, so potentially the worst of both worlds depending on your problem space.
Having tried HTMX a few times, the problem is firmly in creating a backend that feeds it properly. It’s a disjointed experience for anything more complicated than updating content.
To be honest this might be a skill issue or something I haven’t understood properly with these frameworks.
I personally prefer UIs with great encapsulation/composition, which used to be Vue, but with AI starting to write more of my UIs now I've switched to React/Next.js for new non-progressive UIs.
Thats the thing I don't like. I don't want parts of the structure of my page coming from the backend server. I just want that to send data, as JSON and for the front end to handle that into whatever structure it deems suitable.
That way all of the front end code is in one place.
Yes It has a "learning curve" but so does everything (even React).
Also Angular is now about twenty thousand times simpler than it was in the past as you can use Signals for reactivity, and basically ignore Observables for 95% of things.
Angular also removes the a lot of the negatives outlined in the page - no npm, no node_modules, no ecosystem fatigue, no debates on state management etc etc. Everything you need is included in one dependency you can load from a CDN.
I never liked that in react you are mangling the presentation and business logic in one tsx file (separation of concerns? React ignores that lesson for some reason). Htmx feels even worse in this way because now you also have html snippets and templates in your backend code too! Nightmare! Angular let's you leave the templates as standalone files and not mushed into your typescript like react (although you can inline them into the typescript if you want to, but obviously no one does that for anything apart from the most trivial of components)
It made the site look like a SPA without having to write any extra code. How cool is that.
HTMX resembled me this library. But it seems very narrow cased, there are only so many attributes and their values and you cannot implement anything else. While pjax is generic: you can attach it to any site which has links.
Also you cannot replace Vue (don't use React) with HTMX. For example, if you are making a diagram editor, HTMX won't be useful.
> "But what about complex client-side state management?"
> You probably don't have complex client-side state. You have forms. You have lists. You have things that show up when you click other things. HTMX handles all of that.
On the other hand,
> I'm not a zealot. HTMX isn't for everything.
> Genuinely complex UI state (not "my form has validation" complex—actually complex)
But my interpretation is that any UI which displays the same data in just two places (like a "new notification" indicator as well as bolding new messages in an inbox, or a list of articles which can change dynamically as well as a count of the number of articles) is "complex" enough that you'll need client side state.
> htmx is a library that allows you to access modern browser features directly from HTML, rather than using javascript.
From React website:
> React lets you build user interfaces out of individual pieces called components. Create your own React components like Thumbnail, LikeButton, and Video. Then combine them into entire screens, pages, and apps.
Apples and Oranges.
The main problem for me was storing/passing state between too many fragments. At some point some pages can become too complex to be manageable by HTMX, unfortunately. Lots of little fragments depending on each other, I began struggling to maintain a clear mental map of what was going on.
I'd say if React is more like functional programming, HTMX sometimes feels like GOTO programming.
I'm however more curious about going the other way, i.e. you start a project with Htmx which happily grows but after a while, a large feature is requested which inevitably changes the direction of the app into React use-case territory. I can't think of concrete example but you now have to work around it with htmx or commit to rewriting to React (or alternative). Wonder what are thoughts of people who had to deal with this
Hmmm.... I wonder why that is......
Your demo shouldn't have explicit lies, such as "It worked. That was an actual HTMX POST request. The "server" returned this HTML and HTMX swapped it in."
I mean, I guess maybe it made an HTMX POST request, not an HTTP POST request? But this does reduce my trust in the article.
Too bad that the world insists on going nuts with JS everything.
Oh as a plus, AI agents are a lot more productive when dealing with server side logic.
You can do this with plain old Javascript. Make a request, swap out the [inner | outer]HTML with the result. If you want a nice visual transition, wrap the swap in a startViewTransition(). Obviously, you need to be extra careful if you're using user-submitted HTML. Otherwise, it's fairly straight forward.
Agent one: handles the request and does tool calls
Agent two: reads the result and decides on quality vs a re-drive if it’s low quality
Agent three: decides how to present the information to the user, creates a collection of HTMX elements
HTMX hx-get is reliably, and beautifully rendering the result of the Agentic Workflow without any react, etc.
Very happy and passing quality gates. I love not having security alerts every week to patch because of some buried react dependency library
<button hx-post="/clicked" hx-swap="outerHTML">
No, I'll keep using hiccup and similar things that are just data and nothing more, no syntax, just functions and built-in data structures, then give me HTML as a string which consumers can do whatever with, and we're golden.
<a href=“/clicked”>click me</a>HTMX serves fully baked HTML that needs to be created on the back-end (or front-end-facing servers)
That is more processing than sending the raw data to the front-end and baking the HTML there.
It is also more bandwidth (unless the JSON is more verbose than the HTML generated).
Lastly, I can generate different HTML fragments on the front-end from the same client-side state with the data only being transported once. How is that working out?
Not necessarily. Often it is less. Template engines can be very, very efficient and fast.
Returning JSON almost always requires data/object serialization on the server, this is often slower than direct data/object -> template rendering.
Further, it's not your server but keep in mind the client must de-serialize JSON and render some HTML every time.
Modifying layouts as a result of non-persistent state (light/dark mode, sorting, etc) can usually be handled relatively easily with styles and data- attributes and sprinkles of JS. HTMX works very well with Alpine.JS and similar libraries for more complex situations.
HTMX isn't for every scenario, but it works very very well in many scenarios.
https://github.com/jon49/htmz-be
It's amazing how much further you can go when you flip the server as the one deciding where what should be updated on the page.
This was originally conceived by datastar and nomini also implements it this way. And HTMX 4.0 will have this as a first class citizen.
> the build time is over 30 seconds!
that's silly. 30 seconds building time is nothing compare to the accumulated time you wait for micro changes to your frontend.
for typical web development using react/vue/svelte you have hot code reloading, which can reload the current website < 1 seconds after you hit [Save] on your favorite editor.
for htmx to update, you have to wait for your whole server to reload (which can be way slower even you use interpreted languages like ruby or python, due to complexity of the framework you use).
not to mention it does not keep any state of the current website, make debugging way more troublesome compare to a js mature framework.
only people who never have to improve their website incrementally think htmx is a viable option. or insane people.
obviously, for some small websites with minimal interactions or no need to change the content very often, then htmx can be good, but for that case, vanilla js also works, and they do not need 14kb of excess baggage.
Only backend developers that think frontend is trivial and we’re all just idiots think that HTMX is the solution. They saw it working in their hello world side project and think they discovered gold.
> And suddenly you've got:
> A package.json with 847 dependencies
> A build step that takes 45 seconds (if the CI gods are merciful)
> State management debates polluting your pull requests
> Junior devs losing their minds over why useEffect runs twice
> A bundle size that would make a 56k modem weep
No? React is surprisingly small, and if you're in dependency hell then fix that. The alternative is another idiom.
And if you glue packages together you're basically reinventing frameworks. This can be a good thing or a bad thing.
Regardless of your choice between glueing libs or a framework, you'll end up with tons of dependencies for most non-trivial projects anyway.
Just pure eval(). [1]
1. htmx.config.allowEval: defaults to true, can be used to disable htmx’s use of eval for certain features (e.g. trigger filters)
UPDATE: the second visit to the page on Safari didn't have the issue. It's interesting to note that some people might have that effect though... reloads on Safari occasionally for whatever reason. Or it could be something rare on my end.
For things with heavy interaction (drag and drop, chat etc.), I find the code to make it work with HTMX is just too clumsy to work with as a mental model.
> The server just returns HTML (not JSON, actual HTML)
I like to separate presentation HTML from the data (returned from HTTP request). Some like to make backends that do nothing but serve the (singular) frontend, even running templates to make the HTML they return for easy consumption. That's not where I draw the line.
Dx resources must aim AI's attention having enormous technical documentation and be AI efficient in order to become mainstream.
I believe no other shiniest thing will ever make cognitive nest in humans. We are overloaded.
And every months a few of those modules try to exfiltrate your credentials…
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
https://justfuckingusereact.com
With all the examples people keep using, I assumed it would be way smaller. 16kb minified is a lot.
Looking at the docs just now the core api seems reasonable, but it a lot larger than I'd assumed.
https://github.com/bigskysoftware/fixi
1181kb brotli'd (no minification)
I'd bet that almost any site which isn't intentionally bare bones will have a lot more than 16KB of JS.
Oh now now, even senior devs do this too :)
I switched to Hotwire/Stimulus and found it to be a significantly better implementation of the same core concepts. I'd highly recommend checking them out.
Install an open source admin panel and call it a day.
You can use JavaScript for it.
I've been trying lately ruby templates with some occasional JS for this and it works great.
Or implement a straight forward web component.
They are standard, they work, they're great.
htmx is a great idea, but it's not necessary anymore. We're very close to invokers being baseline (and even that is just an extension of the "composedPath includes -> invoke" pattern), and that will take care of plenty of what htmx was designed to do. Between features like that, and web components, I'm very happy to stick with "plain HTML" (no frameworks; my web components do not draw from a core module or anything).
Also, just a suggestion because it's not technically wrong:
The example of sometimes needing an auto-completing search box is probably not the best one to use. I'm sure it's meant to say "you want the results to be queried from a server/database on every input", which you would certainly need javascript for. But the specific example of just having a search box autocomplete can actually be fulfilled with a datalist element. It won't dynamically re-query results, but it will filter based on input. So it's a muddy example, at best, and that's probably not great for the point trying to be made.
From what I've seen, invokers without extra code are designed for client side interactivity (e.g. showing a modal), which is orthogonal to the (correct, IMO) use case of HTMX. You shouldn't use HTMX to turn every custom user interaction into a network round trip, you should use it instead of fetching JSON. If a user interaction wouldn't trigger a network request if you built your app with react/vue/svelte/{insert_framework_of_choice}, then it shouldn't trigger one if you build it with HTMX either.
You can add custom commands with invokes and custom JS, but at that point you're basically re-implementing HTMX yourself, and I'm not sure what the advantage of that would be over hx-trigger="command" (especially when you also consider using fixi if you don't need all the features of HTMX). There's also the triptych proposals [2] from one of the HTMX maintainers which would add some of HTMX's behaviors to HTML, but those are a long way from being baseline, and may get there.
HTMX deals with loading content into the DOM, not managing display of the DOM.
They serve two different roles and together should handle the majority of javascript framework use cases.
Web Components does cover some of the same use case as HTMX, but is intended for when a server is returning data rather than HTML. It is both more powerful and more complex.
> the specific example of just having a search box autocomplete can actually be fulfilled with a datalist element. It won't dynamically re-query results, but it will filter based on input. So it's a muddy example, at best, and that's probably not great for the point trying to be made.
A prefilled list is never an acceptable solution for a search box. A search box is meant to capture arbitrary input. A filterable datalist is not a search box.
If you don't need or want all these and are happy with the worse UX, then of course you don't need htmx.
Re your suggestion: datalist makes you select an option, then fills in an input with the value of the option. Then you have to submit the form to actually get the resource you just searched for. Active search gives you the links to the resources directly in the search results, so you can load them with one click. There's a big UX difference.
Well why not have the benefits of invokers, but today - with HTMX?
HTMX could eventually switch its implementation to use invokers under the hood in the future, and you'd have the convenience of using declarative behaviors on your buttons, today.
> autocomplete can actually be fulfilled with a datalist element
I wish that the spec would cover more use cases, but last time I tried to use it, I couldn't, because it has really bad UX, and is inconsistent across browsers.
Also, like you mentioned, it only works for small data sets that you can deliver with the initial HTML, not large amounts of data which reside on the server.
You could argue that these are use cases where you wouldn't require an auto-complete in the first place, because the data set is too small.
[1]: https://astro.build/
I've built enough stuff in my time to know this is hyperbole at best and an outright lie at worst. I've never seen a team fail due to complexity. Team fails because the thing they built was wrong.
You should spend 99% of your time paranoid that the thing you're building is useful enough to justify its existence. Whatever tool you use along the way makes up the last 1%
That'll be item #848 in my 847 line package.json.
Why would you mock it on the client-side if HTMX makes it so simple??
And you can just return JSON from your API.
And you can add JSX later if you want.
CSS, HTML, Apache, MySQL and PHP.
Can someone explain something to me?
To my view, the single best idea React has is that it forces you to encapsulate the full set of states in your component - not anywhere else. For instance, if you have a "Comment" button that becomes "Submitted" after you click it, you must include that state inside the comment component. You can't hide it somewhere else (i.e., in the input field after you press cmd-enter). This is a huge thing for managing complexity - if you spread state updates to a number of different places, it becomes significantly harder to reason about how the button works.
Replacing the button with whatever the server responds with may sound simple, but it really makes it hard to answer the question of "what are all the states this button could be in". I mean, what if the server returns another button... which hits another API... etc?
The weird thing is that HTMX talks about Locality of Behavior (yay!), but doesn't seem to practice it at all?
BTW, one other thing:
> The ecosystem is why your node_modules folder is 2GB. The ecosystem is why there are 14 ways to style a component and they all have tradeoffs. The ecosystem is why "which state management library" is somehow still a debate.
> HTMX's ecosystem is: your server-side language of choice. That's it. That's the ecosystem.
Really? Python is my ecosystem. You know that people add stuff to their node_modules because they need it, right? It's not like we do it for fun. Where am I going to find a date-time picker in Python? Am I going to build it from scratch? Where is an autocomplete component in Python? Or mentions?
> Inspired by (and in joyful dialogue with) motherfuckingwebsite.com, justfuckingusehtml.com, bettermotherfuckingwebsite.com, and justfuckingusereact.com. Extremism in defense of developer experience is no vice! This site made by me. Does this all sound a bit like shallow slop? Yup, please help make it better.
I agree with you, and wrote a similar one for Markdown that you might enjoy. Same overall naming scheme. (Note: open the comments before you judge the use of a Web Component for rendering purposes.)
You're not a fucking person, this is LLM output.
It starts with the overdone sweary thing then mentions it's overdone and says it's not gonna do it, and it's almost enough to make me think the article is going to offer someone's point of view. But once again the LLM has erased any point of view the author may have had going in (or prevented them from developing it) and replaced it with a mediocre infodump.
I think this is the 5th slop I've seen atop HN in 24 hours.
> This site made by me, with tongue firmly in cheek.
Well, the LLM ruined it, and you didn't even tell us it participated.
This part is said really well, and applies to anything. "It's just a single weekend" is a cure to the whole "wasting time" argument/excuse that I guess a decent amount of people have - at least I know I do.
Really well written article, having both when to use and when not to use, is a nicely balanced view.
This means that in theory you (as a dev) don't need (to write any) js, nor do your users need to download a full page (for any interaction) like it's 1999. Your webserver replies with fully server-renderd HTML but just for the dom node (say a div) that you want to replace.
It's fun for very simple things, even great for extremely simple interactions modes. For interactive products, anything beyond simple CRUDs, it's madness.
Whenever you want to sprinkle a tiny bit of interactivity you'll have to choose between the path of least resistance (a small hack on HTMX) or a proper way. State management gets out of control real fast, it's the opposite of UI=f(state).
I've seen it go bad, then worse with alpine-js, and then completely ripped in favor of something where people can let the browser do browser things.
[edit for clarity]
The article doesn't define any target audience in specific, so there you go.