Given the number of people claiming to be CEO of HTMX, I have to ask: what’s the joke I’m missing?

As a former CEO of HTMX I thank you for your service as the current CEO of HTMX.

> I really like htmx

> Full Disclosure, I am CEO of HTMX

i think you've found a good job!

HTMX 4 is 41KB minified, why not use just plain HTML and a single inline 166-byte (sic!) onload handler named HTMZ? https://leanrada.com/htmz/

Could local-first HTMX ever become part of the standard library? So it could be used easily with a simple static web host?

The board chose well, they are good boys.

[flagged]

Agreed.

In fact, I find Django and Postgres to be the best solution for htmx but Go stack is probably almost as good in terms of developer velocity and obviously much faster. So I think that's a good solution.

You can really build powerful production apps with htmx, and what people underestimate is how good it is with AI assisted development (Claude understands it and does it well, and if any JS glue logic on a specific template is required, it's pretty well written and not a mess).

I call it the GOSH stack (Go Sqlite Htmx) but HUGS is good too.

I go with rust/datastar.

I actually think JSX is better, but I am bored of it because we don't need state in JS no more.

i use this stack quite a bit too. i made the claude do some load bearing 360 backflips, gate and seam a whole buncha smoking guns, and bolt go-starlark on top of this so i can just declare little web apps like its streamlit but it doesn't feel sucky like streamlit. i get to just write little blurbs of python-looking code and i get these fully reactive tools. probably my favorite and most used abstraction that came from too much wine and lazy boredom. also built stupid simple framework ish coverage for connections and duckdb and a few other things.

Oh wow, interesting combo that I would never independently reach for, but thanks to your template I might have to give it a whirl!

If you want a prototype fast, don't you use an LLM?

And if you do, why start with a simpler framework?

How are you using dbos with SQLite? The docs say its a Postgres library

I also like the same stack, as it plays very well with a terminal focus workflow.

I agree. We are moving away from HTMX at work, to React. (After we moved away from Angular. That was…a choice…that I didn’t make.)

Here’s the thing: there’s still a place for HTMX. Lots of places. But “building an SPA but not actually and SPA” is not a lane for HTMX. Nor do they promote HTMX for that purpose. Really quite the opposite.

Different tools for different jobs. (Me? I honestly love React, just a more minimal stack. Zustand and TanStack and Vite. No Redux or Next.JS)

I don't understand (possibly because I lack Angular experience): what is it about a .NET backend using HTMX that requires presentation concerns to be mixed with business logic?

Don't you have to maintain that separation either way? Your core/application logic shouldn't know how its result is ultimately represented. That could be JSON or HTML over HTTP, Protobuf over a TCP stream, or a custom binary protocol over a Unix socket.

Obviously those representations matter at the presentation/transport boundary, but why should choosing HTML force that concern into the business logic?

> ... managing state on the server is not fun at all.

Do you not have a database for your backend? Managing state is kind of their thing.

I agree this is a scope or focus thing. Different tools for different things.

If you are already maintaining a tool chain, a supply chain and skills in an SPA framework for multiple customer-facing, client-driven projects, I don't think you have much of a use for HTMX. Hence why at work, we have our full-time frontend engineers doing this, because it gives you the most flashy quality.

I am an infrastructure engineer. I have privately tried out a couple of SPA frameworks, The complexity to set this up for the first time is immense. And if you have rarely touched projects, the churn of the tooling and dependency ecosystem is taking up a significant amount of time for something that may be nice to have at work, or a pet project at home.

It's not cool if you have half a day to touch an old project and everything has rotted away around it so nothing interesting gets done. Something like Pydantic, Flask or Django + Jinja generally doesn't do that. And HTMX can make it nicer fairly cheaply.

There are an army of people using SPAs for problems best served by a simple and more traditional website. It has been a thing since SPAs started showing up so you have a whole generation who think that Next.js is just how you build for the web.

Then HTMX is to them what the micro-ORMs were for me (and, if you've been in .Net for a couple of decades, I suspect you too).

> managing state on the server is not fun at all.

Really? I've never found that difficult. Sessions exist, URL parameters exist... Perhaps in a complex SPA you can have trouble, but so many of the "applications" I've worked on are just glorified documents.

I'll shill datastar for a second, there's barely a notion of frontend state management if you treat HTML as a projection surface with interactivity. I'd argue HTML is the most efficient wire format for interactive web apps, especially with streaming + compression.

Seriously DB->json->client->toHtml

DB->toHtml->client

Just imagine if that html wire format also conveyed the interactivity too and you eliminate the issues. And you can always seperate whatever concerns you want in whatever tpl lang of your choice.

Also htmx 4 is kinda just an worse datastar funnily enough In it's own way.

I totally agree. When we started splitting presentation from content (CSS) that was a wonderful step forwards. And splitting back-end and front-end concerns similarly makes for a cleaner and more elegant design in both codebases.

IMO HTMX is a weird regression in our design patterns. Hopefully a temporary anomaly. I'd never choose to work in a company that adopted this mixing of front and back end code - it's a red flag as far as I'm concerned.

For me htmx is a utility library to spruce up a couple of interfaces here and there that benefit from a bit of reactivity. Anything more complex I really don't feel that it's the right tool. Or that there is any great tool to build SPAs.

There is sometimes this trends on projects of using anything like a universal hammer. And then they SPA their project.

> mixing presentation concerns with business-logic

That's on you not on your platform

I had a similar thought when someone linked [1] Mike Acton's "Data-Oriented Design Operating Rules" [2] written for agents. The text is Claude-y, but the step-by-step DOD guidance is neat, it specifies a development protocol the likes of which I haven't seen elsewhere, besides in Mike's talks (in less detail).

1. https://news.ycombinator.com/item?id=49062520

2. https://github.com/macton/nagent/blob/main/context/data-orie...

It took me a long time to grok what htmx even was from barely glancing at news articles about it every once in a while. If I'd seen such a concise text explanation I'm sure I'd have got it immediately! Lesson learned: go to LLM docs first I guess?

It's removing all the unnecessary words and fluff. FWIW I adhere to RFC-2119 when writing docs, and tell agents to do so as well.

great library, we link to it on our alternatives page

TIL! One more reason to like gov.uk. I had no idea this was a standard but in hindsight it's quite obvious that's the case. I wonder how much of a burden it is at times, and how one can enforce this with automation?

[dead]

What about vibe coding makes HTMX something that you speak about in the past tense? Are you just generating frontends in vanilla JS now?

As fellow CEO of HTMX, I approve of this statement and concur. I think our next major moves will be to monetize our assets [0].

[0] https://www.youtube.com/watch?v=GyV_UG60dD4

> Like it or not, a lot of people are using LLMs and we are providing the following skills files for

For what? Don't leave us hanging!

Well, if someone is going to vibe code they don't have enough background on searching a good tool. They'll just ask LLM and LLM defaults to a Javascript based thing

You found HTMX?

oh man that's embarassing, someone made that on twitter I didn't realize it was from omarchy, I've removed it, my bad

I think that's the joke

Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise.

Perfect is the enemy of good and all that. If something is useful, it’s possible to fix the architecture later. The only counter-example I know of has been GitHub, which was built on RoR and so poorly planned that it’s still biting Microsoft on a regular basis.

htmx is based on the ideas of hypermedia, you can read the first chapter in our book on the topic here:

https://hypermedia.systems/hypermedia-a-reintroduction/

HTMX is a layer on top of server-side rendered HTML that gives you near-SPA-levels of interactivity without having to build a standalone SPA.

HTMX is a polar opposite to Angular in terms of complexity, for one.

How did you understand Angular to be similar to htmx? They are nearly polar opposites. Can achieve the same though.

Where are you getting those numbers from? The minified code is about 40kB before compression and about 13kB with gzip.

https://bundlephobia.com/package/htmx.org@4.0.0

you can check out fixi if you want to see a minimalist take on it:

https://github.com/bigskysoftware/fixi/blob/master/fixi.js

When sending json data, the browser has to run javascript to parse incoming data, keep track of it, and assemble the UI based on that data. One of the hardest parts of webdev is to synchronize server and frontend state, so there is a lot of things that can go wrong here, you are essentially maintaining the same state in two locations.

With htmx, there is no frontend state. The html always just reflects the state of the server passively, meaning it cannot go out of sync. When you do something on the frontend and submit some request, the server will update its state and replace the frontend html to reflect that exactly.

Here is an example. Traditional react app: Submit new todo item, append to some reactive js list, update frontend list, send new item to server. Here, you have to ensure that both sides did exactly the same thing, and if either side errors, you have to backtrack. Htmx app: Submit new todo item, send request to server, server stores it into its database, renders new list based on new database state, client replaces the list. Here, the server has the complete authority, and the frontend merely reflects that. If something fails, the server returns the old list plus an error.

This is a tradeoff in efficiency, but the hope is that eliminating frontend state management is worth it.

As a joke. Back when 2 came out, they promised there would never be a version 3. I.e., no breaking changes. Then they realized they did need to make a breaking change, so the only way to be true to their promise was to skip version 3.

Carson promised they'd never do a version 3...but he never said they couldn't do a version 4.

Exponential versioning. Next major would be 8.

By default LLMs will start creating a tangled hard to test mess of javascript. But if you ask them to do TDD they will, and if you give them access to Playwright and have them write playwright tests this can all work.

The advantage for the LLM is the same for humans. With the right abstractions, code can be written quicker and more robustly.

To get more hands off with LLMS you really want to have a lot of engineering rigor. A big part of that is a focus on tests. If your abstractions make testing easier, your results will be a lot better. For Javascript the more you can test logic without DOM manipulation and without playwright tests, the better.

I found LLMs to be default to and be pretty good at working with HTMX, but not great (mostly lots of state synchronization issues). The focus on DOM markup of HTMX does not lend itself well to simplifying testing. I don't claim to be an expert at HTMX, but I don't see a separate section on testing in their documentation.

I am trying out the foldkit framework because it makes a lot more testable outside the DOM. Its probably too heavy weight for most humans (and for simple apps- it only seems appropriate for client-side apps), but I will see how well LLMs can work with it.

There's definitely something to this: I expect LLMs to hurt the adoption of htmx and most smaller web libraries. That's fine: it's always been a labor of love and is BSD 0, so I hope the ideas are interesting and that the people who decide to use it enjoy it.

The main issue HTMX address is reducing complexity and LLMs doesn't solve it.

I'd expect it to be the other way around: LLMs will increase HTMX(and similar solutions) adoption because alongside of being excellent at writing HTMX there are also excellent writing web components.

React, vue and similar still have their use case, but htmx + web components can drive you really far.

> now that LLMs can generate JavaScript for us.

You mean generate unmaintainable JavaScript for us.

It's hard to answer because I don't personally use HTMX as a way to avoid Javascript. HTMX is a Javascript library. And I don't know if I even find using HTMX easier/harder than writing JS, because they are fundamentally different approaches to building apps. It really just depends on what I'm trying to do.

One is a programming language used for writing client side code, and the other is a minimal library that makes server sent documents more ergonomic. Yes, it's a JS library with a few nice conveniences, but the main draw of HTMX encourages a completely different app architecture than what the average dev would arrive at with plain JS.

They're just two different things to me, and so it seems irrelevant if LLMs can help you write one faster. If you're only using HTMX to avoid JS, I don't see how LLMs discourage you from doing that. Wouldn't it be better to vibecode something you have an easier time reading than vibecode a language you don't even understand enough to use? What are you going to do if it blows up?

The last time I made a website about a year ago, Gemini used HTMX. It was actually my first experience with HTMX, so in a way, LLMs led to me adopting it. :D

Out of curiosity, are you defaulting to vanilla js in your agentic dev stack? Or do you have the llm use a framework like react?

Does HTMX not have some performance gain over JS frameworks? (Never used it before)

I mean, htmx and JS glue logic is truly the differentiator now because LLM's do it so well. It's absolutely the way to go.

the browser is and always will be built for dealing with SSR HTML

That's super simple, it's your favourite backend web framework. Rails, Spring Boot, Laravel, Django, Flask, FastAPI...really whatever you like.

https://x.com/htmx_org/status/2093371471817244711

Yes, I can confirm. The main advantage is that you can build a site that feels like a React site, but with 100x less code, and no frontend to maintain.

It's a Javascript library with several custom DSLs.

So yes, it's using Javascript even if you don't do it directly.

Where does it say that exactly?

Because serialisation and deserialisation have a price and you almost never need what you describe

I would classify HTMX as a different style of "SSR with tiny bits of JS on top." In fact, I would argue it is a more "pure" form of SSR-based interactive web development than an Alpine.js-style approach (I am not making any value judgment here).

You can use ReScript with Htmx (or anything else) and get no runtime errors. It has a sound type system, great language.

Nope, this kind of app will hold a ton of business logic in the JS side, so HTMX is irrelevant in this context.

The explanation is a single, obvious click away.

Yep, fixed

What part of the Fixi project is building something like React?

40 series landcruiser

Image seems to be in the same style as the recent Omarchy Quattro header image. Is this a meme?