Rendered at 20:10:32 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dec0dedab0de 4 days ago [-]
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
jdlshore 4 days ago [-]
Given the number of people claiming to be CEO of HTMX, I have to ask: what’s the joke I’m missing?
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.
testdelacc1 4 days ago [-]
> unhinged
Please take a look at the official documentation for htmx, which specifically clarifies that the author owns many hinges.
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).
Analemma_ 4 days ago [-]
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.
WD-42 4 days ago [-]
I use the same stack. Single codebase, no build step. It’s so refreshing.
farmeroy 4 days ago [-]
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...
arw0n 3 days ago [-]
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.
yawaramin 3 days ago [-]
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.
sgt 3 days ago [-]
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.
michaelchisari 4 days ago [-]
I call it the GOSH stack (Go Sqlite Htmx) but HUGS is good too.
Someone asked about using htmx with php on reddit, and was recommended a HAYW (Hypermedia on Anything You Want) stack.
antihero 3 days ago [-]
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.
aquariusDue 3 days ago [-]
Same here team rust/datastar though I still can't decide between minijinja and maud for templating.
trueno 4 days ago [-]
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.
ajayvk 4 days ago [-]
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/
Multicomp 3 days ago [-]
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!
ajayvk 3 days ago [-]
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.
kaycebasques 4 days ago [-]
Oh wow, interesting combo that I would never independently reach for, but thanks to your template I might have to give it a whirl!
bbkane 3 days ago [-]
How are you using dbos with SQLite? The docs say its a Postgres library
a_poliakov 2 days ago [-]
Hello, I'm from DBOS.
Our Golang and Python SDKs support SQLite as well as Postgres.
If you want a prototype fast, don't you use an LLM?
And if you do, why start with a simpler framework?
t098i3 3 days ago [-]
LLMs are fantastic at HTMX+Go
shimman 4 days ago [-]
I also like the same stack, as it plays very well with a terminal focus workflow.
rednb 4 days ago [-]
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
perardi 4 days ago [-]
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)
embedding-shape 4 days ago [-]
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.
tyre 3 days ago [-]
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.
perardi 4 days ago [-]
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.
rednb 4 days ago [-]
> 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.
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.
kvirani 4 days ago [-]
Nice. Curious about your views on SolidJS?
splawn 4 days ago [-]
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?
troupo 3 days ago [-]
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.
splawn 3 days ago [-]
I know. HATEOAS...
I understand the issue of mixing state models.. angular SPA style vs HATEOAS.
But that still doesn't answer what I was asking about mixing presentation concerns into business logic.
Returning HTML means the presentation layer has to know about HTML. Why would that require the business logic to know about it?
aidenn0 4 days ago [-]
> ... 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.
mexicocitinluez 3 days ago [-]
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.
aidenn0 3 days ago [-]
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.
mexicocitinluez 2 days ago [-]
We are talking about how state is stored, not about CSS.
And it makes me think you haven't had as much experience as you think.
How do you deal with form state using CSS? Where does it get stored? In the html as elements? So not on the server?
aidenn0 2 days ago [-]
> How do you deal with form state using CSS? Where does it get stored? In the html as elements? So not on the server?
For more complicated stuff, it is in the html as elements. With htmx you can often do this by making a request to the server to update a subtree; the server doesn't need to know the state that the user is seeing, just what is happening in the specific request.
Sometimes just updating html subtrees isn't quite enough, and then I use javascript. Transient state that is only concerned with what is presented to the user is probably not best done on the server.
tetha 3 days ago [-]
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.
3 days ago [-]
radicalbyte 4 days ago [-]
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).
Cthulhu_ 3 days ago [-]
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.
xp84 4 days ago [-]
> 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.
mexicocitinluez 3 days ago [-]
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.
yawaramin 3 days ago [-]
So what do you use instead?
mexicocitinluez 2 days ago [-]
It depends on the specific data. Do you have anything that you store in session in mind?
Having the client/server split has made this a lot easier to reason about. I store client state on the client and server state stays on the server.
yawaramin 2 days ago [-]
I’m talking about auth, like a session cookie. What do you use for auth?
mexicocitinluez 1 days ago [-]
I use Entra, so the session cookies are created through login.microsoft.com. Which means I'm not actually managing the session.
When I said I don't use sessions, I should have specified I don't use them for application state (or roles and stuff).
fatplexer 4 days ago [-]
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.
turtlebits 4 days ago [-]
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.
devalexwells 3 days ago [-]
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?
fatplexer 3 days ago [-]
[dead]
cbeach 3 days ago [-]
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.
mhitza 3 days ago [-]
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.
intrasight 4 days ago [-]
> mixing presentation concerns with business-logic
That's on you not on your platform
hliyan 4 days ago [-]
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.
Rendello 3 days ago [-]
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).
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?
DrBazza 3 days ago [-]
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.
james2doyle 4 days ago [-]
> `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
recursivedoubts 4 days ago [-]
great library, we link to it on our alternatives page
zanderwohl 4 days ago [-]
Carson! FYI:
"let us rething how extensions can and should work,"
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
duxuev 4 days ago [-]
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?
michalc 2 days ago [-]
I would say it's only really a burden if you fight it, or don't expect to have to do it and right at the end someone asks "er... does this work without JavaScript?". My attitude is that it's a combination of freeing and a challenge: "we can and should make it simple, even boring"
Automatic enforcement for all services is tricky, because you _can_ depend on JavaScript if the user needs justify it.
huflungdung 3 days ago [-]
[dead]
miguel-muniz 4 days ago [-]
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.
threesmegiste 4 days ago [-]
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.
havaloc 4 days ago [-]
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.
matthew-craig 4 days ago [-]
What about vibe coding makes HTMX something that you speak about in the past tense? Are you just generating frontends in vanilla JS now?
LVB 4 days ago [-]
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.
havaloc 4 days ago [-]
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.
Baguette5242 4 days ago [-]
As CEO of HTMX, I am very proud of the work achieved by the team.
all2 4 days ago [-]
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].
> 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!
recursivedoubts 4 days ago [-]
lol sorry about that, had a fix sitting in four-dev, merged to four and pushed, should be updated
bluesnowmonkey 4 days ago [-]
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.
thewhitetulip 4 days ago [-]
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
rwoerz 3 days ago [-]
You found HTMX?
hmokiguess 4 days ago [-]
For those wondering, here's how you can join me, the CEO of HTMX, as CEO of HTMX: https://htmx.ceo/
praseodym 4 days ago [-]
Is it just a coincidence that the image for this release is the same as for Omarchy Quattro? https://youtu.be/F7fe9pa8OeE
recursivedoubts 4 days ago [-]
oh man that's embarassing, someone made that on twitter I didn't realize it was from omarchy, I've removed it, my bad
chainwax 4 days ago [-]
I think that's the joke
alkonaut 4 days ago [-]
As the CEO of HTMX I find it disturbing that we have more CEO’s than users.
dajonker 4 days ago [-]
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".
ksec 3 days ago [-]
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.
fionic 4 days ago [-]
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.
ryanisnan 4 days ago [-]
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.
smt88 4 days ago [-]
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.
mostlysimilar 4 days ago [-]
> 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.
smt88 4 days ago [-]
The issues are with the Ruby backend.
RoR is the only framework I’ve ever heard of being so bad that it killed startups. I personally know of two that were doing well, but RoR was so brittle and slow that they couldn’t hire enough to keep it going. This is compounded by Ruby devs being pretty rare.
xp84 4 days ago [-]
> 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.
ashwinsundar 4 days ago [-]
Thinking about whether a web architecture will hold up for 100 years is bikeshedding, is bikeshedding as well
xp84 4 days ago [-]
calling thinking about bikeshedding, bikeshedding, is peak bikeshedding.
ashwinsundar 4 days ago [-]
bikeshed
euroderf 4 days ago [-]
pronounced "by-kesht"
smt88 4 days ago [-]
Only if you don’t know what bikeshedding is and want to broaden the definition so much that it’s meaningless.
This is Hacker News. This is exactly the place to tell people they’re overanalyzing and should just build something.
ashwinsundar 4 days ago [-]
Sir, this is a Wendy's
officialchicken 3 days ago [-]
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.
satvikpendem 4 days ago [-]
100 years, sure, but 10 years? Definitely not bike shedding, I'd hope your website can stay up for 10 years at least.
smt88 4 days ago [-]
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.
satvikpendem 4 days ago [-]
Yes, unless you choose wrong, which is what we're talking about, as sometimes choosing right is worth the bike shedding.
ryanisnan 4 days ago [-]
Sure but it's a spectrum. Surely some choices will age much more poorly than others.
kayson 4 days ago [-]
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?
recursivedoubts 4 days ago [-]
htmx is based on the ideas of hypermedia, you can read the first chapter in our book on the topic here:
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.
Capricorn2481 4 days ago [-]
HTMX is a polar opposite to Angular in terms of complexity, for one.
sgt 4 days ago [-]
How did you understand Angular to be similar to htmx? They are nearly polar opposites. Can achieve the same though.
jordiburgos 1 days ago [-]
I still do not get the point of Htmx of doing the templating in the server side. Maybe it is just me.
Can anybody explain it better why mixing templates in the backed and HTML in the frontend opposite to keep all the HTML + templates in the browser and only return JSON from the server.
mkrd 1 days ago [-]
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.
Xeoncross 3 days ago [-]
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:
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)
moebrowne 3 days ago [-]
Where are you getting those numbers from? The minified code is about 40kB before compression and about 13kB with gzip.
103KB is the actual source code. You should not be reading or debugging the minimized or gzip/transport bytes.
yawaramin 2 days ago [-]
Yeah but when you're reading the actual source code you're not thinking in terms of bytes, you're looking and files and line counts. Htmx is deliberately maintained as a single, no-dependency file of about 5000loc. The maintainers are of the opinion that it reduces complexity, and I tend to agree.
recursivedoubts 3 days ago [-]
you can check out fixi if you want to see a minimalist take on it:
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.
avarun 4 days ago [-]
Why did they skip version 3?
MichaelNolan 4 days ago [-]
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.
asdf88990 4 days ago [-]
This can be a good summary of htmx overall; a confident solution based on half understanding of the problem domain.
No, you misunderstand what is going on. htmx is an exercising in learning web development by someone who didn’t follow 2 decades of web development progress.
He is catching up though, now approaching the early 2010s jQuery (moxi) and backbonejs era with fixiproject.org
yawaramin 3 days ago [-]
Htmx is a direct descendant of Intercooler.js, which has been around since circa 2013, more than a decade. Intercooler still exists and is used in production, and you can clearly see that it works almost exactly the same way as htmx does today, it just bundles jQuery together.
The creator has been working on these ideas for a long time, but the core idea–swapping HTML from the server into the DOM–has been constant throughout.
It's exactly because he followed the past two decades of web dev that htmx avoids almost everything about it. Fixi and htmx extensions follow the 80/20 principle and can work by just being dropped in with a script tag. You don't need an elaborate npm setup, same as everything else in the htmx ecosystem.
asdf88990 2 days ago [-]
The creator is stuck in 2012 and so on as I said. If you look at project fixie, the reason htmx 4 exists, it shows how the 80/20 is an incomplete idea for something as general as a web framework. 80/20 might work for your specific use case, but as a general notion, it either gets built on reasonable constructs or grows into a Frankenstein. Htmx approach is a mirror of yaml in my ways. In denial of what it is trying to be and so turns into complete monster.
Correction: they didn’t ‘realize they needed to make a breaking change’, they got excited by the improvements they could unlock by using the Fetch API and wanted to make a breaking change.
The upgrade is completely voluntary: it won’t even be set as the default version in npm till next year, and there are no known security issues that would force anyone to upgrade. People happy with v2 can just stay on it for the foreseeable future.
_doctor_love 4 days ago [-]
Carson promised they'd never do a version 3...but he never said they couldn't do a version 4.
gwking 4 days ago [-]
I'm so pumped for v8!
recursivedoubts 4 days ago [-]
this guy gets it
SoKamil 4 days ago [-]
Exponential versioning. Next major would be 8.
replwoacause 4 days ago [-]
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.
gregwebs 4 days ago [-]
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.
4 days ago [-]
recursivedoubts 4 days ago [-]
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.
giraffe_lady 4 days ago [-]
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.
sroerick 4 days ago [-]
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.
recursivedoubts 4 days ago [-]
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!
replwoacause 4 days ago [-]
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.
sroerick 4 days ago [-]
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.
cyanydeez 4 days ago [-]
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.
vb-8448 4 days ago [-]
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.
germandiago 4 days ago [-]
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).
Fervicus 4 days ago [-]
> now that LLMs can generate JavaScript for us.
You mean generate unmaintainable JavaScript for us.
razemio 4 days ago [-]
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
germandiago 3 days ago [-]
> 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.
replwoacause 4 days ago [-]
Not my experience. I have large production apps that I'm able to maintain just fine with thousands of lines of JS.
Capricorn2481 4 days ago [-]
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?
KPGv2 4 days ago [-]
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
dgabriel 4 days ago [-]
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?
replwoacause 4 days ago [-]
I've only tried vanilla JS so far
mi_lk 4 days ago [-]
Does HTMX not have some performance gain over JS frameworks? (Never used it before)
sgt 4 days ago [-]
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.
nchmy 4 days ago [-]
the browser is and always will be built for dealing with SSR HTML
KPGv2 4 days ago [-]
That's like rejecting video games because the CRT was built for displaying live TV streams sent over the public airwaves.
replwoacause 4 days ago [-]
All apps I build are server-side rendered. I'm not sure how your comment changes the the question I'm asking.
nchmy 4 days ago [-]
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!
replwoacause 4 days ago [-]
Ah no worries. No SPAs for me, SSR all day.
osigurdson 4 days ago [-]
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.
7bit 4 days ago [-]
Oof bold claim
nchmy 4 days ago [-]
how so? that's what they do - incomparably faster than dealing with JS
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.
orsenthil 4 days ago [-]
Strange. The picture of the jeep looks similar to the Omarchy Quatro Desktop wallpaper. Is there a connection? How come both look so similar?
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?
moebrowne 3 days ago [-]
Because serialisation and deserialisation have a price and you almost never need what you describe
deadbabe 2 days ago [-]
Who pays it?
And I disagree, we definitely use the same API for other contexts.
yawaramin 2 days ago [-]
The client pays it.
- If the server is responding with JSON, the client has to parse, decode, and validate the JSON. Then it has to transform it into HTML DOM nodes. Finally, it can inject them into the DOM.
- If the server is responding with a bespoke non-JSON data structure, it's the same situation as above except even more work because a third-party, non-standard library has to decode this structure into something (most likely JSON) and then transform the JSON into HTML nodes, etc. etc.
- If the server is responding with straight-up HTML, the client uses the browser's HTML parser to directly transform it into HTML nodes and inject it into the page. And by the way, the browser engine is essentially a function that is highly optimized for exactly this use case–parsing bytes into DOM nodes.
'We' might use the same API but it's widely accepted that generally the same API doesn't work for all contexts. See https://samnewman.io/patterns/architectural/bff/#general which details the many well-known problems with having a single API for different contexts.
deadbabe 1 days ago [-]
Fortunately for the client, it costs them basically nothing to pay.
yawaramin 1 days ago [-]
Parsing and processing several megabytes of JS for each page you visit can get expensive quickly. https://tonsky.me/blog/js-bloat/
deadbabe 14 minutes ago [-]
Yes but isn’t this the beauty of decentralized protocols? The cost is spread amongst all, it doesn’t require one entity to shoulder the cost for everyone.
kensai 3 days ago [-]
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?
EmilStenstrom 3 days ago [-]
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.
troupo 3 days ago [-]
It's a Javascript library with several custom DSLs.
So yes, it's using Javascript even if you don't do it directly.
yawaramin 3 days ago [-]
Where does it say that exactly?
cui 4 days ago [-]
It seems this version is also adding hx-live. Anyone used it before? How does it compare against Alpine.js?
flossly 4 days ago [-]
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.
anamexis 4 days ago [-]
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).
hackingonempty 4 days ago [-]
You can use ReScript with Htmx (or anything else) and get no runtime errors. It has a sound type system, great language.
flossly 22 hours ago [-]
I like ReScript/Reason. But it's no were close to Elm.
Htmx is the opposite of what I like. I will not use it ever for something serious.
hackingonempty 1 hours ago [-]
HTMX is designed for enhancing web pages, not making full apps on web platform as Elm is. They have different use cases.
hollowturtle 4 days ago [-]
"On this page" anchor navigation doesn't work for me :( Mobile Safari
vercelsucks 3 days ago [-]
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.
jamesforestwest 4 days ago [-]
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
3 days ago [-]
novoreorx 3 days ago [-]
Can anyone convince me why I should choose HTMX rather than vanilla JS for "sites with limited interactivity"?
alsanan 4 days ago [-]
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.
cubefox 4 days ago [-]
The anchor links in the "on this page section" don't work for me (Android Firefox/Chrome).
SomeHacker44 3 days ago [-]
Shame the page does not tell you what HTMX is, even in one sentence.
yawaramin 3 days ago [-]
The explanation is a single, obvious click away.
enbugger 3 days ago [-]
Is it a good idea to code an app with infinite canvas (like Excalidraw) in Htmx?
konsalexee 3 days ago [-]
Nope, this kind of app will hold a ton of business logic in the JS side, so HTMX is irrelevant in this context.
93po 4 days ago [-]
i'd avoid imo, i'm an intern that got fired from htmx and the ceo was a jerk
As CEO of HTMX I am proud of what we have achieved.
jorelfermin 4 days ago [-]
Great to see progress continues and the CEOs continue to grow.
nektro 3 days ago [-]
fantastic library. htmx has completely changed the way i think about the web in the past year or so
asdfsa32 3 days ago [-]
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.
yawaramin 3 days ago [-]
What part of the Fixi project is building something like React?
asdfsa32 2 days ago [-]
Not react yet, but it is approaching the early 2010 jQuery and Backbone vibes, so give it another 5 years and it will converge to React.
yawaramin 2 days ago [-]
The htmx creator has made similar things for a long time, if anything htmx has diverged from those ideas by taking Intercooler.js and stripping out the bundled jQuery to simplify it and create htmx. See https://news.ycombinator.com/item?id=49496634
asdfsa32 2 days ago [-]
Have you looked at the project for which htmx4 is released for? it is basically mvc + toolbelt + network library and all that jazz like it is 2012.
StrangeSound 4 days ago [-]
> Note that attributes like hx-disinherit
Looks like some copy is missing here
recursivedoubts 4 days ago [-]
Yep, fixed
mkl 4 days ago [-]
> (plus at game)
Typo of "a"?
recursivedoubts 4 days ago [-]
with enough eyes all typos are shallow (it was a long night)
dormento 4 days ago [-]
Its ok now you may rest <3
(Congrats on the release)
nothrowaways 4 days ago [-]
That's a great-looking Toyota. What model is it?
recursivedoubts 4 days ago [-]
40 series landcruiser
closingreunion 3 days ago [-]
Image seems to be in the same style as the recent Omarchy Quattro header image. Is this a meme?
hnacobsxph 3 days ago [-]
The simplicity is the point
philipwhiuk 4 days ago [-]
The game page is pretty broken...
4 days ago [-]
anonymous344 4 days ago [-]
why would i use htmx?
whats the user case
tdhz77 4 days ago [-]
Htmx. And then what’s your mobile strat?
seabre 4 days ago [-]
Can we get a Mitsubishi Delica for the next announcement? Thanks.
metrofun 4 days ago [-]
F
fatplexer 4 days ago [-]
E
Foobarsrules 4 days ago [-]
E
chrisweekly 3 days ago [-]
I don't like htmx.
Compared to component-based approaches, its template / DOM / HTTP-fragment contracts are harder to share, type-check, version, and compose.
Application behavior is distributed among:
- Markup attributes and DOM structure
- HTTP endpoints that return fragments rather than whole documents
- Swap rules and event hooks
- Form / query-string / hidden-field state
- Any supplemental JavaScript for widgets and client-only behavior
IME, htmx doesn't remove complexity, it just relocates it.
Full Disclosure, I am CEO of HTMX
https://x.com/htmx_org/status/1726986945430233323
Please take a look at the official documentation for htmx, which specifically clarifies that the author owns many hinges.
Absolute madman.
> You can put it on your LinkedIn, because it’s true.
I only take LinkedIn seriously under extreme protest, so this is extremely tempting.
It's just about all Twitter links, where's XCancel/Nitter when you need 'em :(
> Full Disclosure, I am CEO of HTMX
i think you've found a good job!
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-...
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).
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.
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.
Skill.md here: https://github.com/dunctk/rasx-app-framework
DynamoDB, API Gateway, Step Functions and HTMX.
I actually think JSX is better, but I am bored of it because we don't need state in JS no more.
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!
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.
Our Golang and Python SDKs support SQLite as well as Postgres.
I recommend updating the README to mention SQLite somewhere, with maybe a link to https://docs.dbos.dev/golang/reference/configuration#using-s... ?
And if you do, why start with a simpler framework?
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
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'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.
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.
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.
> 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.
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.
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?
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 understand the issue of mixing state models.. angular SPA style vs HATEOAS.
But that still doesn't answer what I was asking about mixing presentation concerns into business logic. Returning HTML means the presentation layer has to know about HTML. Why would that require the business logic to know about it?
Do you not have a database for your backend? Managing state is kind of their thing.
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.
And it makes me think you haven't had as much experience as you think.
How do you deal with form state using CSS? Where does it get stored? In the html as elements? So not on the server?
For really simple stuff you can use CSS sibling selectors: https://jsfiddle.net/Kqscu/4/
For more complicated stuff, it is in the html as elements. With htmx you can often do this by making a request to the server to update a subtree; the server doesn't need to know the state that the user is seeing, just what is happening in the specific request.
Sometimes just updating html subtrees isn't quite enough, and then I use javascript. Transient state that is only concerned with what is presented to the user is probably not best done on the server.
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.
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).
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.
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.
Having the client/server split has made this a lot easier to reason about. I store client state on the client and server state stays on the server.
When I said I don't use sessions, I should have specified I don't use them for application state (or roles and stuff).
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.
Can you elaborate on the "too complicated" part? It seems a lot simpler to me given the slim surface area of the APIs?
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.
There is sometimes this trends on projects of using anything like a universal hammer. And then they SPA their project.
That's on you not on your platform
Human readers don't receive this level of care or attention.
1. https://news.ycombinator.com/item?id=49062520
2. https://github.com/macton/nagent/blob/main/context/data-orie...
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
"let us rething how extensions can and should work,"
I think you meant rethink here.
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
Automatic enforcement for all services is tricky, because you _can_ depend on JavaScript if the user needs justify it.
[0] https://www.youtube.com/watch?v=GyV_UG60dD4
For what? Don't leave us hanging!
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".
And perhaps the long term goal is if half if not most of HTMX 4.0 could be inside HTML 5 spec.
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.
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.
Disagree. The RoR front end was way more stable and usable than the mess they have made now.
RoR is the only framework I’ve ever heard of being so bad that it killed startups. I personally know of two that were doing well, but RoR was so brittle and slow that they couldn’t hire enough to keep it going. This is compounded by Ruby devs being pretty rare.
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.
This is Hacker News. This is exactly the place to tell people they’re overanalyzing and should just build something.
https://hypermedia.systems/hypermedia-a-reintroduction/
Can anybody explain it better why mixing templates in the backed and HTML in the frontend opposite to keep all the HTML + templates in the browser and only return JSON from the server.
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.
https://bundlephobia.com/package/htmx.org@4.0.0
https://github.com/bigskysoftware/fixi/blob/master/fixi.js
He is catching up though, now approaching the early 2010s jQuery (moxi) and backbonejs era with fixiproject.org
The creator has been working on these ideas for a long time, but the core idea–swapping HTML from the server into the DOM–has been constant throughout.
It's exactly because he followed the past two decades of web dev that htmx avoids almost everything about it. Fixi and htmx extensions follow the 80/20 principle and can work by just being dropped in with a script tag. You don't need an elaborate npm setup, same as everything else in the htmx ecosystem.
I didn’t realize that was allowed.
What do HN mods think of that, dang?
The upgrade is completely voluntary: it won’t even be set as the default version in npm till next year, and there are no known security issues that would force anyone to upgrade. People happy with v2 can just stay on it for the foreseeable future.
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.
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.
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.
Thank you for your kind words!
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'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 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).
You mean generate unmaintainable JavaScript for us.
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
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.
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?
That doesn't mean do dumb / complicated / bloated stuff for no reason. If the best thing for your users is static html, use that.
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.
And I disagree, we definitely use the same API for other contexts.
- If the server is responding with JSON, the client has to parse, decode, and validate the JSON. Then it has to transform it into HTML DOM nodes. Finally, it can inject them into the DOM.
- If the server is responding with a bespoke non-JSON data structure, it's the same situation as above except even more work because a third-party, non-standard library has to decode this structure into something (most likely JSON) and then transform the JSON into HTML nodes, etc. etc.
- If the server is responding with straight-up HTML, the client uses the browser's HTML parser to directly transform it into HTML nodes and inject it into the page. And by the way, the browser engine is essentially a function that is highly optimized for exactly this use case–parsing bytes into DOM nodes.
'We' might use the same API but it's widely accepted that generally the same API doesn't work for all contexts. See https://samnewman.io/patterns/architectural/bff/#general which details the many well-known problems with having a single API for different contexts.
Can anyone confirm this claim? How good is this? Doing everything in HTML/CSS might have some advantages. Is it quick and compatible enough?
So yes, it's using Javascript even if you don't do it directly.
Nonetheless I hope all who do use Htmx, enjoy using it.
Htmx is the opposite of what I like. I will not use it ever for something serious.
Better than htmx IMO.. Same author.
LOL. Frontend dev never changes.
Looks like some copy is missing here
Typo of "a"?
(Congrats on the release)
Compared to component-based approaches, its template / DOM / HTTP-fragment contracts are harder to share, type-check, version, and compose.
Application behavior is distributed among:
IME, htmx doesn't remove complexity, it just relocates it.Context: doing webdev for a living since 1998.