I really like htmx, and intercooler.js before it. It's been a while since I tried to convince a co-worker to use it, it might be time to try again. Either way I can't wait to try out the new version.

Full Disclosure, I am CEO of HTMX

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

There is something here, but I am not sure if it's the whole story: https://htmx.org/essays/lore/

yeah, basically recursivedoubts is pretty funny.

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

One of the things that is great about htmx (besides being the best library) is the lack of modern silicon valley corpo communication. It has the slightly unhinged feel of a nerd that spent too much time on Newgrounds or 4chan or something awful. Which is how the internet aught to be.

> unhinged

Please take a look at the official documentation for htmx, which specifically clarifies that the author owns many hinges.

I can’t believe he turned that offer from Microsoft down.

Absolute madman.

This is a social media presence worth striving for.

> You can put it on your LinkedIn, because it’s true.

I only take LinkedIn seriously under extreme protest, so this is extremely tempting.

Thanks for sharing that.

It's just about all Twitter links, where's XCancel/Nitter when you need 'em :(

Try https://www.sotwe.com/

Now Cloudflare won't let me see the thing that might let me see Twitter.

Awesome. Thank you!

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

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/

> I really like htmx

> Full Disclosure, I am CEO of HTMX

i think you've found a good job!

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.

Congrats and thanks! htmx brings me joy.

Pretty much every experiment I build now starts with Go, htmx, and SQLite to keep things simple and fast but still responsive.

I put a few more thoughts about this here:

https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...

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

Strongly disagree on Django, unless it is something you are already at a senior level at pre-AI. I've had the displeasure of cleaning up multiple Django backends lately, and the combination of standard fail-open, weak validation, mediocre ORM, and bad testing frameworks lead to issues I've simply not had when managing agents doing Go, Java or Rust.

Go probably wins as a matter of trade-offs for pure productivity (speed, reliability, ease of refactor), but Java Spring Boot works excellently if you're willing to take the plunge (pretty steep learning curve), and the ecosystem really lends itself to building more complex stuff that holds for a while.

Rust is fun because it is an amazing multi-faceted language where agents will constantly deliver you working yet surprising implementations you'll have to quintuple check, and sometimes spend and afternoon trying to grok. The outcome is also perfectly usable, fast, and reliable, but developer velocity is lower.

Feeling this pain with Django right now. I don't even have to deal with a database in this app (it's just a BFF) and it's unnecessarily complex. Right now I'm ripping out the React frontend and replacing it with htmx. Using Pydantic for form validation (will write a custom validator if I ever need multiple values from form fields). And using htpy instead of a templating engine. So far so good. Let's see how it goes.

Yes, it assumes senior level at pre AI, but this will apply to pretty much anything. Java in particular.

Keep in mind of course that a lot of so called seniors were also producing mediocre code <insert framework or language here>. It doesn't change the point though.

I had a great role for just over a year building with django/postgres/htmx! i ended up using lightweight web components for my js glue code (as well as shoelace, now web awesome, components). once a few patterns were established, claude code was extremely proficient. now getting back into frontend framework world i'm realizing what a lightweight, enjoyable experience that was...

Django + Postgres on the backend plus a frontend of HTMX + alpine.js for a light touch of interactivity where needed is a killer combination. Claude is very good at it, and with the right instructions actually keeps things concise and modular without spilling into spaghettification. I would recommend this as a first option to anyone looking to spin up a new web stack if you’re not absolutely sure you need the heavyweight of React.

I use the same stack. Single codebase, no build step. It’s so refreshing.

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.

Same here team rust/datastar though I still can't decide between minijinja and maud for templating.

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

Or RASX (Rust Axum Sqlite Htmx)

Skill.md here: https://github.com/dunctk/rasx-app-framework

DASH.

DynamoDB, API Gateway, Step Functions and HTMX.

Or HAGS (HTMX, AlpineJS, Go, SQLite).

Someone asked about using htmx with php on reddit, and was recommended a HAYW (Hypermedia on Anything You Want) stack.

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

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.

