Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here:

https://htmx.org/essays/when-to-use-hypermedia/

Also, please try unpoly:

https://unpoly.com/

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.

I am tired of people using the smallest "Hello World" example to demonstrate how something is better than React -- "See, you don't need all these things to get a website up and running!"

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 did.

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.

I always thought the GWT->react branch of the webdev family tree was an inbred, unecessarily cumbersome compromise bred from JavaScript and performance metrics rather than descending from the beautiful code family we used to have with Rails and Django.

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.

The thing is React is usually fine, and even if you don't have to build _this_ thing in React due to simplicity, why bother learning two paradigms when you can just use the heavier one for everything and most likely never encounter any real practical showstopping issue?

Not HTMX but Alpine.js has been a complete revelation to me. What clicked for me was that you're enhancing server-rendered HTML, not replacing it. Need a dropdown menu? Add x-data="{ open: false }" and you're done. Want to show/hide elements? x-show does exactly what you expect etc.

No bundler required, no compilation step.

Ultimately the complexity does have to live somewhere.

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! :)

The proselyting over frameworks is the worst bit of the web ecosystem.

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.

Man I did try htmx, and I was hopeful, right until I saw how it polluted my codebase. I can't say I have the answers, but writing a pure Go app, I'm currently using one giant css file, custom styling and inline html.

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...

> After the user downloads 2MB of JavaScript, waits for it to parse, waits for it to execute, waits for it to hydrate, waits for it to fetch data, waits for it to render... yes, then subsequent navigations feel snappy. Congratulations.

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.

I've used HTMX on a personal project of mine. Other than HTMX itself, it used Go templates + Tailwind for CSS. As a backend dev with almost no professional frontend experience, I was able to replicate a fairly large and feature rich React app (which I was inspired by) using htmx in a matter of weeks in free time.

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’ve been a fan of this philosophy since the Intercooler.js days. In fact, our legacy customer portal at bomquote.com still runs on Intercooler. I spent the last year building a new version using the "modern" version of that stack: Flask, HTMX, Alpine, and Tailwind.

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.

It feels like the worst of both worlds, what am I missing?

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?

But I don't want SSR, period. My backend is an HTTP API that speaks JSON. My frontend is whatever thingimajig can talk to an HTTP API in JSON. That's it. I love it this way and see no reason why I should blur the lines between frontend and backend.

HTML over the wire frameworks like HTMX, Hotwire (rails), LiveView (phoenix), Livewire (laravel), LiveView (django), etc. They all have the same basic idea with differences in how they achieve it. I feel this approach is overlooked, and it drives me crazy. There is a huge complexity cost attached with JS frontend app + backend that everyone seems to have accepted as reality. HTML over the wire (really need a catchy acronym maybe HotW) can greatly simplify and speed up development with pretty much the same end user experience as a react app.

Datastar has been garnering my attention https://data-star.dev/

I just don't like having to send HTML and have the backend deal with what are really frontend problems. Sending JSON is great since you can serialize most reasonable data types into it and then the backend has no responsibility for how it is rendered which helps for having mobile apps use the same backend as the website. Sending HTML just seems nuts since if you change your design you would have to change the backend too.

I've had good success with Turbo (previously Turbolinks). The newer versions (ie. Turbo) really fixed up the shortcomings of the older versions (ie. Turbolinks) and I enjoy using it.

Any big reason to use HTMX instead? Is Turbo not really discussed much because of it's association to RoR?

This evangelism around HTMX is bit misplaced.

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 incredibly simple text-based website doesn't work without enabling JavaScript and allowing XHR in uMatrix.

Why not "just use HTML"?

Threads like these make me glad I’m not a frontend dev. Just looking at the comments it’s clear there is no cohesive view or vision or agreement. One giant Tower of Babel

> The server just returns HTML (not JSON, actual HTML)

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.

I like HTMX, I use it on my blog. But I will say, in the niche where I need some dynamic DOM changes without needing a full-blown SPA, raw JavaScript with some basic utilities like jQuery is not so bad.

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.

I would even say that even "just html" is enough for most website/app. We've been using "just html" at my company ( rosaly.com) for 5 years, we've raised 10 million, have hundreds of customer, and nobody ever complained. And the Android/Ios applications are 234 lines of React-Native which is just embedding a webview , a bit of error screen when there's no internet connection , and intercom library for notification.

