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!
The article stated that he no longer needs eventing to update other parts of the page, he can send down everything at once. So, I guess that is much less complex. Granted, eventing and pulling something down later could be a better approach depending on the circumstance.
"Alpine or Stimulus features were natively included in htmx"
I'm contemplating using HTMX in a personal project - do you know if there are any resources out there explaining why you might also need other libraries like Alpine or Stimulus?
They're for client-side only features. Think toggling CSS classes, updating the index on a slider- you ideally don't want to have to hit the server for that
I'm really just starting with htmx but came across datastar yesterday. This is a great comparison and is confirming some of my impressions, so thanks! I'll still look a bit more but if the main thing is that it's naively adding Alpine or Stimulus then datastar is not for me.
> 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'm not too strong in frontend, but wouldn't this make for a lighter, faster front end? Especially added up over very many elements?
100%. Datastar is just make HTML spec support reactive expression in data-* attributes, that's it. You will become stronger at web cause it just gets out of your way
Reminds me a bit of the Seaside framework in Pharo. A lot of the things I programmed in Pharo at my previous employer was a lot of back and forth between front-end and back-end, because the back-end was managing the front-end state. For B2B apps that don't have a lot of latency requirements, etc., I'd say it's better. For high scalable B2C apps though? No.
Not GP, but I would say, it’s the same reason someone would use React. If you keep you state in a single place, the rest of the app can become very functional and pure. You receive data and tranform it (or render it). The actual business logic that manipulate the state can be contained in a single place.
This reduces a lot of accidental complexities. If done well, you only need to care about the programming language and some core libraries. Everything else becomes orthogonal of each other so cost of changes is greatly reduced.
I would imagine the same arguments for Smalltalk like live coding and an IDE within your production application. So you get some overlap with things like Phoenix LiveView, but more smalltalk-y.
I assume it had backend scaling issues, but usually backend scaling is over-stated and over-engineered, meanwhile news sites load 10+ MB of javascript.
As someone who wants to write open source but needs to be able to capture some financial value from doing that to be able to make it sustainable, what model do you prefer?
My current thoughts lean towards a fully functional open source product with a HashiCorp style BSL and commercial licensing for teams above a size threshold.
I think the open core model is fine, and the most financially sustainable. Just be up front about it from day 1. I don't think the honor system for licensing will get you the results you're wanting.
I can't imagine that works very well for relatively small, simple, functional or intuitive projects though. Incentives wise, is it possible to sell reverse support: extracting payment for all the times the product works so well that support isn't needed?
source is MIT, do what you want. The team found certain plugins to be anti-patterns and support burdens. You can find the old plugins in the repo source, feel free to fork from there!
It's good to know -- having replace-url functionality behind the paywall is likely to be a deal-killer; I can't help but think that this "freemium" model is really going to kill datastar's prospects for taking off; at best it's likely to result in a fork which ends up subsuming the original project.
That said, the attitude of the guy in the article is really messed up. Saying "fuck you" to someone who gave you something amazing for free, because he's not giving you as much as you want for free -- it's entitled to a toxic degree, and poisons the well for anyone else who may want to do something open-source.
It's more like the mouse saying fuck you to the trap holding the cheese. It's not that the mouse isn't grateful for the free cheese. It's just the mouse understands the surrounding context.
> Saying "fuck you" to someone who gave you something amazing for free, because he's not giving you as much as you want for free
I don't have a problem, on principle, with paywalling new features. I don't like it, but I don't think it's bad behaviour.
Putting up a paywall around features that were previously free, however, I do take issue with. It's deceptive and it's not common practice. It tricks people into becoming invested and then holds hostage the features that they've become invested in using. Frankly, fuck that.
On the latter point, couldn't disagree more. He's saying "fuck you" to the product, not the person, and unilaterally removing extant features to paywall them imo is poisoning the well far more than a simple FU to a developer ever could?
We didn't remove the features, if you want to use the old ones they're still there in the repo. We just didn't want to support the old way of doing them when we actively tell people not to use them. If you're going to be a support burden going forward we want you to have skin in the game if not cool do it yourself no one's going to get mad at you
It's also pretty shady that no mention is made of Datastar Pro on the home page [1]. You might well be well on the way to integrating Datastar into your website before you stumble across the Pro edition, which is only mentioned on the side bar of the reference page [2].
Isn't that only a problem if it advertised pro features there without mentioning the fact that they're paid? If it didn't then you could just be happy with the free features, no?
I'd expect it to make it explicit this is a freemium product, with free features and paid features. Nothing is given on the home page to indicate as such.
If they aren’t leading to expect that they have the paid features for free, how is offering them for money any different from just not offering those features at all?
It’s not like your exiting use cases stop working past 10 users or something.
I'm not opposed to open source projects placing features that realistically only large/enterprise users would use behind a paywall, i.e. the open core model. When done fairly, I think this is the most sustainable way to build a business around OSS[1]. I even think that subscriptions to such features are a fair way of making the project viable long-term.
But if the project already had features that people relied on, removing them and forcing them to pay to get them back is a shitty move. The right approach would've been to keep every existing feature free, and only commercialize additional features that meet the above criteria.
Now, I can't say whether what they paywalled is a niche/pro feature or not. But I can understand why existing users wouldn't be happy about it.
These "we cut 70% of our codebase" claims always make me laugh. We have no idea what was going on in that original codebase. The talk literally shows severely cursed lines stretching to the moon like:
<div
hx-get="{% url 'web-step-discussion-items-special-counters' object.bill_id object.pk %}?{{ request.GET.url...who knows how many characters long it is.
It's hard to tell whether they optimised the app, deleted a ton of noise, or just merged everything into those 300-character-long megalines.
> These "we cut 70% of our codebase" claims always make me laugh.
There's also a slide in my talk that presents how many JS dependencies we dropped, while not adding any new Python. Retrospectively, that is a much more impressive achievement.
... but the whole social movement of "back to the backend" is about getting rid of the client-side application as a separate component
of course it (should) lead to a lot less code! at the cost of completely foregoing most of the capabilities offered by having a well-defined API and a separate client-side application
... and of course this is happening as over the last ~2 decades we mostly figured out that most of that amazing freedom on the client-side does not worth it
... most clients are dumb devices (crawlers), most "interactions" are primitive read-only ones, and having a fast and simple site is a virtue (or at least it makes economic sense to shunt almost all complexity to the server-side, as we have fast and very capable PoPs close to users)
> ... and of course this is happening as over the last ~2 decades we mostly figured out that most of that amazing freedom on the client-side does not worth it
It's not that, at least in my opinion, it's that we love (what we perceive as) new and shiny things. For the last ten years with Angular, React, Vue et al., new waves of developers have forgotten that you can output stuff directly from the server to the browser outside of "APIs".
This implementation is "dumb" to me. Feels like the only innovation is using SSE, otherwise it's a `selector.onClick(() => {selector.outerHTML = await (fetch(endpoint)).json()});`. That's most of the functionality right there. You can even use native HTML element attributes instead of doing .onClick https://developer.mozilla.org/en-US/docs/Web/API/Element/cli....
Cool how do exponential back off, make sure that it auto connects on tab visibility changes, make sure when you replace stuff it keeps the same selection. I'm sure if you had enough of these you'll end up with 10 kilobyte shim
Ok? Not sure what's your point. I'm not saying the package is bloated or anything. I'm saying it's a very simple functionality that was considered an anti-pattern when Angular and React were coming up.
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.
I’ve not tried Datastar in anger but I have tried HTMX after all the hype and it quickly became unmaintainable.
My dream was having a Go server churning out all this hypermedia and I could swerve using a frontend framework, but I quickly found the Go code I was writing was rigid and convoluted. It just wasn’t nice. In fact it’s the only time I’ve had an evening coding session and forgotten what the code was doing on the same evening I started.
I’m having a completely opposite experience with Elixir and Phoenix. That feels like an end to end fluid experience without excessive cognitive load.
BEAM + Elixir + Phoenix feels like I can control a whole system from the CPU processes (almost) up to the UI elements on a remote user’s screen, all in one easy-ish-to-understand system and language.
Granted, I’ve only used it for smaller projects, but I can almost feel my brain relax as the JS fades out, and suddenly making web apps is super fun again.
The preferred pattern addresses your concern about scattered logic: a single long-lived SSE endpoint that "owns" the user's view of the app. That endpoint updates their field of view as appropriate - very much inspired by game dev's immediate mode rendering.
An interesting characteristic of Datastar: it's very opinionated about the shape of your backend but extremely unopinionated about how you implement that shape.
My understanding is Turbo is more aligned with htmx. Common practice in Turbo are generally patterns of last resort in Datastar.
e.g. Datastar prescribes a single long lived SSE endpoint that owns the state for the currently connected user's view of the world / app, while common practice in Turbo is to have many small endpoints that return a fragment of html when requested by the client.
I share your feelings. If you like React and its trade-offs, and you're comfortable using it (based on various HN discussion the easiest sign is that you're able to understand the concept of hooks and you don't have the need to wrongly yell everywhere how it's a bad abstraction :D), you can forget about Datastar or HTMAX.
For context, I worked with large React codebases, contributed to various ecosystem libraries (a few bigger ones: react-redux, styled components, react-router). So, I'm pretty comfortable with hooks, but I still make mistakes with them if React isn't in my daily routine (different day job now, only use React occasionally for some pet projects).
I've also onboard interns and juniors onto React codebase, and there's things about React that only really make sense if you're more old-school and know how different types behave to understand why certain things are necessary.
I remember explaining to an intern why passing an inlined object as a prop was causing the component to rerender, and they asked whether that's a codebase smell... That question kinda shocked me because to me it was obvious why this happens, but it's not even a React issue directly. Howeve the fix is to write "un-javascripty" code in React. So this persons intro to JS is React and their whole understanding of JS is weirdly anchored around React now.
So I totally understand the critique of hooks. They just don't seem to be in the spirit of the language, but do work really well in spite of the language.
As someone who survived the early JS wilderness, then found refuge in jQuery, and after trying a bunch of frameworks and libraries, finally settled on React: I think React is great, but objectively parts of it suck, and it's not entirl its fault
> and they asked whether that's a codebase smell...
Something that's been an issue with our most junior dev, he's heard a lot of terminology but never really learned what some of those terms mean, so he'll use them in ways that don't really make sense. Your example here is just the kind of thing I'd expect from him, if he's heard the phrase "code smell" but assumed something incorrect about what it meant and never actually looked up what it means.
It is possible your co-worker was asking you this the other way around - that they'd just learned the term and were trying to understand it rather than apply it.
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.
If I understand the code for these correctly though, you're not actually doing the "idiomatic" datastar things as the article describes? No diffing/patching individual elements, just rerender the entire page?
Tbh that mental model seems so much simpler than any or all of the other datastar examples I see with convoluted client state tracking from the server.
Would you build complex apps this way as well? I'd assume this simple approach only works because the UI being rendered is also relatively simple. Is there any content I can read around doing this "immediate mode" approach when the user is navigating across very different pages with possibly complicated widget states needing to be tracked to rerender correctly?
I mean Datastar is pretty flexible. I'd say CQRS is pretty idiomatic if you want to do multiplayer/realtime stuff. As you mentioned, once you've se that up, the mental model is much simpler. That being said the initial set up is more involved than req/response Datastar.
Yes we are building complex accounting software at work with Datastar and use the same model. "Real UI" is often more complex, but a lot less heavy less divs, less data, fewer concurrent users, etc compared to these demos. Checkboxes are a lot more div dense than a list of rows for example.
I don't use anything from pro and I use datastar at work. I do believe in making open source maintainable though so bought the license.
The pro stuff is mostly a collection of foot guns you shouldn't use and are a support burden for the core team. In some niche corporate context they are useful.
You can also implement your own plugins with the same functionality if you want it's just going to cost you time in instead of money.
I find devs complaining about paying for things never gets old. A one off life time license? How scandalous! Sustainable open source? Disgusting. Oh a proprietary AI model that is built on others work without their consent and steals my data? Only 100$ a month? Take my money!
Genuine question from an "old school" web developer: can someone please give me an example of where these new frontend technologies are actually better than just using HTML, CSS, and vanilla JavaScript or jQuery?
I have honestly yet to see an example where using something like React doesn't just look like it's adding unnecessary complexity.
These tools are absolutely nothing like React. Take a look at what htmx does, which is even simpler from a spec standpoint. There are actual on-going efforts to get it into the actual HTML spec. htmx and the like are basically built for us old-skool types (and thankfully many youngins are catching on).
One of the big promises of HTMX is that the client doesn't have to understand the structure of the returned data since it's pre-compiled to the presentation layer, and it feels like this violates that quite heavily since now the calling page needs to know the IDs and semantics of the different elements the server will return.
This isn't really a criticism of Datastar, though: I think the popularity of OOB in HTMX indicates that the pure form of this is too idealistic for a lot of real-world cases. But it would be nice if we could come up with a design that gives the best of both worlds.
Basically, the HTMX code says: "when this span is clicked, fetch /rebuild/status-button, extract the #rebuild-bundle-status-button element from the returned HTML, and replace the existing #rebuild-bundle-status-button element with it".
The Datastar code instead says: "when this span is clicked, fetch /rebuild/status-button and do whatever it says". Then, it's /rebuild/status-button's responsibility to provide the "swap the existing #rebuild-bundle-status-button element with this new one" instruction.
If /rebuild/status-button returns a bunch of elements with IDs, Datastar implicitly interprets that as a bunch of "swap the existing element with this new one" instructions.
This makes the resulting code look a bit simpler since you don't need to explicitly specify the "target", "select", or "swap" parts. You just need to put IDs on the elements and Datastar's default behavior does what you want (in this case).
Note that for this example you can get the same behavior (assuming the endpoint hit isn't using using SSE, which IMO Datastar over emphasizes) in HTMX via a combination of formatting your response body correctly and the response headers. It isn't the way things are typically done in HTMX for Locality of Behavior reasons, not because it's impossible.
Datastar keeps the logic in the backend. Just like we used to do with basic html pages where you make a request, server returns html and your browser renders it.
With Datastar, you are essentially doing kind of PWA where you load the page once and then as you interact with it, it keeps making backend requests and render desired changes, instead of reloading the entire page. But yo uare getting back snippets of HTML so the browser does not have to do much except rendering itself.
This also means the state is back in the backend as well, unlike with SPA for example.
So again, Datastar goes back to the old request-response HTML model, which is perfectly fine, valid and tried, but it also allows you to have dynamic rendering, like you would have with JavaScript.
In other words, the front-end is purely visual and all the logic is delegated back to the backend server.
This essentially is all about thin client vs smart client where we constantly move between these paradigms where we move logic from backend to the frontend and then we swing back and move the logic from the frontend to the backend.
We started with thin clients as computers did not have sufficient computing power back in the day, so backend servers did most of the heavy lifting while the thin clients very little(essentially they just render the ready-made information). That changed over time and as computers got more capable, we moved more logic to the frontend and it allowed us to provide faster interaction as we no longer had to wait for the server to return response for every interaction. This is why there is so much JavaScript today, why we have SPAs and state on the client.
So Datastar essentially gives us a good alternative to choose whether we want to process more data on the backend or on the frontend, whilst also retaining the dynamic frontend and it is not just a basic request-response where every page has to re-render and where we have to wait for request to finish. We can do this in parallel and still have the impression if a "live" page.
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.
During 2015-2018 I was not working on FE and when I started again everyone was using js frameworks ditching MVC, aspx and similar.
Now I again not working on the FE for 3 years and it seems everybody is going back to sending HTML from server.
I am not saying it is wrong. Just it is abit funny looking from perspective how pendulum is going now the other way.
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.
1. If the element is out-of-band, it MUST have `htmx-swap-oob="true"` in it, or it may be discarded / cause unexpected results
2. If the element is not out-of-band, it MUST NOT have `htmx-swap-oob="true"` in it, or it may be ignored.
This makes it hard to use the same server-side HTML rendering code for for a component that may show up either OOB or not; you end up having to pass down "isOob" flags, which is ugly and annoying.
I think Datastar has the better approach here with making OOB the default. I suspect HTMX's non-OOB default makes more sense for very simple requirements where you simply replace the part of the DOM from which the action was triggered. But personally, situations where OOB is necessary is more typical.
Interestingly, elements sent via the HTMX websocket extension [1] do use OOB by default.
I like the alpine-ajax API. You specify one or more targets and it swaps each of those elements. No default case or OOB, just keeping it uniform instead.
As for Datastar, all the signal and state stuff seems to me like a step in the wrong direction.
Despite the “just figure it out” style of documentation, I still believe Hotwire + Stimulus (optional honestly) to be the best iteration of the low-JavaScript reactivity bunch.
Htmx gives me bad vibes from having tons of logic _in_ your html. Datastar seems better in this respect but has limitations Hotwire long since solved.
That is not at all what HTMX does.
HTMX is "If the user clicks[1] here, fetch some html from the server and display it". HTMX doesn't put logic in your HTML.
I was tired of writing backend APIs with the only purpose that they get consumed by the same app's frontend (typically React). Leading to boilerplate code both backend side (provide APIs) and frontend side (consume APIs: fetch, cache, propagate, etc.).
Now I am running 3 different apps in productions for which I no longer write APIs. I only define states and state updates in Python. The frontend code is written in Python, too, and auto-transpiled into a React app. The latter keeping its states and views automagically in sync with the backend. I am only 6 months into Reflex so far, but so far it's been mostly a joy. Of course you've got to learn a few but important details such as state dependencies and proper state caching, but the upsides of Reflex are a big win for my team and me. We write less code and ship faster.
I run 6 React apps in prod, which used to consume APIs written with Falcon, Django and FastAPI. Since 2 years ago, they all consume APIs from PostgREST. I define SQL views for the tables I want to expose, and optionally a bunch of SQL grants and SQL policies on the tables if I have different roles/permissions in the app, and PostgREST automatically transforms the views into endpoints, adds all the CRUD + UPSERT capabilities, handles the authorization, filtering, grouping, ordering, insert returning, pagination, and so on.
I checked this out because it sounded cool and I was not expecting to see a landing page about AI and "Contact sales" for pricing info if you don't want your work to be data-mined. 2025, man. Sigh.
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.
I like Hotwire but I admit its a bit confusing to get started with and the docs dont help.
Form submits + redirects are a bit weird, you cant really make the server "break out" of a frame during a redirect if the form was submitted from inside a frame (there are workarounds, see https://github.com/hotwired/turbo/issues/257).
> 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.
Basically every single web page on the modern web has the server returning JS that the client then executes. I think you should clarify what's dangerous about the specific pattern you're thinking of that isn't already intrinsic to the web as a whole.
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!
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're accusing the poster of shilling. That's against site rules, but aside from that it makes no sense in this context -- the post talks about the advantages of HTMX versus Datastar.
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 have never heard of it, but I loved it reading a bit of the docs, especially as someone who doesn't like the whole front end circus! I was planning to teach myself svelte but it seems this one is more than enough!
I had a SaaS project last year with massive HTMX code base. Code was big and pain was even bigger. A few months back I attempted to convert parts of it to DataStar but the introduction of premature "DataStar Pro" and putting pretty basic but essential utilities behind the paywall killed the vibe. I scrapped the idea and wouldn't go near it.
Having just watched the Vite documentary both HTMX and DataStar have a higher order mission to challenge dominant incumbent JS frameworks like React/NextJS. HTMX is struggling and in my opinion Datastar is DOA!
Win the adoption, win the narrative then figure out cashing in. People behind Vite won the JS bundling race, they now have a new company Void(0) and raised venture money. NextJS solved major React pain points, gave it away for free and built a multi-billion$ infrastructure to host it.
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...
Yup, which is why I never understand why people keep making this criticism that could have been avoided by just reading the docs a little bit more or even asking on the htmx Discord.
Datastar author here, all this happened while I was asleep so yeah I'm really good at reading the system in my dreams. I must be actually AGI and totally not a real person. Highly suspect
That's kind of the point. Don't throw out the new modern features of the browser but use them with fine-grainer activity. Otherwise most of the state lives in the back end. It's really just getting back to normalcy
"Why I switched from HTMX to Datastar" -> Why I never switched to HTMX, because there will always be something better, and for that there also will be something better.
Or the then backwards-incompatible HTMX v2 will give it the rest, leaving all the obsolete codebase. It's the circle of life.
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"
>At this point why not just bite the bullet and go back to the old days of php serving html.
Going back to it is the point. HTMX lets you do that while still having that button refresh just a part of the page, instead of reloading the whole page.
It's AJAX with a syntax that frees you from JS and manual DOM manipulation.
I fairly recently developed an app in PHP, in the classic style, without frameworks.
It provided me with stuff I remembered, the $annoyance $of $variable $prefixes, the wonky syntax, and a type system that makes JS look amazing -- but it still didn't make me scream in pain and confusion like React. Getting the app done was way quicker than if any JS framework was involved.
Having two separate but tightly integrated apps is annoying. HTMX or any other classic web-dev approaches like PHP and Django make you have one app, the backend. The frontend is the result of executing the backend.
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 guess one thing that might be potentially problematic is that if you update the server while someone has the page still open you need to match their original templates version and not the new (potentially incompatible) one
> 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.
> ...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.
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.
I attacked your ideas cause there were going to be a long term loss to you and your users. If you want people to tell you want to here go watch tech devs on youtube.
You are wrong. A few months ago before the Pro announcement I was exploring HTMX, Unpoly and Datastar was the new thing. It looked cool - especially the demo of a game like thingy. But the page was kind of unresponsive still. This is a common pattern among even Liveview pages where the server roundtrip is still a thing unlike in a typical SPA despite it beings using SSE it's still not local React/Svelte/Vue app experience. That's why you will end up moving more and more parts to Alpine from Livewire/Liveview .... anyway.... I asked the guys on the Discord channel for Datastar how would I do the spa like page navigation between pages. And he got irritated - probably because this wasn't the first time somebody asked that - and told me that I don't get Datastar that that is wrong, Datastar don't care about that. But it was in a such weird aggressive way , he was mociking me, my intelligence and used very childish ad hominem attacks. I then left. And ok, he doesn't like the spa navigation or datastar doesn't care with that at all, but the way he addressed via an attack on me was super negative. You don't call people idiots because they would like from Datastar a functionality that is common in HTMX, Unpoly, Liveview or Livewire. Perhaps they have something like that - or in the PRO version, but I don't care. If you want realtime go with Phoenix Liveview instead - their community is much more friendly and mature.
We don't shy away from telling you your ideas are terrible. Being mature is caring about your code and your users. You were VERY clearly making bad technically reasons and we pushed back. We aggressively care about the details and if you don't then please go use Liveview. We aren't trying to win popularity contests. Show code and prove your point or continue to clutch your pearls
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!
The article stated that he no longer needs eventing to update other parts of the page, he can send down everything at once. So, I guess that is much less complex. Granted, eventing and pulling something down later could be a better approach depending on the circumstance.
"Alpine or Stimulus features were natively included in htmx"
I'm contemplating using HTMX in a personal project - do you know if there are any resources out there explaining why you might also need other libraries like Alpine or Stimulus?
They're for client-side only features. Think toggling CSS classes, updating the index on a slider- you ideally don't want to have to hit the server for that
Thanks - I was having a quick read of the documentation for those projects and that makes perfect sense.
I'm really just starting with htmx but came across datastar yesterday. This is a great comparison and is confirming some of my impressions, so thanks! I'll still look a bit more but if the main thing is that it's naively adding Alpine or Stimulus then datastar is not for me.
its not like that at all, read the guide and build something before passing judgement
:pointing-up-emoji:
> I'll still look a bit more
> 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'm not too strong in frontend, but wouldn't this make for a lighter, faster front end? Especially added up over very many elements?
100%. Datastar is just make HTML spec support reactive expression in data-* attributes, that's it. You will become stronger at web cause it just gets out of your way
Reminds me a bit of the Seaside framework in Pharo. A lot of the things I programmed in Pharo at my previous employer was a lot of back and forth between front-end and back-end, because the back-end was managing the front-end state. For B2B apps that don't have a lot of latency requirements, etc., I'd say it's better. For high scalable B2C apps though? No.
Could you expand on why you think it (back-end managing the front-end's state) is better in the scenarios that you do?
Edit - rather than spam with multiple thank you comments, I'll say here to current and potential future repliers: thanks!
Not GP, but I would say, it’s the same reason someone would use React. If you keep you state in a single place, the rest of the app can become very functional and pure. You receive data and tranform it (or render it). The actual business logic that manipulate the state can be contained in a single place.
This reduces a lot of accidental complexities. If done well, you only need to care about the programming language and some core libraries. Everything else becomes orthogonal of each other so cost of changes is greatly reduced.
I would imagine the same arguments for Smalltalk like live coding and an IDE within your production application. So you get some overlap with things like Phoenix LiveView, but more smalltalk-y.
I assume it had backend scaling issues, but usually backend scaling is over-stated and over-engineered, meanwhile news sites load 10+ MB of javascript.
I recently read this: https://drshapeless.com/blog/posts/htmx,-datastar,-greedy-de...
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.
Same for me...
I had been tracking Datastar for months, waiting for the 1.0.0 release.
But my enthusiasm for Datastar has now evaporated. I've been bitten by the open-source-but-not-really bait and switch too many times before.
As someone who wants to write open source but needs to be able to capture some financial value from doing that to be able to make it sustainable, what model do you prefer?
My current thoughts lean towards a fully functional open source product with a HashiCorp style BSL and commercial licensing for teams above a size threshold.
I think the open core model is fine, and the most financially sustainable. Just be up front about it from day 1. I don't think the honor system for licensing will get you the results you're wanting.
Some solo dev projects are used as a platform to sell books, training, ads, speaking engagement, consulting, and development.
Sell support.
I can't imagine that works very well for relatively small, simple, functional or intuitive projects though. Incentives wise, is it possible to sell reverse support: extracting payment for all the times the product works so well that support isn't needed?
Selling support can be rough. I talked with the developer of PyMol.
Many corporations wouldn't buy licenses and those that would pay for support wanted support for hardware that was 2 or 3 generations old.
Gentle reminder: please encourage your corporation to pay for open source support whenever possible.
That doesn't work. My day job is at scenario working on NATS and I can tell you 99.9% of people don't pay for support
As a NATS user, I can say that's mostly because it just works and when it doesn't it's pretty easy to figure out :)
yep, and you'd think someone that has seen that would pick a different model... idk, ngmi
Maintainers need a way to maintain during the day - not just evenings and weekends. Otherwise it eventually dies.
Does HTMX have a pro version? Is it dead?
Far from dead. Usage is growing.
HTMX is a single htmx.js file with like 4000 lines of pretty clearly written code.
It purports to - and I think succeeds - in adding a couple of missing hypermedia features to HTML.
It's not a "framework" - good
It's not serverside - good
Need to add a feature? Just edit htmx.js
Some people will get a fit once they find out it's JS, and not TypeScript.
Yes look at the active issues on GitHub. There's hundreds and some going back years with no traction.
source is MIT, do what you want. The team found certain plugins to be anti-patterns and support burdens. You can find the old plugins in the repo source, feel free to fork from there!
[dead]
I know the projects/specifics are completely different but this immediately reminded me of Meteor.js from back in the day
https://news.ycombinator.com/item?id=9569799
Technically very different but emotionally yes very the same but a lot simpler
It's good to know -- having replace-url functionality behind the paywall is likely to be a deal-killer; I can't help but think that this "freemium" model is really going to kill datastar's prospects for taking off; at best it's likely to result in a fork which ends up subsuming the original project.
That said, the attitude of the guy in the article is really messed up. Saying "fuck you" to someone who gave you something amazing for free, because he's not giving you as much as you want for free -- it's entitled to a toxic degree, and poisons the well for anyone else who may want to do something open-source.
It's more like the mouse saying fuck you to the trap holding the cheese. It's not that the mouse isn't grateful for the free cheese. It's just the mouse understands the surrounding context.
The freemium model of everything makes me skeptical and reluctant to buy too much into many things.
Bit like Pydantic. It's a JSON parsing library at the end of the day, and now suddenly that's got a corporate backer and they've built a new thing
Polars is similar. It's a faster Pandas and now suddenly it's no longer the same prospect.
FastAPI the same. That one I find even more egregious since it's effectively Starlette + Pydantic.
Edit: Add Plotly/Dash, SQLAlchemy, Streamlit to that list.
I am totally skeptic about freemium too. Are FastAPI and SQLAlchemy freemium too? I didn't know that. Can you share more info, please?
There's now a "FastAPI Cloud" product that the author is working on.
SQLAlchemy just has paid for support, I shouldn't have included it with the others, I must have confused it with something else.
its a 501c3 with no shares. please tell me how its the same?
I referenced the article with hesitation for the same reason, don't think the position the critique takes is great.
Interestingly, this article pops up first page if you search "htmx vs datastar".
> Saying "fuck you" to someone who gave you something amazing for free, because he's not giving you as much as you want for free
I don't have a problem, on principle, with paywalling new features. I don't like it, but I don't think it's bad behaviour.
Putting up a paywall around features that were previously free, however, I do take issue with. It's deceptive and it's not common practice. It tricks people into becoming invested and then holds hostage the features that they've become invested in using. Frankly, fuck that.
Then go fork earlier in the repo and support it yourself!
Fuck me buddy, no fuck you GUY. I'm not your guy pal.
On the latter point, couldn't disagree more. He's saying "fuck you" to the product, not the person, and unilaterally removing extant features to paywall them imo is poisoning the well far more than a simple FU to a developer ever could?
We didn't remove the features, if you want to use the old ones they're still there in the repo. We just didn't want to support the old way of doing them when we actively tell people not to use them. If you're going to be a support burden going forward we want you to have skin in the game if not cool do it yourself no one's going to get mad at you
Deprecating a feature and replacing it with a paywalled version is imo a distinction without a difference.
You're of course free to do it, just as I'm free continue to use other products which do not do this.
Fair enough, but the use of coarse language can also impair the underlying point. i.e. the shock value can derail the reader.
For such reasons, The Economist style guide advises against using fancy language when simpler language will suffice.
https://en.wikipedia.org/wiki/Tone_policing
I don't really have much of a response beyond this.
err, fuck is simple
So let's say you wanted to use data-animate but on the free edition, would you just add some JS/CSS glue logic to make it work?
yup, why not. css animations go brrrr. and anime.js is a great library.
It's also pretty shady that no mention is made of Datastar Pro on the home page [1]. You might well be well on the way to integrating Datastar into your website before you stumble across the Pro edition, which is only mentioned on the side bar of the reference page [2].
[1]: https://data-star.dev/ [2]: https://data-star.dev/reference/datastar_pro#attributes
Isn't that only a problem if it advertised pro features there without mentioning the fact that they're paid? If it didn't then you could just be happy with the free features, no?
I'd expect it to make it explicit this is a freemium product, with free features and paid features. Nothing is given on the home page to indicate as such.
If they aren’t leading to expect that they have the paid features for free, how is offering them for money any different from just not offering those features at all?
It’s not like your exiting use cases stop working past 10 users or something.
Yikes.
I'm not opposed to open source projects placing features that realistically only large/enterprise users would use behind a paywall, i.e. the open core model. When done fairly, I think this is the most sustainable way to build a business around OSS[1]. I even think that subscriptions to such features are a fair way of making the project viable long-term.
But if the project already had features that people relied on, removing them and forcing them to pay to get them back is a shitty move. The right approach would've been to keep every existing feature free, and only commercialize additional features that meet the above criteria.
Now, I can't say whether what they paywalled is a niche/pro feature or not. But I can understand why existing users wouldn't be happy about it.
[1]: https://news.ycombinator.com/item?id=45537750
Yeah, fuck the Datastar author. He is the fucking worst. Definitely should use HTMX!
Yeah, but as the HTMX author said, HTMX sucks! Definitely should use Datastar!
fuck, you got me there. thanks obama
I find it much more interesting to read from people who do programming as a hobby.
They focus on the practical solutions much more than on the typical bikeshedding.
"Bikeshedding" means debating over aspects that don't matter (much; i.e, color of the bike shed), the linked blog post isn't about asthetic changes.
Nor was my intent to label any of the linked blogs as such.
My intent was to say that hobbyists have a different, refreshing approach to programming and it's technologies that I appreciate.
These "we cut 70% of our codebase" claims always make me laugh. We have no idea what was going on in that original codebase. The talk literally shows severely cursed lines stretching to the moon like:
<div hx-get="{% url 'web-step-discussion-items-special-counters' object.bill_id object.pk %}?{{ request.GET.url...who knows how many characters long it is.
It's hard to tell whether they optimised the app, deleted a ton of noise, or just merged everything into those 300-character-long megalines.
> These "we cut 70% of our codebase" claims always make me laugh.
There's also a slide in my talk that presents how many JS dependencies we dropped, while not adding any new Python. Retrospectively, that is a much more impressive achievement.
... but the whole social movement of "back to the backend" is about getting rid of the client-side application as a separate component
of course it (should) lead to a lot less code! at the cost of completely foregoing most of the capabilities offered by having a well-defined API and a separate client-side application
... and of course this is happening as over the last ~2 decades we mostly figured out that most of that amazing freedom on the client-side does not worth it
... most clients are dumb devices (crawlers), most "interactions" are primitive read-only ones, and having a fast and simple site is a virtue (or at least it makes economic sense to shunt almost all complexity to the server-side, as we have fast and very capable PoPs close to users)
> ... and of course this is happening as over the last ~2 decades we mostly figured out that most of that amazing freedom on the client-side does not worth it
It's not that, at least in my opinion, it's that we love (what we perceive as) new and shiny things. For the last ten years with Angular, React, Vue et al., new waves of developers have forgotten that you can output stuff directly from the server to the browser outside of "APIs".
This implementation is "dumb" to me. Feels like the only innovation is using SSE, otherwise it's a `selector.onClick(() => {selector.outerHTML = await (fetch(endpoint)).json()});`. That's most of the functionality right there. You can even use native HTML element attributes instead of doing .onClick https://developer.mozilla.org/en-US/docs/Web/API/Element/cli....
I really don't see any benefit to using this.
Cool how do exponential back off, make sure that it auto connects on tab visibility changes, make sure when you replace stuff it keeps the same selection. I'm sure if you had enough of these you'll end up with 10 kilobyte shim
Ok? Not sure what's your point. I'm not saying the package is bloated or anything. I'm saying it's a very simple functionality that was considered an anti-pattern when Angular and React were coming up.
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.
I’ve not tried Datastar in anger but I have tried HTMX after all the hype and it quickly became unmaintainable.
My dream was having a Go server churning out all this hypermedia and I could swerve using a frontend framework, but I quickly found the Go code I was writing was rigid and convoluted. It just wasn’t nice. In fact it’s the only time I’ve had an evening coding session and forgotten what the code was doing on the same evening I started.
I’m having a completely opposite experience with Elixir and Phoenix. That feels like an end to end fluid experience without excessive cognitive load.
BEAM + Elixir + Phoenix feels like I can control a whole system from the CPU processes (almost) up to the UI elements on a remote user’s screen, all in one easy-ish-to-understand system and language.
Granted, I’ve only used it for smaller projects, but I can almost feel my brain relax as the JS fades out, and suddenly making web apps is super fun again.
Did you use templ [1] for server side templating? It supports something called fragments, which may help with HTMX [2].
[1]: https://templ.guide/
[2]: https://templ.guide/syntax-and-usage/fragments
The standard library html/template also has that in the form of blocks.
The preferred pattern addresses your concern about scattered logic: a single long-lived SSE endpoint that "owns" the user's view of the app. That endpoint updates their field of view as appropriate - very much inspired by game dev's immediate mode rendering.
I've a tutorial that demonstrates this with Nushell as the backend: https://datastar-todomvc.cross.stream
An interesting characteristic of Datastar: it's very opinionated about the shape of your backend but extremely unopinionated about how you implement that shape.
> if I had to go back to something lighter, I'd just go back to all in SSR with Rails
FWIW, default config of Rails include Turbo nowadays, which seems quite similar to Datastar in concept.
My understanding is Turbo is more aligned with htmx. Common practice in Turbo are generally patterns of last resort in Datastar.
e.g. Datastar prescribes a single long lived SSE endpoint that owns the state for the currently connected user's view of the world / app, while common practice in Turbo is to have many small endpoints that return a fragment of html when requested by the client.
I share your feelings. If you like React and its trade-offs, and you're comfortable using it (based on various HN discussion the easiest sign is that you're able to understand the concept of hooks and you don't have the need to wrongly yell everywhere how it's a bad abstraction :D), you can forget about Datastar or HTMAX.
For context, I worked with large React codebases, contributed to various ecosystem libraries (a few bigger ones: react-redux, styled components, react-router). So, I'm pretty comfortable with hooks, but I still make mistakes with them if React isn't in my daily routine (different day job now, only use React occasionally for some pet projects).
I've also onboard interns and juniors onto React codebase, and there's things about React that only really make sense if you're more old-school and know how different types behave to understand why certain things are necessary.
I remember explaining to an intern why passing an inlined object as a prop was causing the component to rerender, and they asked whether that's a codebase smell... That question kinda shocked me because to me it was obvious why this happens, but it's not even a React issue directly. Howeve the fix is to write "un-javascripty" code in React. So this persons intro to JS is React and their whole understanding of JS is weirdly anchored around React now.
So I totally understand the critique of hooks. They just don't seem to be in the spirit of the language, but do work really well in spite of the language.
As someone who survived the early JS wilderness, then found refuge in jQuery, and after trying a bunch of frameworks and libraries, finally settled on React: I think React is great, but objectively parts of it suck, and it's not entirl its fault
> and they asked whether that's a codebase smell...
Something that's been an issue with our most junior dev, he's heard a lot of terminology but never really learned what some of those terms mean, so he'll use them in ways that don't really make sense. Your example here is just the kind of thing I'd expect from him, if he's heard the phrase "code smell" but assumed something incorrect about what it meant and never actually looked up what it means.
It is possible your co-worker was asking you this the other way around - that they'd just learned the term and were trying to understand it rather than apply it.
Fantastic write up!
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.
If I understand the code for these correctly though, you're not actually doing the "idiomatic" datastar things as the article describes? No diffing/patching individual elements, just rerender the entire page?
Tbh that mental model seems so much simpler than any or all of the other datastar examples I see with convoluted client state tracking from the server.
Would you build complex apps this way as well? I'd assume this simple approach only works because the UI being rendered is also relatively simple. Is there any content I can read around doing this "immediate mode" approach when the user is navigating across very different pages with possibly complicated widget states needing to be tracked to rerender correctly?
I mean Datastar is pretty flexible. I'd say CQRS is pretty idiomatic if you want to do multiplayer/realtime stuff. As you mentioned, once you've se that up, the mental model is much simpler. That being said the initial set up is more involved than req/response Datastar.
Yes we are building complex accounting software at work with Datastar and use the same model. "Real UI" is often more complex, but a lot less heavy less divs, less data, fewer concurrent users, etc compared to these demos. Checkboxes are a lot more div dense than a list of rows for example.
> On both the checkboxes/cells examples there's adaptive view rendering so you can zoom out a fair bit.
how do you zoom out?
Also, even with your examples, wouldn't data-replace-url be a nice-to-have to auto update the url with current coordinates, e.g. ?x=123&y=456
Currently zoom the page web cmd+/-. At some point I'll add buttons and to proper quantised views.
> think you need any of the PRO features
Pro features ? Now I see - it is open core, with a $299 license. I'll pass.
Good for you!
I don't use anything from pro and I use datastar at work. I do believe in making open source maintainable though so bought the license.
The pro stuff is mostly a collection of foot guns you shouldn't use and are a support burden for the core team. In some niche corporate context they are useful.
You can also implement your own plugins with the same functionality if you want it's just going to cost you time in instead of money.
I find devs complaining about paying for things never gets old. A one off life time license? How scandalous! Sustainable open source? Disgusting. Oh a proprietary AI model that is built on others work without their consent and steals my data? Only 100$ a month? Take my money!
Genuine question from an "old school" web developer: can someone please give me an example of where these new frontend technologies are actually better than just using HTML, CSS, and vanilla JavaScript or jQuery?
I have honestly yet to see an example where using something like React doesn't just look like it's adding unnecessary complexity.
These tools are absolutely nothing like React. Take a look at what htmx does, which is even simpler from a spec standpoint. There are actual on-going efforts to get it into the actual HTML spec. htmx and the like are basically built for us old-skool types (and thankfully many youngins are catching on).
One of the big promises of HTMX is that the client doesn't have to understand the structure of the returned data since it's pre-compiled to the presentation layer, and it feels like this violates that quite heavily since now the calling page needs to know the IDs and semantics of the different elements the server will return.
This isn't really a criticism of Datastar, though: I think the popularity of OOB in HTMX indicates that the pure form of this is too idealistic for a lot of real-world cases. But it would be nice if we could come up with a design that gives the best of both worlds.
The calling page knows nothing, you do an action on the client, the server might return an update view of the entire page. That's it.
You send down the whole page on every change. The client just renders. It's immediate mode like in video games.
I don't understand the examples in this post. For example, how does:
<span hx-target="#rebuild-bundle-status-button" hx-select="#rebuild-bundle-status-button" hx-swap="outerHTML" hx-trigger="click" hx-get="/rebuild/status-button"></span>
Turn into:
<span data-on-click="@get('/rebuild/status-button')"></span>
The other examples are even more confusing. In the end, I don't understand why the author switched from HTMX to Datastar.
Basically, the HTMX code says: "when this span is clicked, fetch /rebuild/status-button, extract the #rebuild-bundle-status-button element from the returned HTML, and replace the existing #rebuild-bundle-status-button element with it".
The Datastar code instead says: "when this span is clicked, fetch /rebuild/status-button and do whatever it says". Then, it's /rebuild/status-button's responsibility to provide the "swap the existing #rebuild-bundle-status-button element with this new one" instruction.
If /rebuild/status-button returns a bunch of elements with IDs, Datastar implicitly interprets that as a bunch of "swap the existing element with this new one" instructions.
This makes the resulting code look a bit simpler since you don't need to explicitly specify the "target", "select", or "swap" parts. You just need to put IDs on the elements and Datastar's default behavior does what you want (in this case).
I see, so the rendering logic is performed mostly on the back-end when using Datastar. It makes sense now, thanks.
Note that for this example you can get the same behavior (assuming the endpoint hit isn't using using SSE, which IMO Datastar over emphasizes) in HTMX via a combination of formatting your response body correctly and the response headers. It isn't the way things are typically done in HTMX for Locality of Behavior reasons, not because it's impossible.
It is quite simple.
Datastar keeps the logic in the backend. Just like we used to do with basic html pages where you make a request, server returns html and your browser renders it.
With Datastar, you are essentially doing kind of PWA where you load the page once and then as you interact with it, it keeps making backend requests and render desired changes, instead of reloading the entire page. But yo uare getting back snippets of HTML so the browser does not have to do much except rendering itself.
This also means the state is back in the backend as well, unlike with SPA for example.
So again, Datastar goes back to the old request-response HTML model, which is perfectly fine, valid and tried, but it also allows you to have dynamic rendering, like you would have with JavaScript.
In other words, the front-end is purely visual and all the logic is delegated back to the backend server.
This essentially is all about thin client vs smart client where we constantly move between these paradigms where we move logic from backend to the frontend and then we swing back and move the logic from the frontend to the backend.
We started with thin clients as computers did not have sufficient computing power back in the day, so backend servers did most of the heavy lifting while the thin clients very little(essentially they just render the ready-made information). That changed over time and as computers got more capable, we moved more logic to the frontend and it allowed us to provide faster interaction as we no longer had to wait for the server to return response for every interaction. This is why there is so much JavaScript today, why we have SPAs and state on the client.
So Datastar essentially gives us a good alternative to choose whether we want to process more data on the backend or on the frontend, whilst also retaining the dynamic frontend and it is not just a basic request-response where every page has to re-render and where we have to wait for request to finish. We can do this in parallel and still have the impression if a "live" page.
You explained nothing about how it actually works, seems an ai generated response
Also why is it a span instead of a button or link?
My guess is to demonstrate that any element can be interactive with D*, not just buttons or links.
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.
Let's have scattered bits of JS inject HTML instead, that'll fix it!
This. I feel wrong having endpoints that produce bits of HTML.
Servers sending HTML to the browser? Scandalous!
What has the world wide web come to?!
"Bits of HTML" was for a long time so common and normal it has its own term: HTML fragments.
Yes. It is OK for simple form submits but going to get annoying for anything that feels like an app.
There's a reason xpath and xls look they way they do - they're powerful, but not very comfortable :/
Reimplantations tend to simply some bits, but end up amassing complexities in various corners...
Ironically given the topic is hypermedia, the article doesn't link to the Datastar website. Here it is:
https://data-star.dev/
During 2015-2018 I was not working on FE and when I started again everyone was using js frameworks ditching MVC, aspx and similar. Now I again not working on the FE for 3 years and it seems everybody is going back to sending HTML from server.
I am not saying it is wrong. Just it is abit funny looking from perspective how pendulum is going now the other way.
What you see on hackernews/twitter is not what everybody is doing. Reality is that everyone is still rawdogging React in their legacy app
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.
One frustration I have with OOB elements in HTMX:
1. If the element is out-of-band, it MUST have `htmx-swap-oob="true"` in it, or it may be discarded / cause unexpected results
2. If the element is not out-of-band, it MUST NOT have `htmx-swap-oob="true"` in it, or it may be ignored.
This makes it hard to use the same server-side HTML rendering code for for a component that may show up either OOB or not; you end up having to pass down "isOob" flags, which is ugly and annoying.
I think Datastar has the better approach here with making OOB the default. I suspect HTMX's non-OOB default makes more sense for very simple requirements where you simply replace the part of the DOM from which the action was triggered. But personally, situations where OOB is necessary is more typical.
Interestingly, elements sent via the HTMX websocket extension [1] do use OOB by default.
[1]: https://htmx.org/extensions/ws/
"I was late to the hypermedia party" → very late indeed :)
The term was coined in 1965 by Ted Nelson in: https://dl.acm.org/doi/10.1145/800197.806036
Here's the exact sentence: "The hyperfilm-- a browsable or vari-sequenced movie-- is only one of the possible hypermedia that require our attention."
Both Datastar and HTMX try to lay claim to being "the one true hypermedia" just because they both are vaguely HTML-like. And they gladly misappropriate Ted Nelson, too: https://dmitriid.com/hypermedia-is-a-property-of-the-client
I like the alpine-ajax API. You specify one or more targets and it swaps each of those elements. No default case or OOB, just keeping it uniform instead.
As for Datastar, all the signal and state stuff seems to me like a step in the wrong direction.
I thought alpine ajax did OOB on any ids returned in a response.
Edit: right, as long as the element has x-sync on it, it will receive any OOB updates from any response.
Despite the “just figure it out” style of documentation, I still believe Hotwire + Stimulus (optional honestly) to be the best iteration of the low-JavaScript reactivity bunch.
Htmx gives me bad vibes from having tons of logic _in_ your html. Datastar seems better in this respect but has limitations Hotwire long since solved.
I'd love to hear what those limitations are as someone who came from Hotwire and moved to Datastar.
>Htmx gives me bad vibes from having tons of logic _in_ your html
Write some HTMX and you'll find that exactly the opposite is true
> tons of logic _in_ your html
That is not at all what HTMX does. HTMX is "If the user clicks[1] here, fetch some html from the server and display it". HTMX doesn't put logic in your HTML.
[1] or hovers or scrolls.
> They converted it from React to HTMX, cutting their codebase by almost 70% while significantly improving its capabilities.
Happy user of https://reflex.dev framework here.
I was tired of writing backend APIs with the only purpose that they get consumed by the same app's frontend (typically React). Leading to boilerplate code both backend side (provide APIs) and frontend side (consume APIs: fetch, cache, propagate, etc.).
Now I am running 3 different apps in productions for which I no longer write APIs. I only define states and state updates in Python. The frontend code is written in Python, too, and auto-transpiled into a React app. The latter keeping its states and views automagically in sync with the backend. I am only 6 months into Reflex so far, but so far it's been mostly a joy. Of course you've got to learn a few but important details such as state dependencies and proper state caching, but the upsides of Reflex are a big win for my team and me. We write less code and ship faster.
> I was tired of writing backend APIs with the only purpose that they get consumed by the same app's frontend
PostgREST is great for this: https://postgrest.org
I run 6 React apps in prod, which used to consume APIs written with Falcon, Django and FastAPI. Since 2 years ago, they all consume APIs from PostgREST. I define SQL views for the tables I want to expose, and optionally a bunch of SQL grants and SQL policies on the tables if I have different roles/permissions in the app, and PostgREST automatically transforms the views into endpoints, adds all the CRUD + UPSERT capabilities, handles the authorization, filtering, grouping, ordering, insert returning, pagination, and so on.
I checked this out because it sounded cool and I was not expecting to see a landing page about AI and "Contact sales" for pricing info if you don't want your work to be data-mined. 2025, man. Sigh.
Thanks for writing this up — some great insights!
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.
I like Hotwire but I admit its a bit confusing to get started with and the docs dont help. Form submits + redirects are a bit weird, you cant really make the server "break out" of a frame during a redirect if the form was submitted from inside a frame (there are workarounds, see https://github.com/hotwired/turbo/issues/257).
Also, custom actions [https://turbo.hotwired.dev/handbook/streams#custom-actions] are super powerfull, we use it to emmit browser events, update dom classes and attributes and so on, just be careful not to overuse it.
> 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.
Basically every single web page on the modern web has the server returning JS that the client then executes. I think you should clarify what's dangerous about the specific pattern you're thinking of that isn't already intrinsic to the web as a whole.
Datastar is like Htmx done even better.
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!
Read the grugs around the fire essay on the datastar site
Interesting write-up. Thanks.
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.
Isn’t HTMX fully open source? The comment you’re replying to has no outright praise for Datastar.
Must be part of HTMX' highly paid marketing team ;)
More like unpaid fan account. Anyway since HTMX is open source and free, it's easy to validate.
You're accusing the poster of shilling. That's against site rules, but aside from that it makes no sense in this context -- the post talks about the advantages of HTMX versus Datastar.
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)
https://netstack.fm/#episode-4
>datastar
I have never heard of it, but I loved it reading a bit of the docs, especially as someone who doesn't like the whole front end circus! I was planning to teach myself svelte but it seems this one is more than enough!
I had a SaaS project last year with massive HTMX code base. Code was big and pain was even bigger. A few months back I attempted to convert parts of it to DataStar but the introduction of premature "DataStar Pro" and putting pretty basic but essential utilities behind the paywall killed the vibe. I scrapped the idea and wouldn't go near it.
Having just watched the Vite documentary both HTMX and DataStar have a higher order mission to challenge dominant incumbent JS frameworks like React/NextJS. HTMX is struggling and in my opinion Datastar is DOA!
Win the adoption, win the narrative then figure out cashing in. People behind Vite won the JS bundling race, they now have a new company Void(0) and raised venture money. NextJS solved major React pain points, gave it away for free and built a multi-billion$ infrastructure to host it.
DOA! NGMI! Should just give up cause popular stuff is popular!
Sorry I care more about metrics and flamegraphs than what tech youtuber is faffing on about.
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...
I really like the ideas of hmx I just didn't find the actual implementation was complete enough to make performant apps... So I fixed it
HTMX can do all of that via OOB updates no?
Yup, which is why I never understand why people keep making this criticism that could have been avoided by just reading the docs a little bit more or even asking on the htmx Discord.
Yeah but then you don't get to write a cool blog post.
Sure, go try doing it and see what happens. Make sure to handle every verb, automatically connect, expo backoff, etc!
you miss the sse support (in htmx it's a plugin) and the reactivity part (like alpine).
if you think they work the same at all you haven't tried either
OOB is annoying in HTMX because you need to include hx-swap-oob attribute in every component you want to swap this way. In Datastar you just use id.
Two posts about one, lesser known, framework in the top two spots of HN.
It smells of rigging.
Datastar author here, all this happened while I was asleep so yeah I'm really good at reading the system in my dreams. I must be actually AGI and totally not a real person. Highly suspect
I'm really enjoying watching everything revert back to how it worked fifteen years ago
That's kind of the point. Don't throw out the new modern features of the browser but use them with fine-grainer activity. Otherwise most of the state lives in the back end. It's really just getting back to normalcy
"Why I switched from HTMX to Datastar" -> Why I never switched to HTMX, because there will always be something better, and for that there also will be something better.
Or the then backwards-incompatible HTMX v2 will give it the rest, leaving all the obsolete codebase. It's the circle of life.
Datastar's "Build reactive web apps that stand the test of time" tagline invites some skepticism.
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"
>At this point why not just bite the bullet and go back to the old days of php serving html.
Going back to it is the point. HTMX lets you do that while still having that button refresh just a part of the page, instead of reloading the whole page. It's AJAX with a syntax that frees you from JS and manual DOM manipulation.
I fairly recently developed an app in PHP, in the classic style, without frameworks. It provided me with stuff I remembered, the $annoyance $of $variable $prefixes, the wonky syntax, and a type system that makes JS look amazing -- but it still didn't make me scream in pain and confusion like React. Getting the app done was way quicker than if any JS framework was involved.
Having two separate but tightly integrated apps is annoying. HTMX or any other classic web-dev approaches like PHP and Django make you have one app, the backend. The frontend is the result of executing the backend.
Unironically PHP serving HTML wasn't that bad apparently
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.
Let's say I'm intrigued and on the fence.
I guess one thing that might be potentially problematic is that if you update the server while someone has the page still open you need to match their original templates version and not the new (potentially incompatible) one
Fair point, but we often do "fat morphs", i.e. patching the whole <body> element because this one isn't going anywhere.
I've heard good things about Unpoly too. Any experiences around here?
I find Unpoly easier to use than HTMX, their demo is second-to-none:
But absolutely terrible name.> 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.
Honestly, seeing the Datastar server-side snippets reminded me of writing RJS in Rails back in the day.
Everything old is new again.
Having the backend aware of the IDs in the HTML leads to pain. The HTMX way seems a lot simpler and Rails + Turbo has gone in that direction as well.
i don't know what the big deal is
with a REST API, the front and back ends need to agree on the JSON field names
with an HTML API for Datastar, the front and back ends need to agree on the element IDs
Really not a huge difference
I thought returning html from server was considered mixing up separation of concerns… oh well
partial html?
Returning html from a server is... just the WWW.
Last time I checked both have questionable shadow dom support if any
Use webcomponents all the time
Link to datastar portal: https://data-star.dev/essays/why_another_framework
> ...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.
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.
I attacked your ideas cause there were going to be a long term loss to you and your users. If you want people to tell you want to here go watch tech devs on youtube.
Excuse me but based on your post history I have to imagine it came out of nowhere
You are wrong. A few months ago before the Pro announcement I was exploring HTMX, Unpoly and Datastar was the new thing. It looked cool - especially the demo of a game like thingy. But the page was kind of unresponsive still. This is a common pattern among even Liveview pages where the server roundtrip is still a thing unlike in a typical SPA despite it beings using SSE it's still not local React/Svelte/Vue app experience. That's why you will end up moving more and more parts to Alpine from Livewire/Liveview .... anyway.... I asked the guys on the Discord channel for Datastar how would I do the spa like page navigation between pages. And he got irritated - probably because this wasn't the first time somebody asked that - and told me that I don't get Datastar that that is wrong, Datastar don't care about that. But it was in a such weird aggressive way , he was mociking me, my intelligence and used very childish ad hominem attacks. I then left. And ok, he doesn't like the spa navigation or datastar doesn't care with that at all, but the way he addressed via an attack on me was super negative. You don't call people idiots because they would like from Datastar a functionality that is common in HTMX, Unpoly, Liveview or Livewire. Perhaps they have something like that - or in the PRO version, but I don't care. If you want realtime go with Phoenix Liveview instead - their community is much more friendly and mature.
We don't shy away from telling you your ideas are terrible. Being mature is caring about your code and your users. You were VERY clearly making bad technically reasons and we pushed back. We aggressively care about the details and if you don't then please go use Liveview. We aren't trying to win popularity contests. Show code and prove your point or continue to clutch your pearls
Datastar author is the fucking worst!
from https://data-star.dev/: Simple. Fast. Light. No VCs. Coded by Hand
You have my sword!
[dead]
[dead]