Go backend with Starlark for dynamic behavior is a great combination. I have been building https://github.com/openrundev/openrun with that approach, mainly for teams to deploy internal tools. It can be used to deploy any containerized application. The management UI for OpenRun is built with the Hypermedia approach https://utils.demo.clace.io/console/

I was unfamiliar with this stack and had an AI conversation about it to figure out what it meant, if I'm correct (not likely), this openrun+Go stack has a PHP FastCGI analogy:

Your web app can be HTML templated pages, with HTMX client interactivity and server interactivity provided by ~~PHP~~ Starlark, which does not have full OS access, but only what ~~CGI~~ OpenRun exposes as possible functionality, all of which happens in-process and per web route.

That's a fascinating new combination!

Yes, OpenRun can deploy any containerized application and act like a proxy for the upstream application, no Starlark or any transformation in OpenRun. If the upstream container is serving JSON APIs, OpenRun can also be used to implement a Hypermedia based web app on top, using Go HTML templates and Starlark as the glue code.

The advantage is that you get the performance of Go while being able to hot reload applications and install new application dynamically without a process restart. I think of it as an application server for containerized applications.

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?

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

Maybe a contrarian view, but as someone very knowledgeable about .NET API backends + angular on the frontend, I've found that HTMX made things more difficult as it required me to move back to mixing presentation concerns with business-logic and data concerns (basically have the backend produce the UI, which is whole point of HTMX).

This is not a criticism but I suspect that the people enjoying HTMX are either people preferring old-school server-side rendering or react users.

Just sharing my experience, because HTMX is the absolute darling of hacker news.

Since i mainly develop real SPA, i found that is more complex than just using typscrpit if you build something non-trivial as managing state on the server is not fun at all.

In my opinion if you are happy using angular, you'll find that HTMX is a step backward in terms for dev experience. Can't speak about react, but since it is not a battery included stack unlike Angular, i can understand why many people find they'd be better off moving things server-side instead of messing around with 15 third-party libraries. My 2 cents

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)

Yeah, typically I end up building websites (for myself and others) in basically three "lanes". Static HTML/CSS files, great for docs, presentations, reports and similar. Or, websites with some interactive/dynamic elements, HTMX is great for this. Or, fully fledged "client-side apps" where it's more of an application than website, then I go full out dynamic programming with ClojureScript and similar approaches.

I'm not sure why so many people seemingly fall into the trap of trying to find one tool and then use that absolutely everywhere. I mean, I'm familiar with it as in "it's fun" as I used Nix as a framework for a static website builder, but I keep seeing people making those sort of choices professionally too. Like when React first became popular, then suddenly people try to jam it into absolutely everything, until they slowly walk back and then after some years agree that maybe it's good for some things, not for everything and not as a default.

As someone who has conducted a ton of systems design interviews, the "I used these tools at my last job so I will use them for this completely different problem" is bamboozling.

OTOH, there are advantages to comfort picks. You know the APIs, you know the common libraries in the ecosystem, you know the quirks and pitfalls. It might not be optimal—and in production it compounds—but for dinky personal projects or finite-scoped professional things, it's understandable.

Ha, that was me and Hugo, back in the day, for static sites.

And, yeah, HTMX is truly great for sites with limited interactivity. You really, really do not want or need a full React Leaning Tower of Pisa stack for a simple presentational website.

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

My concern with is that i build line of business applications for a living, and literally, every project i work on ends up growing in scope such that even the simplest ones, reach a point where the customer asks for items that are just much simpler to do with a front-end framework. And these are often cross cutting concerns, such that it is not as easy as simply adding some js to one page.

Example: "i want to be able to reorder all the columns of all the tables of the website, and hide some columns, with my preferences remembered for each table". Customers pull that kind of thing off their hat every time, such that even "basic websites" can move out of the trivial territory any time. And this is just the most trivial example i can think of.

