Local First Htmx
20 comments
·November 8, 2025oldestofsports
HTMX is neither a meme nor is it anti-javascript, it is literally written in js.
It does not aim to remove js from your code, it simply adds more features to HTML by default, like making any element able to trigger an web request.
When you write a real world app with HTMX, you inevitably end up writing some js, which is totally fine.
Animats
Nor is it "local first". It works by remotely pushing HTML into the DOM. It's really a form of push technology.
kryptn
htmx isn't local first. this blog post is about trying to make it 'local first' by introducing a service worker.
kryptn
i decided to use htmx for a frontend for myself and it was a pretty fun experience. even got tailwind involved pretty easily with my rust+maud backend.
xg15
It is definitely "anti-javascript" or more precisely "anti-SPA". I've read the blog posts.
zelphirkalt
JS != SPA though, no matter how many frontendies want to believe it is equivalent.
brabel
It’s funny to equate JS with SPA. We’ve had JS on the web since day 1 to add interactivity to otherwise static pages. SPA only became a thing decades later.
sublinear
Why not just write the js yourself? It's really not that complicated. The people who keep pushing for htmx are weird.
Swizec
> Why not just write the js yourself? It's really not that complicated. The people who keep pushing for htmx are weird.
HTMX is great. We use it as a middle ground for mildly interactive parts of the app. Places where jquery/vanilla would get annoying but going full React isn’t worth it. Admin interfaces in particular are a great fit – lots of CRUD, mildly interactive, very repetitive.
Adding `hx-get` to a button or div is way way quicker than writing all that boilerplate javascript yet again for the hundredth time.
Extra bonus: it encourages you to write small self-contained composable endpoints instead of massive kitchen-sink pages.
Culonavirus
> Admin interfaces in particular are a great fit – lots of CRUD, mildly interactive, very repetitive. Adding `hx-get` to a button or div is way way quicker than writing all that boilerplate javascript yet again for the hundredth time.
Yes. Then imagine you have a massive legacy codebase and a control panel of something has a ton of data and buttons and inputs and all kinds of nonsense. Say you have a weight and dimensions of a package of a product... you'd like to make it so you can edit these in-place and when you do, a package volume (and/or volume sum of all packages) gets updated somewhere else on the page (along with some other info... I don't know, an estimate of product delivery cost based on volume, which delivery methods are now un/available etc.)
Like... you already have ways to calculate and show these in your server side logic. With HTMX you reuse these, add a sprinkle of hx-get and add some OOB updates and you're done. You can do the same with ajax, but not nearly as fast as with HTMX and much more annoyingly...
HiPhish
Why should I write it myself? Sure, I could do that, but then every time I want to have that sort of functionality on multiple pages I would have to write the JavaScript code multiple times. I could then roll it into a library. Maybe make the library work with custom HTML attributes. And now I've just reinvented HTMX. So I might as well use HTMX instead of reinventing it.
Such a weird question. You could ask that about any library ever.
righthand
Because with HTML you get static, non-flashing, intstantly rendered without load times. So smart developers actually want less Javascript, because the browser already implements most of what Javascript does, why reinvent the wheel?
Why would I write React components myself when I the Javascript isn't really that complicated?
It is bizarre that ONLY HTMX gets these weird "DONT USE THAT ITS NOT POPULAR ENOUGH" criticisms.
XML, XLST get these criticisms except for the XQuery and XPath components because HTML fanatics need that to make their hybrid HTML/JS garbage apps work.
But really the ultimate goal for any good website engineer should be to offload as much logic and processing to the browser, not rewrite everything in JS just because you can.
orhmeh09
> But really the ultimate goal for any good website engineer should be to offload as much logic and processing to the browser, not rewrite everything in JS just because you can
Why? This makes for a horrible user experience. Things like TicketMaster, and in recent years GitHub, slow my machine to a crawl sometimes. I much prefer mostly static content. This is a well-made website: https://www.compuserve.com/
on_the_train
Because I don't know js and don't want to touch it
librasteve
Really enjoyed this article … thanks for opening my mind wider.
In case anyone thinks this idea is serious, my strong like of vanilla HTMX came from the realizations that (i) state management can revert to the ur-web model and avoid all the complexity of browser / server state synch and (ii) I can use anything I damn well like on the server (I wrote https://harcstack.org to optimize for expediency).
aidenn0
So far, all of the comments are taking this far too seriously. It's literally just: "htmx is supposed to be great" and "Local first is supposed to be great" so lets combine them in the dumbest way possible.
righthand
The WASM component just seems like a way to avoid writing models? Or is it demonstrating that you can run your server in the browser? Why is WASM needed then if it's just handling simple internal requests. WASM adds a layer of Golang which would be nice if the server needed to be portable from the local, but then why run the server locally at all if you need it in remote contexts? If you're trying to build a simple local JS app, why not just write it all in JS?
indatawetrust
[dead]
Big fan of htmx here, so thanks for opening my eyes to a new way of using it with service workers.
But man, 10MB Go WASM download? That's a no go. It's not only about downloading it but executing on a clients machine over and over again. But I guess you can handle those requests perfectly fine just in service worker using pure JavaScript.