I haven't used htmx, but I've given turbo a fair shake. I've only worked on server side rendered apps for my whole career, and they are generally they way to go. But just like react, or anything else, you throw enough engineers at it and it becomes a mess. But also you'll only find a handful of engineers who understand it compared to react, so that makes it worse. I think the bottom line is creating web UI is just as unsolved today as it was 20+ years ago, and nobody can make any headway - it suggests the fundamentals are totally wrong - after all - this isn't what http and html were even built for.

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.

Can someone who's adapted HTMX for a larger app report about front-end-server costs?

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?

htmx led to spaghetti code for me. react is too much to learn. using vuejs these days.

The Demo 3 Live Search example has really nasty scroll jank issues. I’m guessing it’s caused by the results being inserted inline in the document (and thus redoing the layout of much of the page) instead of being placed in some sort of overlay.

> No fetch(). No setState()

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)

> That's HTMX. I didn't write JavaScript to make those work. I wrote HTML attributes.

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.

What I don’t like with HTMX and the like is that you basically don’t get any help in the backend. It also introduces implicit coupling between the frontend and backend which is very much the worst kind of coupling you can have. While this is fine for small to medium projects it is terrible in the long run.

To be honest this might be a skill issue or something I haven’t understood properly with these frameworks.

I would recommend https://data-star.dev over htmx. It is more complete. But it depends on what you are building. Datastar does everything that htmx can do and much more.

The big problem I have with HTMX is the same one I have with React server components and similar concepts; I really like being able to just serve static files. Plus the clear separation of server and client really makes reasoning about a lot of different problem cases a lot easier, that's not something to dismiss lightly. (It's a bit of a 'ship your org chart' case, though)

I keep seeing articles religiously pushing htmx, what I'm not seeing are sophisticated examples or apps written with it, just more basic example and interaction examples.

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.

Please install a TLS certificate to the site so people can view the content.

> Option B: React (or Vue, or Svelte, or Angular if you're being punished for something).

> 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.

The author seems to have some beef with angular, which I have found lighter and more pleasant to use compared to react.

So we are almost back to using XSLT (and this is a good thing)

I have used HTMX extensively with AI agents. It is fantastic for dynamic views.

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

My main use of HTMX is to hack the Django Admin here and there. It works great for that. I’ve tried to use it in a moderately complex app and it became such a mess so quickly. I’m sticking with React for frontend stuff for now. Works well enough and I’m used to it now.

To prove the point, author mentions company that went from React to Htmx and saw positive change in relevant metrics. When you do that, it usually means your app has matured in a sense and you can be sure that htmx will be sufficient to handle all the functionality

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

For those who build in Ruby on Rails, does htmx have an advantage over Turbo/Stimulus? For me, the sense that it doesn't is why I've been avoiding it. Prefer to stick with vanilla stack unless there's a very compelling reason not to.

I did. I found it to have quite a few problems with bugs, docs, and web page lifecycle.

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.

> But sometimes—and here's where it gets uncomfortable—you actually do need a button that updates part of a page without reloading the whole damn thing. You do need a search box that shows results as you type. You do need interactivity.

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.

Can highly recommend HTMX with Astro[1] for pages that are mostly static.

[1]: https://astro.build/

Isn't this what html-over-the-wire/turbo/stimulus is? [1]

[1] https://hotwired.dev/

    <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.

> Or are you building another dashboard, another admin panel, another e-commerce site, another blog, another SaaS app that's fundamentally just forms and tables and lists?

Install an open source admin panel and call it a day.

> You do need a search box that shows results as you type. You do need interactivity.

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.

No, I'm sorry. Life is too short to write code inside of HTML attributes.

I love HTMX. It felt like a rebirth of PJAX. Server side template rendering is simply the best.

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.

HTMX is a great choice for an app that only needs forms, validation and partial template rendering, though CSS view transitions are making partials less relevant for server side web applications.

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.

This guy lives in extremes! His option 1 is pure HTML the only other option 2 is React! But it seems he never heard about VanillaJS to drive a button click.

> Any HTML element can make an HTTP request

> 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.

As the op may read along the other comments, we are tired trying the new shiny thing. Now it is AI's turn to get tired or never.

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.

>The "server" (mocked client-side for this demo

Hmmm.... I wonder why that is......

I liked the idea that htmx is good for those middle of the road cases where you're not doing anything fancy but I didn't end up using it very often though because if I'm not doing something fancy then I'm not going to ask my user to leave their terminal anyhow.

The framework has been built into the browser for a while now.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

I'm a big fan of returning html instead of json when possible and I've been htmx curious for a bit.

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.

For those wanting different colored pills, there are

https://justfuckingusereact.com

https://justfuckingusetailwind.com

https://www.justfuckinguserails.com

> Junior devs losing their minds over why useEffect runs twice

Oh now now, even senior devs do this too :)

I would recommend https://data-star.dev instead.

SimpleUI helps address the endpoint issue by autogenerating routes for HTMX. It's like a simulation of the frontend running on the backend.

https://simpleui.io

No. Why the hell would I use Angular 1.x style directives in 2026? For the simple contact form and todo apps, why would I even use client side scripting? Go away.

Are there any server-side frameworks that look like HTMX in the browser but allow writing functional-style code for managing all that HTML mutating itself?

I'm a big fan of it for building micro websites with LLMs, since it can keep pretty much the entire thing in context (even including the docs) it seems to perform pretty well.

I would say please just try Web Components.

They are standard, they work, they're great.

What are some large websites using HTMX? I'd like to check them out.

Ofc if you really want to lose bloat, there's always Htmz

https://leanrada.com/htmz/

Sorry, but it's a no from me.

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.

Has anyone tried using HTMX + some realtime query layer like Convex?

> The ecosystem is why your node_modules folder is 2GB. The

And every months a few of those modules try to exfiltrate your credentials…

Latest iOS Safari: the viewport jumps around on all those demos. Really hurts your case.

There is inherent risk of such low level frameworks over React, that is they allow you to easily blow your foot off, by injecting raw unsanitized HTML back for dynamic execution. A thing that would not work in React apps by default. Even on those demos, you can XSS yourself with the simplest payload, confirming my point.

Mitrhil.js is 8.8 kB gzipped.

And you can just return JSON from your API.

And you can add JSX later if you want.

What you need is more f-bombs in your article.

I don't get why people don't just use vue... with no build step, just including it.

> Honor obliges me to admit this is not literally true. bettermotherfuckingwebsite.com is a fucking pedagogical masterpiece and reshaped how I built my own site. But let's not spoil the bit...

> 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.)

