Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Computer works in binary
htmx 1 htmx 2 htmx 4
I look forward to version 8 in 2030.
(Meaning there always was a version 3! Just include both htmx1 and htmx2 onto your webpage!)
by masfoobar - This is great! I had to create an xhr-fetch-proxy to use fetch and htmx. This change should open up a lot of fun possibilities.by logankeenan
- in 4.0 the request cycle is totally open: you can replace the fetch() implementation on a per-request basis
learned that trick from fixi.js
- Any chance we could get a poll on changing the default swap strategy as documented in the quirks page? https://htmx.org/quirks/#the-default-swap-strategy-is-innerh...by rbjorklin
- Looking forward to porting my demos [1] from Datastar to HTMX once V4 is stable enough. Exciting stuff. Nice to see HTMX innovating again.by andersmurphy
- I really enjoyed reading this - very clear technical writing and I learned quite a bit about htmx and their approach to API design generally from it.by simonw
- Great to see this evolution! Realtime ssr hypermedia is definitely the future.
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?
by nchmy - One important difference that I found is that HTMX (and Alpine AJAX) can easily push a URL into the browser's location history. I've used this feature often with my Django projects--essentially storing the state in the URL which is great for sharing URLs or bookmarking them. As far as I'm aware, Datastar have locked this feature behind the "Pro" paywall.by amanzi
- The irony that the Datastar author originally tried to have those features added to HTMX a few years ago.by andersmurphy
- > why use HTMX when it really seems like (a heavier) Datastar-lite?
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/
by alexpetros - I took a look at Datastar, and pretty quickly realized I really don't like libraries which try to do so many different things. The surface area of the API is way too big. htmx is already too big for me, I tend to reach for mostly vanilla-only or small vanilla-adjacent solutions I can either write by hand or import. But as I've been experimenting with htmx (including its very good extensions API), I'm realizing it's in a pretty good sweet spot overall.
I'm very excited about htmx 4.0 and sounds like things are headed in a promising direction.
by jaredcwhite - Because Datastar Pro isn't FOSS, and speaking from a purely probabilistic and historical standpoint, your odds of getting rugpulled (in some form or another) might as well be 100%.
- I feel like people who crave stability pull all the wrong lessons from how to get to stability when doing this sort of "ok we'll make _one_ major version with all the breaking changes we've built up over time".
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.
by rtpg - >I feel like people who crave stability pull all the wrong lessons from how to get to stability when doing this sort of "ok we'll make _one_ major version with all the breaking changes we've built up over time".
Yeah this is a huge fallacy. If you do a breaking change, you want to do as few breaking changes at once as possible, with as little impact as possible and in the best case scenario you're in contact with every single person that is affected by the breaking change, so that it can be handled without anyone noticing anything other than having to bump a library version, which they were doing anyway since they're running a new Python version in the first place.
The dumbest change in python 3 was removing the print statement [0]. Maximum breakage, minimum gain. They could have introduced the new function as println() and deprecated the print statement in Python 3.
by imtringued - > By switching to fetch(), we can take advantage of its support for readable streams, which allow for a stream of content to be swapped into the DOM, rather than a single response.
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
by lazypenguin - > hx-target attribute is explicitly declared as inherited on the enclosing div and, if it wasn’t, the button elements would not inherit the target from 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.
by deepsun - or 'cascade' ?by treve
- Maybe `heritable`?by mrj
- yeah, i'm struggling w/it, willing to consider options
- > 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.
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".
by jonahx - I was going to make the same comment. "inherited" is the wrong word. I like "inherit" too. And it's a bit shorter which is always nice. I guess "bequeath" might work also?by SoftTalker
- I think the ideas behind HTMX are cool, and Carson’s advocacy around Hypermedia is great.
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.
by JSR_FDED - Datastar looks interesting, but their guide on how to redirect a user is a joke.
async def redirect_from_backend():
LOL, they really think it's a good use of server resources to sleep so the client doesn't have to.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...
by nprateem - > htmx 2.0 (like htmx 1.0 & intercooler.js 1.0) will be supported in perpetuity, so there is absolutely no pressure to upgrade your application: if htmx 2.0 is satisfying your hypermedia needs, you can stick with it
This is commendable, specially during times when libraries and programs aren't afraid of breaking changes and API churn.
by gr4vityWall - > So, eventually & reluctantly, I have changed my mind: there will be another major version of htmx.
> 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
by booi - The author is lucky the phrasing wasn't "there won't be another major version of htmx", or even "a third version".by jraph
- Got a https://en.wikipedia.org/wiki/Leisure_Suit_Larry#Leisure_Sui... vibe from it.by tidbeck
- Should go directly to htmx 4.1, so we can finally have xhtmx 1.0by fmbb
- It's an amusing solution, but if this ends up being anything like the missing PHP 6, it's also going to cause confusion for users. It might've been better to just mea culpa and release 3.0 anyway. I can't imagine anybody would really hold it against the author.by SquareWheel