> However, in order to keep my word that there will not be a htmx 3.0, the next release will instead be htmx 4.0.
technically correct.. the best kind of correct
Then 8
You can derive a lot of information about my age and current version from the dad-joke version string “I thought it was 6 7 when 7 8 9”
This is commendable, specially during times when libraries and programs aren't afraid of breaking changes and API churn.
This feels like a repeat of the Python 3.0 strategy, though obviously at a much smaller scale. Some stuff is of course hard to roll out but to me it feels "obvious" that having a 4.0 with the inheritence change (or even better, a 2.1 with a toggle on that change!), then a 5.0 with some other changes, then a 6.0 with other changes... all feels way easier to manage than a 4.0 with all the changes at once.
We have version pinning! People who want 2.0 can have 2.0 "forever", so version numbers that go up very high are not actually a problem. Many releases can of course be a bit of a frustration from a release maker's perspective, but given that htmx is the way it is (ain't even getting type checking helping you out on any of this like you would with React!), having the gradual path seems way better.
"I think I've handled the 10 changes in between 2.0 and 4.0... but forgot the 11th change" is a constant annoyance with these huge major version bumps.
I will once again point to the Django strategy of having breaking changes be rolled out over several releases, including in between releases where "both" models exist. It is a very nice way to do release management when rolling things out, gives good checkpoints for pushing things out, and overall means users are seeing less bugs. Going from `XMLHttpRequest` to `fetch` really might not be a feasable thing to toggle, but a lot of the other stuff in that list feels like it.
So confusing. I'm pretty sure it should be "inheritable", because "inherited" on an attribute means the attribute is inherited, not the element's children will inherit the attribute.
UPDATE: or "inherit", sounds like a command, little less confusing.
That is one interpretation, but not the one I had reading it. I read it as "This target will be inherited by its children," rather than "This target is inherited from its parents," which, while a grammatical possibility, doesn't really make sense because you are specifying it right there with the equal sign.
Both "inherit" and "inheritable" have the same possible double readings. Something like "pass-to-children" or "pass-down" would remove the possible ambiguity, but I'm not sure like either better than "inherited".
Like male pattern baldness, we are cursed by our parents to inherit it
I came from SPA-land and was tired of the fundamental architectural issue of having to keep the front-end and back-end state in sync.
I’ve compared Datastar and HTMX and decided on Datastar. There’s overlap between the two libraries in that they both support the request/response model, but with Datastar my learning investment takes me further and opens up new possibilities.
In one project I was able to remove a bunch of polling code and simply push a signal from the server to the browser when an external event occurred. The reduction in complexity was crazy.
On an internal tool I noticed I didn’t need Alpine.js anymore, and while anytime I can remove a dependency is a good time, the conceptual simplicity is what really makes me happy.
Now I’m doing a small app where I decided to make a streaming connection between browser and server and simply regenerate and send the entire view over that connection anytime something changes. Intuitively this felt wasteful but it turned out that with compression this works beautifully. There’s just less code in my app, and the code that’s there is less “fiddly” not having to deal with partial updates of the page.
If you’re coming from the world of SPAs, definitely check out both.
async def redirect_from_backend():
yield SSE.patch_elements('<div id="indicator">Redirecting in 3 seconds...</div>')
await asyncio.sleep(3)
yield SSE.execute_script('window.location = "/guide"')
[1] https://data-star.dev/how_tos/redirect_the_page_from_the_bac...
Based on this section, it will be interesting to see how this evolves. I've used HTMX a bunch but after stumbling on Datastar I've come to prefer it. Partially because I don't need something like alpine.js to get some frontend goodies but also because I've come to appreciate the power of SSE streaming morphable targets to the browser
So first you weren't going to make a new major version, because htmx was sooo perfect, but now you had realized how much it can be improved.
Obviously, all software needs to evolve, and it was always very silly to say "this is the final major version". Why would someone use software from such kind of developer is beyond my understanding. But of course I also don't understand anything about this library; this surely must be some kind of trolling:
> We are going to adopt a new standard for event naming to make things even clearer:
> htmx:<phase>:<system>[:<optional-sub-action>]
It's truly wonderful what can people do to avoid writing JavaScript :D
well, except when you want to do drag and drop sorting and this other thing.
yeah you get to communicate intent with html, but ignoring the security concerns for arguments sake, an inline script tag or your good old onclick event handler can do that too.
Okay, the author changed idea, so?
What's your point?
But, my thoughts immediately go to Datastar, which has Fetch, SSE, declarative signals and js expressions, dom morphing, and much more - in a tiny package. I find it to have a more flexible, expressive and standards-compliant API as well. And it'll soon have a simple reactive web components and css framework as well.
At this point, why use HTMX when it really seems like (a heavier) Datastar-lite?
But Datastar is different. The project is literally owned by a 501c3 non-profit. The devs have dayjobs and donate their spare time to this. Funds are for going to conferences or hosting their own
And 99% of the features/value that I mentioned is MIT licensed, and the "rugpulled" code is still available to easily port via the plugin API.
If the Postgres team released PGPro, swore it just contained anti patterns and you can just write the code yourself if you needed that feature, you’d roll your eyes, no?
It’s about the fact they went there, not about the intentions.
The reason to use htmx is that it has a simpler interface optimized for the majority use-case.
With htmx, you are largely tied to a request/reply paradigm. Something happens that triggers a request (e.g. user clicks a button, or some element scrolls into view), htmx sends the request, and then it processes the response. The htmx interface (`hx-get`, hx-trigger`) is optimized to make this paradigm extremely simple and concise to specify.
Datastar's focus (last I checked) is on decoupling these two things. Events may stream to the client at any time, regardless of whether or not they were triggered by a specific action on the client, and they get processed by Datastar and have some effect on the page. htmx has affordances for listening to events (SEE extension, new fetch support) and for placing items arbitrarily on the page (out-of-band swaps) but if your use-case is a video game or a dashboard or something else where the updates are frequently uncorrelated with user actions, Datastar makes a lot of sense. It's a bit like driving a manual transmission.
Delaney is fond of saying that there's no need for htmx when Datastar can technically do everything htmx can [0]. But I think this misses the point of what makes htmx so popular: most people's applications do fit within a largely request/reply paradigm, and using a library that assumes this paradigm is both simpler to implement and simpler to debug. As an htmx maintainer, I often encourage people to even use htmx less than they want to, because the request/reply paradigm is very powerful and the more you can adhere to browser's understanding of it, the more durable and maintainable your website will be [1].
[0] https://data-star.dev/essays/v1_and_beyond
[1] https://unplannedobsolescence.com/blog/less-htmx-is-more/
1. Datastar supports req/reply just fine - be it via normal text/html responses, or SSE (0, 1, or infinity responses) https://data-star.dev/reference/actions#response-handling. So, the crux of your argument is moot...
Moreover, if htmx's real value is ajax request/response, then why are you introducing SSE as a first-class citizen now?
2. Datastar has data-on, and various other attributes, that allow for triggering far more actions than just backend requests, from far more (any) events. I'm glad to see that htmx is now following suit with hx-on, even if it is apparently limited in capabilities.
3. Datastar can do OOB-swaps just fine - that's literally the core functionality, via (their own, faster) idiomorph.
4. Its a misnomer that Datastar is for video games etc - again, as described above, it can do all of the simple things that that HTMX can do, and more. And, again, why is HTMX introducing SSE if its so apparently unnecessary and unwieldy?
5. What makes htmx popular is that it was the first library to make declarative fragment swapping easy. And Carson is just a god-tier marketer. Its nice to see that he's now realized that Delaney was on to something when he wanted to introduce all of these v4 features to HTMX 3 years ago, but was (fortunately for us happy users) forced to go make Datastar instead.
6. We havent even talked about one of the key features - declarative signals. Signals are justifiably taking over all of the JS frameworks and there's even an active proposal to make them part of the web platform. D* makes them simpler to use than any of them, and in a tiny package.
I, Delaney, and all other D* users are grateful for HTMX opening this door. But I reiterate my original question - now that HTMX is becoming Datastar-lite, why not just use Datastar given that the powerful extras don't add any complexity and comes in a smaller package?
<button hx-get="/contact/1/edit">
And here's the datastar one, edited for parity: [1]
<button data-on:click="@get('/contact/1/edit')">
The htmx one is simpler. There's fewer mini-languages to learn and the API makes more assumptions about what you want. As you noted, Datastar has more generalized mechanisms that are certainly less clunky than htmx's if you lean heavily into more signals- or event-driven behavior, but for (what I believe to be) the majority use-case of a CRUD website, htmx's simpler interface is easier to implement and debug.(For example: you will see the response associated with the request in the browser network tab; I'm not sure if Datastar has a non-SSE mode to support that but it wouldn't be true for SSE.) To each their own.
As for "well then why implement X, Y, or Z," as the OP notes, refactoring to use fetch() means you get them largely for free, without compromising the nice interface. So why not?
Moreover, the fact that Datastar is more generalized is actually better - HTMX has vastly more (non-standards-compliant) attributes that you need to learn.
vs
https://data-star.dev/reference/attributes
> I'm not sure if Datastar has a non-SSE mode to support that but it wouldn't be true for SSE.) To each their own.
My first point was literally saying that it has non-SSE and linked to the docs. You're not even trying to be objective here...
> So why not?
Yes, I have no problem with these things being implemented in v4. In fact, celebrated it in my original post. I brought it all up because you were describing that all as needless complexity in Datastar, but now you're implementing it.
Also, most of Datastar can be trivially disabled/unbundled because its nearly all plugins. That is largely not the case for HTMX.
Thus far, you've simply strongly confirmed my initial hunch that HTMX v4 is unnecessary compared to Datastar.
Which is why HTMX is having to bolt on more gubbins. Because, although it's less characters to type its fundamentally complected and therefore less composable.
I'm sure you've already warched it but if you haven't I'd recommend Rich Hickey's talk Simple made Easy.
HTMX's 4's morph is almost a copy paste of Datastar's.
I think that even with req/resp morph leads to a simpler majority use case and that's what Turbo and Datastar have both shown. No?
v4 makes almost no changes to the interface, other than to flip inheritance to be off by default.
> I think that even with req/resp morph leads to a simpler majority use case and that's what Turbo and Datastar have both shown. No?
Although you can use the idiomorph extension for htmx, I personally don't think idiomorph is simpler, because there's an algorithm choosing what parts of the page get replaced based on the server response; I prefer to specify exactly what parts of the page get replaced in much simpler terms, a CSS selector, with `hx-target`.
Per [1] above, my style is minimize partial page responses wherever possible, so the ones that I do have are bespoke and replace a specific thing.
https://dev.37signals.com/a-happier-happy-path-in-turbo-with...
My interest in htmx is more on the coarse-grained aspects of its interface, not the finer ones, which is a consistent theme in my writings about it [0].
Moreover, the FOSS code still exists and would take 2 minutes to update to the current plugin API (I have Datastar pro and the code is almost exactly the same)
https://github.com/starfederation/datastar/blob/v1.0.0-beta....
The Datastar authors are wrong about this. History push is a very important part of the hypermedia-driven application approach. Because URLs are super important. And we want to make sure that the correct URL is shown for the currently-loaded view, and that the view is reproducible given the URL (as much as possible) so that bookmarking and copy-pasting to send URLs just works as expected.
A really nice article came out about this just recently: https://alfy.blog/2025/10/31/your-url-is-your-state.html
I also wrote a bit more about it here: https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-i...
As it turns out, I shared that very same article in the Datastar discord the other day! Here's some other good ones that I found while digging into the topic, for anyone who cares.
* https://warpspire.com/posts/url-design/
* https://blog.jim-nielsen.com/2023/examples-of-great-urls/
* https://www.w3.org/Provider/Style/URI
* https://www.hanselman.com/blog/urls-are-ui
I strongly agree that good urls are very important. But I don't see how D* prevents correct urls/history at all... You can click anchor links just fine for pages that are genuinely separate pages. If its just a sub page, filter etc, then i think in many cases it should only swap into the dom without updating the history.
Moreover, am I wrong to think that if you use hx-boost to swap in fragments, then the URL that gets updated/saved in history wouldn't actually load the same page if you loaded it from a bookmark? That wouldn't happen with non-boosted anchor links.
Anyway, I'm not the best person to take up this argument. If you are interested at all in some respectful debate on the topic, it would be great if you came by the datastar discord where there's definitely people who would be better able to engage with it. I'd be eager to observe from the sidelines
It depends. If it's a 'resource' (in the REST sense) then it should actually push the URL of the resource into history, because the URL should correspond to the currently viewed resource. This is exactly what I was talking about earlier, it's super important as a basic hypermedia principle.
> if you use hx-boost to swap in fragments, then the URL that gets updated/saved in history wouldn't actually load the same page if you loaded it from a bookmark
See amanzi's explanation or my blog post where I explain the same thing. With htmx we can easily check for the presence of a request header in the backend and serve the appropriate version of the resource: either a partial (fragment) rendering or a full page that contains the resource. I highly recommend reading my blog post: it's not a huge commitment and it will clarify these issues for you.
It's a common pattern with Django and template partials that you check if the request is an AJAX request, in which case you just load a partial template to swap into the existing DOM. Or if it's not an AJAX request, your server-side logic loads the full template.
A simple example would be a to-do list at http://example.com/todo/. Clicking on a task item would swap it into the DOM without a full page load, and then you'd update the URL and browser history to http://example.com/todo/my-task/. Then if you open that URL in a new session, your server side logic would render your page with the "my-task" already selected.
I'm too tired to parse this logic, but I suspect it is a novel entry in techcorp doublespeak/dirty tricks.
* Datastar was re-written from the ground up, numerous times.
* They didn't want to update and maintain the plugins that they viewed as unnecessary/anti-patterns
* People wanted them still, so they said "fine, pay us to port it". Or, do it yourself - the MIT code is sitting right there and the changes are not all that significant. You'd also learn more about D* while at it. I linked in the parent comment to the MIT code - would not be difficult for anyone to do.
I suspect that in the long-run (probably not too far from now), they'll just make those plugins MIT again as the real value of Pro is the inspector, and soon their WIP web component framework (Rocket) and css framework (stellar) - all of which have always been being a commercial license.
p.s. there's no techcorp here. Its literally 3 guys with day jobs donating their time to a 501c3-registered non-profit. Funds go to things like going to conferences, or holding their own.
Ah, yes, a debugging tool. Only professionals need those.
Whatever the case, you dont truly need it, but it is helpful. You buy it for convenience as well as to support the project.
I'm also sure this has already been explained in comments to other posts here as well.
learned that trick from fixi.js
I thought I'd include an example of replacing fetch for anyone that come across this.
const originalFetch = window.fetch;
window.fetch = function(url, options) {
if (url.includes('/api/user')) {
const mockUser = {id: 1, name: 'John Doe', email: 'john@example.com'};
return Promise.resolve(new Response(JSON.stringify(mockUser)));
}
return originalFetch(url, options);
};
<button hx-get="/foo" hx-on:htmx:config:request="ctx.fetch = myCustomFetch">
Do It
</button>