14kb gzipped file? sorry no.

Just use the CHAMP stack. Like it's 2005 again.

CSS, HTML, Apache, MySQL and PHP.

To be honest, none of these new-ish frameworks are good because there’s not enough data to train LLMs. React/NextJS is great because I can 80% get there with LLMs.

> The whole library is ~14kb gzipped

That'll be item #848 in my 847 line package.json.

This is a retarded advice. Author clearly never tried to develop any serious web development.

> 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.

Was hoping for a sandbox so I could actually try it!

You don't need React or HTMX; just put onclick= on your element and make your call with vanilla javascript. Use these frameworks if you want, as they're both neat, but frankly I think people forget that there are other options

> When you click it, HTMX POSTs to /clicked, and whatever HTML the server returns replaces the button. No fetch(). No setState(). No npm install. No fucking webpack config.

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?

No

This fucker didn't even bother showing us some real POST requests. And he actually wrote JavaScript to make those work.

Why would you mock it on the client-side if HTMX makes it so simple??

> Most teams don't fail because they picked the wrong framework. They fail because they picked too much framework. HTMX is a bet on simplicity, and simplicity tends to win over time.

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%

But how to actually manage non trivial state? URLs get big pretty fast

please, just use html/css and some javascript where applicable.

Do not use HTMX for anything other than very simple CRUD apps. The vast majority of the time you'll be wishing you had client side two way data binding and state management. If you want "simple and not React", just use Alpine.js. It has way better ergonomics and features than HTMX and can do essentially everything HTMX can do.

No huge JS frameworks, no build steps, no state hell

I'm the CEO of HTML. I approve of unpoly. A+++++

Even if you do have complex client-side state: dataos.software

If you never seen HTMX it is a small js library that lets you swap some part of your dom with the responses from your webserver.

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]

I haven't used HTMX but the author doesn't make a very convincing case. On the one hand they say,

> "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.

> "I'm not a fucking saint"

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.

The author has never heard of jQuery

please just try TLS

Can we see a styled date-time picker in htmx?

_another fucking framework_

Yet another thread of React vs the rest of the world. Each has its use case, and most of the time, React/Vue are largely overkill. Personally, I would never, ever, ever start another React project again. The nightmare of the horrible JS ecosystem, build steps and tooling is behind me. All my projects now use either HTMX or Alpine Ajax - and for web apps that are actually pretty large. It works perfectly fine. Add Turbo to the mix and you almost have the feeling of using a real SPA, without the headache and large bundled JS files. Feels refreshingly simple. Still have to figure out the no-build step so I can completely drop Bun/Yarn/Npm, and life will be a wonderful thing.

..and be unemployed.

The article doesn't define any target audience in specific, so there you go.

what is the use case. I did not read the page. Can you tell me where stars live?