I'm seriously keen on trying it out. It's not like Htmx is bad, I've built a couple of projects in it with great success, but they all required some JS glue logic (I ended up not liking AlpineJS for various reasons) to handle events.
If Datastar can minimize that as well, even better!
The server deciding what to replace reminds me of some old (dangerous, I think) patterns like returning actual JS from the server which the client then executes.
But it was a nice pattern to work with: for example if you made code changes you often got hot-reloading ‘for free’ because the client can just query the server again. And it was by definition infinitely flexible.
I’d be interested to hear from anyone with experience of both Datastar and Hotwire. Hotwire always seemed very similar to HTMX to me, but on reflection it’s arguably closer to Datastar because the target is denoted by the server. I’ve only used Hotwire for anything significant, and I’m considering rewriting the messy React app I’ve inherited using one of these, so it’s always useful to hear from others about how things pan out working at scale.
Blog post author here. I never expect my blog post to get this much attention. I was emotional when I wrote that blog because I had spent a couple weeks to rewrite a service for self use. And the service was almost completely migrated to datastar from htmx.
I was facing a situation where I either need to stuck with the beta, or paying a pro version, as I was using the replace-url function a lot.
I was emotionally feeling betrayed. I went to the datastar reddit thread to raise my doubt that whether there would be more features that I rely on in the free version would be stripped out and be put behind the paywall. I was fine to convert my service to purely free tier features, when my service is stable and usable, I was very willing to buy a pro license.
But you know what? The datastar author jumped out and stated two points. He said the release version of datastar is a full rewrite, if I am not paying, I could stay in beta or fork it. And in open source world, he owned me nothing. Very legit points.
However, the real reason behind that fuck you statement is that I was attacked by the datastar discord members multiple times. In one of the humiliating replies I got, that guy said some one in the discord server told them to show support to datastar. Instead of supporting, they just mocked me and called me a troll as if I was an obstacle to their potential success, multiple people, multiple times.
I noticed some comments in the thread said that I don't know how to use version control, or ignorant towards software license. Well, I do use version control and occasionally contribute to open source projects. I am a doctor, I may not be as skillful as you all, but I do know some basics in programming.
I've written costumer-facing interfaces in HTMX and currently quite like it.
One comment. HTMX supports out-of-bound replies which makes it possible to update multiple targets in one request. There's also ways for the server to redirect the target to something else.
I use this a lot, as well as HTMX's support for SSE. I'd have to check what Datastar offers here, because SSE is one thing that makes dashboarding in HTMX a breeze.
Being new to Datastar and having seen some of the hype recently, I'm really not sold on it.
The patch statements on the server injecting HTML seems absolutely awful in terms of separation of concerns, and it would undoubtedly be an unwieldy nightmare on an application of any size when more HTML is being injected from the server.
I can't say I like the server returning portions of HTML that need to match the HTML in the client, but I can see myself trying it in a monorepo and using some templating lib on both sides.
I was late to the hypermedia party, started with datastore but now use HTMX when i want something in this space. The datastar api is a bit nicer but htmx 2.0 supports the same approach, the key thing is what htmx calls OOB updates, with that in place, everything else is a win in the htmx column.
I don't see a good enough reason to move over from Htmx, unless im missing something you're just moving more lines to the server side. At this point why not just bite the bullet and go back to the old days of php serving html. "Look mom, 0 lines of markup"
ALL OF THE LINES ARE ON THE SERVER FOR BOTH OF THEM! That's what ssr html is!
Both are just small javascript libraries that allow you to do some interactive stuff declarative in your ssr html. But Datastar is smaller, simpler, more powerful and closer to web standards.
> ...To accomplish this, most HTMX developers achieve updates either by “pulling” information from the server by polling every few seconds or by writing custom WebSocket code, which increases complexity.
This isn't true. HTMX has native support for "pushing" data to the browser with Websockets or SSE, without "custom" code.
Htmx got me into hypermedia heaven, but it lead me to datastar for sure.
Recently we also had an interview with the creator of datastar, where he also talked a bit about darkstar (something he wants to built on top of webtransport for the few things where datastar is no well suited for now)
I may be just completely out of my depth here, but I look at the cool example on their website, the Open the pod bay doors, HAL bit, and I don't like it, at all.
And reading comments one would think this is some amazing piece of technology. Am I just old and cranky or something?
This feels... very hard to reason about. Disjoint.
You have a front-end with some hard-coded IDs on e.g. <div>s. A trigger on a <button> that black-box calls some endpoint. And then, on the backend, you use the SDK for your choice language to execute some methods like `patchElements()` on e.g. an SSE "framework" which translates your commands to some custom "event" headers and metadata in the open HTTP stream and then some "engine" on the front-end patches, on the fly, the DOM with whatever you sent through the pipe.
This feels to me like something that will very quickly become very hard to reason about globally.
Presentation logic scattered in small functions all over the backend. Plus whatever on-render logic through a classic template you may have, because of course you may want to have an on-load state.
I'm doing React 100% nowadays. I'm happy, I'm end-to-end type safe, I can create the fanciest shiny UIs I can imagine, I don't need an alternative. But if I needed it, if I had to go back to something lighter, I'd just go back to all in SSR with Rails or Laravel and just sprinkle some AlpineJS for the few dynamic widgets.
Anyway, I'm sure people will say that you can definitely make this work and organize your code well enough and surely there are tons of successful projects using Datastar but I just fail to understand why would I bother.
The idea of HATEOS is that HTML isn't "presentation logic", it IS the state of your application. Then, the backend manages the state of your application.
Be careful with Datastar. If the paid "PRO" features are not enough to warn you let me just say that I had a very unfortunate encounter with the author. I asked about how to do something like wire:navigate in Livewire and he told me that's not necessary and I don't understand Datastar and I should go fuck off. He was very ad hominem and aggressive. Won't use his product ever.
Funny, the next cycle is starting ;-) I remember Vaadin which was a great framework just before angularJS took off. Now Datastar seems to give it another try and bring everyone back to server calls...
Thanks to Chris to continue challenging his comfort zone (and mine!) and sharing his impressions and learnings with us!
I may be a little biased because I've been writing webapps with htmx for 4 years now, but here are my first thoughts:
- The examples given in this blogpost show what seems to be the main architectural difference between htmx and Datastar: htmx is HTML-driven, Datastar is server-driven. So yes, the API on client-side is simpler, but that's because the other side has to be more complex: on the first example, if the HTML element doesn't hold the information about where to inject the HTML fragment returned by the server, the server has to know it, so you have to write it somewhere on that side. I guess it's a matter of personal preference then, but from an architecture point-of-view both approaches stand still
- The argument of "less attributes" seems unfair when the htmx examples use optional attributes with their default value (yes you can remove the hx-trigger="click" on the first example, that's 20% less attributes, and the argument is now 20% less strong)
- Minor but still: the blogpost would gain credibility and its arguments would be stronger if HTML was used more properly: who wants to click on <span> elements? <button> exists just for that, please use it, it's accessible ;-)
- In the end I feel that the main Datastar selling point is its integration of client-side features, as if Alpine or Stimulus features were natively included in htmx. And that's a great point!
As far as I understand, the main difference between HTMX and datastar is that HTMX uses innerHTML-swap by default and datastar uses the morph-swap by default, which is available as an extension for HTMX [1].
Another difference is that datastar comes with SSE, which indeed makes it server driven, but you don't have to use SSE. Also datastar comes with client-side scripting by default. So you could say the datastar = integrated HTMX + idiomorph + SSE + Alpine.
> Since then, teams everywhere have discovered the same thing: turning a single-page app into a multi-page hypermedia app often slashes lines of code by 60% or more while improving both developer and user experience.
Well, not at all. The only compelling reason for me to use server-side rendering for apps (not blogs obviously,they should be HTML) is for metadata tags. That's why I switched from pure React and everything has been harder, slower for the user and more difficult to debug than client-side rendering.
I don't think the article does a good job of summarising the differences, so I'll have a go:
* Datastar sends all responses using SSE (Server Side Events). Usually SSE is employed to allow the server to push events to the client, and Datastar does this, but it also uses SSE encoding of events in response to client initiated actions like clicking a button (clicking the button sends a GET request and the server responds with zero or more SSE events over a time period of the server's choice).
* Whereas HTMX supports SSE as one of several extensions, and only for server-initiated events. It also supports Websockets for two-way interaction.
* Datastar has a concept of signals, which manages front-end state. HTMX doesn't do this and you'll need AlpineJS or something similar as well.
* HTMX supports something called OOB (out-of-band), where you can pick out fragments of the HTML response to be patched into various parts of the DOM, using the ID attribute. In Datastar this is the default behaviour.
* Datastar has a paid-for Pro edition, which is necesssary if you want certain behaviours. HTMX is completely free.
I think the other differences are pretty minor:
* Datastar has smaller library footprint but both are tiny to begin with (11kb vs 14kb), which is splitting hairs.
* Datastar needs fewer attributes to achieve the same behaviours. I'm not sure about this, you might need to customise the behaviour which requires more and more attributes, but again, it's not a big deal.
D* doesnt only use SSE. It can do normal http request-response as well. Though, SSE can also do 0, 1 or infinite responses too.
Calling datastar's pro features "necessary" is a bit disingenuous - they literally tell people not to buy it because those features, themselves, are not actually necessary. Theyre just bells and whistles, and some are actually a bad idea (in their own words).
Datastar is 11kb and that includes all of the htmx plugins you mentioned (sse, idiomorph) and much more (all of alpine js, essentially).
As someone on the sideline who's been considering HTMX, its alternatives and complements, this was a helpful comment! Even without having used any of it, I get the feeling they're going in the right direction, including HTMX author's humorous evangelism. If I remember correctly he also wrote Grug, which was satire and social criticism of high caliber.
That's... no, servers sending HTML to the client was where we started with all this.
That's why the H in HTTP and in HTML stand for "Hypertext." Any time a webserver replies with something other than markup, _that's_ the extension/exception to that very old design.
Now, if you're talking about the separation of user-interface, data, logic, and where HTML fits in, that's a much bigger discussion.
For those of you who don't think Datastar is good enough for realtime/collaborative/multiplayer and/or think you need any of the PRO features.
These three demos each run on a 5$ VPS and don't use any of the PRO features. They have all survived the front page of HN. Datastar is a fantastic piece of engineering.
On both the checkboxes/cells examples there's adaptive view rendering so you can zoom out a fair bit. There's also back pressure on the virtual scroll.
Can you explain how these work? Does the server send small subrectangles of the large grid when the user scrolls to new regions of the grid? Does the browser actually have a two-dimensional array in memory with a billion items, or is there some other data structure?
69 comments
[ 2.6 ms ] story [ 66.7 ms ] threadI'm seriously keen on trying it out. It's not like Htmx is bad, I've built a couple of projects in it with great success, but they all required some JS glue logic (I ended up not liking AlpineJS for various reasons) to handle events.
If Datastar can minimize that as well, even better!
https://data-star.dev/
The server deciding what to replace reminds me of some old (dangerous, I think) patterns like returning actual JS from the server which the client then executes.
But it was a nice pattern to work with: for example if you made code changes you often got hot-reloading ‘for free’ because the client can just query the server again. And it was by definition infinitely flexible.
I’d be interested to hear from anyone with experience of both Datastar and Hotwire. Hotwire always seemed very similar to HTMX to me, but on reflection it’s arguably closer to Datastar because the target is denoted by the server. I’ve only used Hotwire for anything significant, and I’m considering rewriting the messy React app I’ve inherited using one of these, so it’s always useful to hear from others about how things pan out working at scale.
Which states some of the basic (great) functionality of Datastar has been moved to the Datastar Pro product (?!).
I’m eager to support an open source product financially and think the framework author is great, but the precedent this establishes isn’t great.
I was facing a situation where I either need to stuck with the beta, or paying a pro version, as I was using the replace-url function a lot.
I was emotionally feeling betrayed. I went to the datastar reddit thread to raise my doubt that whether there would be more features that I rely on in the free version would be stripped out and be put behind the paywall. I was fine to convert my service to purely free tier features, when my service is stable and usable, I was very willing to buy a pro license.
But you know what? The datastar author jumped out and stated two points. He said the release version of datastar is a full rewrite, if I am not paying, I could stay in beta or fork it. And in open source world, he owned me nothing. Very legit points.
However, the real reason behind that fuck you statement is that I was attacked by the datastar discord members multiple times. In one of the humiliating replies I got, that guy said some one in the discord server told them to show support to datastar. Instead of supporting, they just mocked me and called me a troll as if I was an obstacle to their potential success, multiple people, multiple times.
I noticed some comments in the thread said that I don't know how to use version control, or ignorant towards software license. Well, I do use version control and occasionally contribute to open source projects. I am a doctor, I may not be as skillful as you all, but I do know some basics in programming.
I've written costumer-facing interfaces in HTMX and currently quite like it.
One comment. HTMX supports out-of-bound replies which makes it possible to update multiple targets in one request. There's also ways for the server to redirect the target to something else.
I use this a lot, as well as HTMX's support for SSE. I'd have to check what Datastar offers here, because SSE is one thing that makes dashboarding in HTMX a breeze.
You have my sword!
The patch statements on the server injecting HTML seems absolutely awful in terms of separation of concerns, and it would undoubtedly be an unwieldy nightmare on an application of any size when more HTML is being injected from the server.
Let's say I'm intrigued and on the fence.
Both are just small javascript libraries that allow you to do some interactive stuff declarative in your ssr html. But Datastar is smaller, simpler, more powerful and closer to web standards.
This isn't true. HTMX has native support for "pushing" data to the browser with Websockets or SSE, without "custom" code.
https://netstack.fm/#episode-4
And reading comments one would think this is some amazing piece of technology. Am I just old and cranky or something?
This feels... very hard to reason about. Disjoint.
You have a front-end with some hard-coded IDs on e.g. <div>s. A trigger on a <button> that black-box calls some endpoint. And then, on the backend, you use the SDK for your choice language to execute some methods like `patchElements()` on e.g. an SSE "framework" which translates your commands to some custom "event" headers and metadata in the open HTTP stream and then some "engine" on the front-end patches, on the fly, the DOM with whatever you sent through the pipe.
This feels to me like something that will very quickly become very hard to reason about globally.
Presentation logic scattered in small functions all over the backend. Plus whatever on-render logic through a classic template you may have, because of course you may want to have an on-load state.
I'm doing React 100% nowadays. I'm happy, I'm end-to-end type safe, I can create the fanciest shiny UIs I can imagine, I don't need an alternative. But if I needed it, if I had to go back to something lighter, I'd just go back to all in SSR with Rails or Laravel and just sprinkle some AlpineJS for the few dynamic widgets.
Anyway, I'm sure people will say that you can definitely make this work and organize your code well enough and surely there are tons of successful projects using Datastar but I just fail to understand why would I bother.
I may be a little biased because I've been writing webapps with htmx for 4 years now, but here are my first thoughts:
- The examples given in this blogpost show what seems to be the main architectural difference between htmx and Datastar: htmx is HTML-driven, Datastar is server-driven. So yes, the API on client-side is simpler, but that's because the other side has to be more complex: on the first example, if the HTML element doesn't hold the information about where to inject the HTML fragment returned by the server, the server has to know it, so you have to write it somewhere on that side. I guess it's a matter of personal preference then, but from an architecture point-of-view both approaches stand still
- The argument of "less attributes" seems unfair when the htmx examples use optional attributes with their default value (yes you can remove the hx-trigger="click" on the first example, that's 20% less attributes, and the argument is now 20% less strong)
- Minor but still: the blogpost would gain credibility and its arguments would be stronger if HTML was used more properly: who wants to click on <span> elements? <button> exists just for that, please use it, it's accessible ;-)
- In the end I feel that the main Datastar selling point is its integration of client-side features, as if Alpine or Stimulus features were natively included in htmx. And that's a great point!
As far as I understand, the main difference between HTMX and datastar is that HTMX uses innerHTML-swap by default and datastar uses the morph-swap by default, which is available as an extension for HTMX [1].
Another difference is that datastar comes with SSE, which indeed makes it server driven, but you don't have to use SSE. Also datastar comes with client-side scripting by default. So you could say the datastar = integrated HTMX + idiomorph + SSE + Alpine.
[1] https://htmx.org/extensions/idiomorph/
Well, not at all. The only compelling reason for me to use server-side rendering for apps (not blogs obviously,they should be HTML) is for metadata tags. That's why I switched from pure React and everything has been harder, slower for the user and more difficult to debug than client-side rendering.
* Datastar sends all responses using SSE (Server Side Events). Usually SSE is employed to allow the server to push events to the client, and Datastar does this, but it also uses SSE encoding of events in response to client initiated actions like clicking a button (clicking the button sends a GET request and the server responds with zero or more SSE events over a time period of the server's choice).
* Whereas HTMX supports SSE as one of several extensions, and only for server-initiated events. It also supports Websockets for two-way interaction.
* Datastar has a concept of signals, which manages front-end state. HTMX doesn't do this and you'll need AlpineJS or something similar as well.
* HTMX supports something called OOB (out-of-band), where you can pick out fragments of the HTML response to be patched into various parts of the DOM, using the ID attribute. In Datastar this is the default behaviour.
* Datastar has a paid-for Pro edition, which is necesssary if you want certain behaviours. HTMX is completely free.
I think the other differences are pretty minor:
* Datastar has smaller library footprint but both are tiny to begin with (11kb vs 14kb), which is splitting hairs.
* Datastar needs fewer attributes to achieve the same behaviours. I'm not sure about this, you might need to customise the behaviour which requires more and more attributes, but again, it's not a big deal.
D* doesnt only use SSE. It can do normal http request-response as well. Though, SSE can also do 0, 1 or infinite responses too.
Calling datastar's pro features "necessary" is a bit disingenuous - they literally tell people not to buy it because those features, themselves, are not actually necessary. Theyre just bells and whistles, and some are actually a bad idea (in their own words).
Datastar is 11kb and that includes all of the htmx plugins you mentioned (sse, idiomorph) and much more (all of alpine js, essentially).
That's why the H in HTTP and in HTML stand for "Hypertext." Any time a webserver replies with something other than markup, _that's_ the extension/exception to that very old design.
Now, if you're talking about the separation of user-interface, data, logic, and where HTML fits in, that's a much bigger discussion.
For those of you who don't think Datastar is good enough for realtime/collaborative/multiplayer and/or think you need any of the PRO features.
These three demos each run on a 5$ VPS and don't use any of the PRO features. They have all survived the front page of HN. Datastar is a fantastic piece of engineering.
- https://checkboxes.andersmurphy.com/
- https://cells.andersmurphy.com/
- https://example.andersmurphy.com/ (game of life multiplayer)
On both the checkboxes/cells examples there's adaptive view rendering so you can zoom out a fair bit. There's also back pressure on the virtual scroll.