I want the tech stacks i use to be future proof, as in not having to rewrite everything when requirements become more complex (as it is also typically a time where we aren't given much time budget, as they need it for yesterday).

For something for which i fully control the roadmap, i may consider htmx (but even then, even my own products grow in ambition rapidly) however for customer projects i find this choice way too risky.

I need to be able to capitalize on the tech infrastructure i've built as requirements get complex, both due to customer time constraints and because this is where we get some of the highest profit margin from our work. Having to rework most of what i've done every time a complex requirement comes up, would be inefficient with this regard.

To me it's a case of knowing your tools in depth, to make meet most requirements (including from a performance perspective). Maybe erlang or go would have been more suited for a project from a philosophical perspective but since i specialize in .NET + angular, unless there is hard blocker, i'll use this tech stack, and everything is fine from the perspective of the customer. But i gain that the project is future proof and i won't need to reengineer it when it moves of its initial sweetpot.

From the same author: https://grugbrain.dev/#grug-on-saying-no

Thanks for sharing, I agree with what he says.

I've reached a point in my career where i can essentially call the shots as far as engineering and even product direction is concerned.

But recently had to do some consulting as an IC due to circumstances (worst case scenario deal closing delay), and i can tell you that there are places where non-technical people make tech decisions without consulting anyone. Also in my already quite distant qconsultant past (wow, time flies) while it has always been common for me to sort out requirements, and help with business analysis to align them with engineering, even when you dismiss flying unicorns, the class of core requirement evolutions that can make you regret choosing a tech stack is still very large. I've seen a couple of folks fired literally due to this.

Even now that i call the shots and sell products rather than time, the roadmap uncertainty is still high (largely driven by the need to make products user-friendly enough based on feedback), so i default to .NET + angular as it keeps my game open.

B2B2C at the cross-roads of ecommerce, fintech, blockchains. So you need to deal with vendor integration requirements while making the integration user-friendly from a UX perspective + and keeping your own core UX premium, especially for the B2C segment, and being competitive. Requirements change fast, especially at the beginning, so you don't want your engineering to constrain you or make things more difficult than necessary.

Nice. Curious about your views on SolidJS?

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.

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

Are you not familiar with building web apps?

So, when building for the web you'll essentially have 2 different categories of state: server and client.

Server state is obviously what's pulled fromt the db, but that's 100% not where something like form state should be stored. Or button toggle state. Or whether a modal is open, etc.

I have written web apps and about 80% of the sorts of things you are talking about can be handled with just html/css and I just use javascript for the other 20%. It's not like when you use htmx it disables all other javascript APIs.

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

It was so bizarre seeing people go from pure SPAs, to the concept of "hydrating" a website (ok still makes sense to a point), to coming up with server-side rendering like it's novel.

I mean sure, things like Next, Gatsby, etc can theoretically create the best of both worlds - static site for search engines and no-js users, content first, and very fast client-side rendered content afterwards. But that's a lot of extra engineering, considering a good server-side rendered website is also fetched and rendered within milliseconds.

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.

> 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 haven't used sessions in over a decade and haven't regretted that decision once. It opens up a whole new class of problems you don't have when using client-side frameworks.

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.

Datastar relies way to much on IDs everywhere that it's not ergonomic and turns into a chore. It's also a bit too complicated for its own good trying to solve everything.

As far as I understand D* only uses id (which is a pretty normal HTML attribute?) to key morphs in SSE. I only use one id for fat morphs on the body, and even if I needed more I'm not sure I'd find that any less ergonomic than other web standard attributes (class for example I have to use religiously in my day job with tailwind, etc).

Can you elaborate on the "too complicated" part? It seems a lot simpler to me given the slim surface area of the APIs?

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?

HTMX requires you to return HTML chunks (and calls that hypermedia) that get dumped directly into the client-side HTML.

So instead if returning data (JSON, XML, whatever), every part of your API now needs to return parts of client-side UI, and be aware of changes in it.

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.

Somewhat of an aside: it's ironic the that some of the clearest, most concise technical documentation I now find on the Internet has come out that way because it was written for a machine: https://raw.githubusercontent.com/bigskysoftware/htmx/v4.0.0...

Human readers don't receive this level of care or attention.

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.

Most sites/apps I work on are progressively enhanced (https://www.gov.uk/service-manual/technology/using-progressi...)

So far I've used a little bit of htmx (2) for one of them, and I really love it. Just a few attributes and we get some very reasonable progressively enhanced client/server interactive elements without full page loads.

Not sure I would choose if I had to make a SPA - it's partially from ignorance, but right not not sure how to avoid spaghetti. But I think it makes me even more strongly consider _not_ making a SPA

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?

Htmx 4.0 is over 100kb / 2,000 lines of code. Isn't there a way to slim this down some? I mean, isn't the basic idea just a couple lines of code? I remember AJAX 2.0 or whatever loaders that were only 1-5kb wrappers around XHR back in the day. Now we have fetch() which is even more basic:

    fetch('/my/api/content.html')
      .then(response => response.text())
      .then(html => {
        document.getElementById('content').innerHTML = html;
      });

I don't mean to imply this is close to total number of Htmx features, but fetching islands of content is the core idea and I feel like we're way past feature bloat at this point for something that is supposed to be simpler than React (Preact is only 10kB)

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

https://bundlephobia.com/package/[email protected]

103KB is the actual source code. You should not be reading or debugging the minimized or gzip/transport bytes.

> `hx-alpine-compat` - smooths over compatibility issues between htmx and Alpine.js

I looked into this when I tried HTMX 4 on a project earlier this year. I actually found that https://alpine-ajax.js.org/ was smaller than HTMX while providing all the features I needed. It is one of the sanctioned projects they link to so I felt good using it

great library, we link to it on our alternatives page

Carson! FYI:

"let us rething how extensions can and should work,"

I think you meant rethink here.

Proof it wasn't AI generated! Thank you!

A thoughtful, clean, and useful library that wasn't built to climb the corporate ladder. It grew organically. I think it became a cry of relief for those annoyed by unnecessary complexity, which also boosted its recognition. It served as a starting point for things like Datastar, too. I believe it brought a refreshing breath of air to the frontend landscape.

As the CEO of HTMX, I've never used HTMX but I've been keeping an eye on the releases, essays, and talks. Congratulations to the team.

As CEO of HTMX, I am very proud of the work achieved by the team.

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!

lol sorry about that, had a fix sitting in four-dev, merged to four and pushed, should be updated

I found Htmx to be a great combo with agent driven development. It lets you end-to-end test the UI without a full headless browser by just examing the HTML, which means UI tests are cheap and fast, which means you can have tons of them. And coding agents are exactly as good as your test coverage. So with Htmx they're great.

You found HTMX?

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

Before vibe coding was a thing, HTMX made it super easy for me to implement Ajax like features. It was the most approachable library I've ever seen, and I'll always be grateful for it.

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

For me, I know backend development really well, and HTML/CSS passably. HTMX has been much lower friction for me than learning JS frameworks, which tbh I didn't really enjoy, and they were constantly changing. But now, I had mostly leave the JS to Claude, and the HTMX draw has diminished a bit.

It's day job tasks/database CRUD, so I tell the LLM what I need. I used to write all my work apps in plain jane PHP/MySQL and I use that as a guide for the LLM, as in use this app as a guide on how I want things. The bonus of using plain PHP/MySQL/PDO is that the apps are small, so no issues with context windows or using complex frameworks.

For those wondering, here's how you can join me, the CEO of HTMX, as CEO of HTMX: https://htmx.ceo/

Is it just a coincidence that the image for this release is the same as for Omarchy Quattro? https://youtu.be/F7fe9pa8OeE

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

As the CEO of HTMX I find it disturbing that we have more CEO’s than users.

Congrats on the release. The next stage is probably some real world comparison between DataStar and HTMX 4.0. Or against Hotwire / Turbo.

And perhaps the long term goal is if half if not most of HTMX 4.0 could be inside HTML 5 spec.

The site is very broken on my iPhone safari. If I click an an anchor reference at the very top (“LLM” let’s say) and try to scroll down because it doesnt link me to the content, it keeps snapping me back to the top after a second.

Cheers! We've been running the various betas in production for a couple of months now. For our Rails app we replaced most of our Hotwired/Turbo with HTMX. For me at least, HTMX just makes more sense: you control the flow of content from the client, not from the server as you do with Turbo.

For pushing updates, we use ActionCable, but we do it in a different way from what we used to do with Turbo Streams: when a record is updated, instead of sending HTML from the server to the client with instructions on what to replace, we only send a small JSON payload with the ID of the element that was updated. On the client side, an event is dispatched that any DOM element with <hx-trigger="<resource-id>:updated from:body"> will trigger on. For the rest it's just basic HTMX, only the trigger is "custom".

I have been reading:

https://www.goodreads.com/book/show/192405005-hypermedia-sys...

and still having a hard time wrapping my mind around all of this.

The thing which I would really like to see is a stand-alone IDE with a straight-forward "Hello World" as an on-ramp.

Shame the page does not tell you what HTMX is, even in one sentence.

Congratulations on the release!

I have enjoyed working with htmx very much.

I'm still skeptical of htmx being the foundation for a 100-year web service, but I think this is a really worthwhile goal. I'll add that aside from static HTML, I don't have a better option.

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.

> RoR and so poorly planned that it’s still biting Microsoft on a regular basis.

Disagree. The RoR front end was way more stable and usable than the mess they have made now.

> RoR was so brittle and slow that they couldn’t hire enough to keep it going.

This is such a "poor carpenter blaming his tools" take.

RoR isn't holding you back from writing performant, high-quality code. However, letting inexperienced developers run wild without supervision does end up with a codebase committing most of the deadly sins of software: (1) proliferation of competing patterns (2) proliferation of competing third-party libraries, leading to more #1, (3) inadequate test suite, and (4) an app that serves up so many 500 errors that you can't tell which are new and/or which indicate a problem. #4 is definitely more common in untyped languages, since that whole class of bugs can't be caught at compile time.

By the time a lot of these "startups" get to the mature state they have like a 7-year-old codebase that is beyond help. But you can use Ruby and Rails responsibly. I've seen it done. Usually all that's needed is to apply yourself to understanding how to cache, and then, identifying the key expensive high-traffic endpoints and converting them from ActiveRecord N+1 messes into single-query eager-loaded beasts, sometimes skipping ActiveRecord's object instantiation. Sounds scary, but it's inevitable for a popular application on any language/framework that you'll need to go beyond the tutorial-grade code for key transactions. This kind of thing is what Staff Engineers are for.

Is it though? It doesn't need to be perfect to last. Good engineering practices certainly embrace timeless concepts. I understand if you are working in a feature-factory, but creating inheritable code should be given more consideration however much programmers dislike thinking about things like ROI.

Thinking about whether a web architecture will hold up for 100 years is bikeshedding, is bikeshedding as well

calling thinking about bikeshedding, bikeshedding, is peak bikeshedding.

bikeshed

pronounced "by-kesht"

Sir, this is a Wendy's

100 years, sure, but 10 years? Definitely not bike shedding, I'd hope your website can stay up for 10 years at least.

You don’t need to agonize over a library choice to know that your site will be up for 10 years. If it outputs web standards, the browser engines will make sure it is.

Yes, unless you choose wrong, which is what we're talking about, as sometimes choosing right is worth the bike shedding.

Sure but it's a spectrum. Surely some choices will age much more poorly than others.

I'm not very familiar with htmx but at first glance it seems similar to Angular. I thought Angular lost favor because of all the extra attributes and boilerplate. What makes htmx different?

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.

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

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

I just discovered this and it’s exactly what I’ve been hoping for since 2016. I’m just sorry I’m JUST finding out about it.

According to their docs "htmx is a library that allows you to access modern browser features directly from HTML, rather than using javascript"

Can anyone confirm this claim? How good is this? Doing everything in HTML/CSS might have some advantages. Is it quick and compatible enough?

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.

Can anyone convince me why I should choose HTMX rather than vanilla JS for "sites with limited interactivity"?

Why did they skip version 3?

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.

This can be a good summary of htmx overall; a confident solution based on half understanding of the problem domain.

Exponential versioning. Next major would be 8.

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

I'm so pumped for v8!

this guy gets it

Hopefully Vercel acquires them and puts the final nail in the coffin of that piece of shit PaaS and the SSR concept in general for client-side applications.

I've always been a fan and supporter of HTMX, but lately I've wondered how beneficial it is now that LLMs can generate JavaScript for us. HTMX was especially useful when I wrote JavaScript by hand because I appreciated its higher level of abstraction and simplicity. I also struggled to make it work with AlpineJS and eventually had to resort to plain JavaScript, which gave me finer control. Normally, switching to JavaScript would have been a hassle but since an LLM can produce it as easily as any other text, I’m less clear on HTMX’s advantage. I’ve been getting along fine without it. If computers didn’t write code for us, I would still choose HTMX, but now I find it hard to justify the trade‑off.

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.

It may do the opposite! My sense of LLMs is that simplicity beats training.

If you have 1/5th the context to consume, that's going to generate better code than the comparable typescript, even if the language is an esoteric one.

I think, at least for the next few years, certain preferences and consensuses were accidentally embedded in the models to your benefit.

They love htmx! Claude will independently suggest using it instead of more general js frameworks for smaller projects. A gpt model told me, and I wrote this down because it was striking, "htmx won the argument it was making."

It's the same thing with rust. I'm an ocaml expert and ocaml genuinely fits a lot of the problems I work with better regardless of that. But because of when the models were trained and what they were trained on, a certain sort of alt-consensus opinion is frozen into them, and it believes rust is a better choice for nearly everything!

I think you're good for the next few years at least. It's an open question what happens after that dead internet theory recursive loop of llms trained on llm output etc so who knows you might be good forever.

I agree with this and I'd also say - I've been vibe coding in OCaml since before the training data was good.

All the stuff I lost in training data I gained back in having great compiler feedback.

I don't think agents are nearly as restricted by language or training data as we think.

We will see. Changing things around a bit (especially flipping attribute inheritance to explicit by default) may confuse a lot of models. Oh well, it's the right thing ¯\_(ツ)_/¯

Thank you for your kind words!

Please don’t misunderstand my comment, I wasn't trying to diminish the brilliant work you’ve done on HTMX, which I’ve personally benefited from. I could have probably worded it better than I did. I'm also not saying you _did_ misunderstand it, only asking that you please don't. I was just sharing an observation that I realize is not everyone’s experience. I’m still a fan + supporter, even though I now reach for JS more often because the pain of writing it has largely disappeared. I’m still not a fan of it by any means, but LLMs have been a major mitigator. I'm always happy to see the HTMX updates when they come out.

I've yet to see anyone try to finetune one of these qwen models on a specific framework, but if you guys care, qwen3.5-35B-A3B is rather fast and reliable for a lot of what I'd call "copy/paste" task and might be worth while to see if a fine tune could excel at HTMX universe tasks.

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.

I recently used Alpine.js (client-side, I know), and, as a person that does backend most of the time and is not super knowledgeable in frontend, I was amazed.

I think that, combined with Htmx it can be a really powerful thing for lots of deployments (basically most things that do not need API/Json talking).

> now that LLMs can generate JavaScript for us.

You mean generate unmaintainable JavaScript for us.

Depends how you set it up. Like any other project I guess. Funny enough, if you are able to produce maintainable code with an llm you could aswell lead a team of humans. LLMs shift your focus on project management and architectural choices.

I let the llm write components which are independent to each other. This works great and keeps everything clean. The times that llm would only generate unmaintainable code are long gone with OPUS, Fable and sol 5.6

> LLMs shift your focus on project management and architectural choices.

And a comfortable sense of short term productivity that make you tend to ignore the middle and long-term trade-offs.

It is unmaintainable unless you create a very modular architecture (read here: modules written by LLMs that will not get in the middle of others bc of their extra fat).

And even with a modular architecture, I am not convinced.

However I had a couple of success stories in the generative area, maybe bc I am so stupid that I do not detect the problems: SQL query/code generation and frontend Alpine.js-based for a small website.

Also good for one-off scripts.

But when it is about a project where you iterate for weeks, things get out of hand.

As a powerful search engine, exploring alternative solutions or doing code review, great. But the reason is not that it is extremely good at it. It is bc it is extremely fast at it and it is easy to recognize bogus stuff if you have been doing this for many years, so it saves you time. But still gives you inaccurate stuff.

Not my experience. I have large production apps that I'm able to maintain just fine with thousands of lines of JS.

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?

I've only tried vanilla JS so far

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

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

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?

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.

All apps I build are server-side rendered. I'm not sure how your comment changes the the question I'm asking.

apologies, i thought you were saying you were switching to SPAs because LLMs understand it better. I see some version of that comment nearly daily now. Carry on!

Ah no worries. No SPAs for me, SSR all day.

IMO current browsers are more like an operating system designed for progressive loading of apps.

That doesn't mean do dumb / complicated / bloated stuff for no reason. If the best thing for your users is static html, use that.

That's like rejecting video games because the CRT was built for displaying live TV streams sent over the public airwaves.

Oof bold claim

how so? that's what they do - incomparably faster than dealing with JS

Strange. The picture of the jeep looks similar to the Omarchy Quatro Desktop wallpaper. Is there a connection? How come both look so similar?

Great library. Really enjoy using it. Agents work really well with the kind of site you build with it and it’s very easy to build. Thanks for the upgrade skills.

It seems this version is also adding hx-live. Anyone used it before? How does it compare against Alpine.js?

I'm glad I'm not using this. It's the opposite of how I like to build web apps (which is either SSR with tiny bits of JS on top that I like to use Alpine.js for; or a JS-app that I like to use Elm for as life is too short runtime errors).

Nonetheless I hope all who do use Htmx, enjoy using it.

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.

"On this page" anchor navigation doesn't work for me :( Mobile Safari

Is it a good idea to code an app with infinite canvas (like Excalidraw) in Htmx?

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

Cool to see htmx alive and evolving. This update was long overdue. The change to attribute inheritance seems a bit debatable to me but maybe it'll actually make the code easier to understand

disappointing: not a mention to "fixi" in any comment. Fixi is the reason htmx 4.0 has come. Fixi is extremately simple but extremately powerful at a time. http://fixiproject.org/

Better than htmx IMO.. Same author.

And by the looks of it, the Author is starting to understand the reason React and the likes exists and has start to build them over again: https://fixiproject.org/

LOL. Frontend dev never changes.

Maybe I’m missing something, but why would you want HTMX server side rendering, rather than a restful API that can return platform-agnostic data structures that you could render in various contexts, like a SPA, or a mobile app, or a terminal app, etc?

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

HTMX Rocks!

Congrats. Relatedly, see also https://data-star.dev/

The simplicity is the point

Great to see progress continues and the CEOs continue to grow.

As CEO of HTMX I am proud of what we have achieved.

That's a great-looking Toyota. What model is it?

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

40 series landcruiser

> Note that attributes like hx-disinherit

Looks like some copy is missing here

Yep, fixed

> (plus at game)

Typo of "a"?

with enough eyes all typos are shallow (it was a long night)

Its ok now you may rest <3

(Congrats on the release)

why would i use htmx? whats the user case

i'd avoid imo, i'm an intern that got fired from htmx and the ceo was a jerk

The game page is pretty broken...

The anchor links in the "on this page section" don't work for me (Android Firefox/Chrome).

Can we get a Mitsubishi Delica for the next announcement? Thanks.