Because Datastar Pro isn't FOSS, and speaking from a purely probabilistic and historical standpoint, your odds of getting rugpulled (in some form or another) might as well be 100%.
I can appreciate why people would have this perspective - I have been rugpulled a few times recently by thoroughly unscrupulous companies (Augment Code are trash humans).
But Datastar is different. The project is literally owned by a 501c3 non-profit. The devs have dayjobs and donate their spare time to this. Funds are for going to conferences or hosting their own
And 99% of the features/value that I mentioned is MIT licensed, and the "rugpulled" code is still available to easily port via the plugin API.
Yeah HTMX should rebrand as DATASTAR LIBRE.
> why use HTMX when it really seems like (a heavier) Datastar-lite?
The reason to use htmx is that it has a simpler interface optimized for the majority use-case.
With htmx, you are largely tied to a request/reply paradigm. Something happens that triggers a request (e.g. user clicks a button, or some element scrolls into view), htmx sends the request, and then it processes the response. The htmx interface (`hx-get`, hx-trigger`) is optimized to make this paradigm extremely simple and concise to specify.
Datastar's focus (last I checked) is on decoupling these two things. Events may stream to the client at any time, regardless of whether or not they were triggered by a specific action on the client, and they get processed by Datastar and have some effect on the page. htmx has affordances for listening to events (SEE extension, new fetch support) and for placing items arbitrarily on the page (out-of-band swaps) but if your use-case is a video game or a dashboard or something else where the updates are frequently uncorrelated with user actions, Datastar makes a lot of sense. It's a bit like driving a manual transmission.
Delaney is fond of saying that there's no need for htmx when Datastar can technically do everything htmx can [0]. But I think this misses the point of what makes htmx so popular: most people's applications do fit within a largely request/reply paradigm, and using a library that assumes this paradigm is both simpler to implement and simpler to debug. As an htmx maintainer, I often encourage people to even use htmx less than they want to, because the request/reply paradigm is very powerful and the more you can adhere to browser's understanding of it, the more durable and maintainable your website will be [1].
[0] https://data-star.dev/essays/v1_and_beyond
[1] https://unplannedobsolescence.com/blog/less-htmx-is-more/
Why bother with v4 at all? If it dilutes that simpler interface?
I think that even with req/resp morph leads to a simpler majority use case and that's what Turbo and Datastar have both shown. No?
> Why bother with v4 at all? If it dilutes that simpler interface?
v4 makes almost no changes to the interface, other than to flip inheritance to be off by default.
> I think that even with req/resp morph leads to a simpler majority use case and that's what Turbo and Datastar have both shown. No?
Although you can use the idiomorph extension for htmx, I personally don't think idiomorph is simpler, because there's an algorithm choosing what parts of the page get replaced based on the server response; I prefer to specify exactly what parts of the page get replaced in much simpler terms, a CSS selector, with `hx-target`.
Per [1] above, my style is minimize partial page responses wherever possible, so the ones that I do have are bespoke and replace a specific thing.
The irony that the Datastar author originally tried to have those features added to HTMX a few years ago.
Better late than never. Everyone benefits with HTMX evolving and bringing more attention and capabilities to hypermedia-first approaches.
One important difference that I found is that HTMX (and Alpine AJAX) can easily push a URL into the browser's location history. I've used this feature often with my Django projects--essentially storing the state in the URL which is great for sharing URLs or bookmarking them. As far as I'm aware, Datastar have locked this feature behind the "Pro" paywall.
Check out window.history.pushState
Fair. Though, D*'s authors are pretty adamant that this is an anti-pattern - that's why they put it behind the paywall.
Moreover, the FOSS code still exists and would take 2 minutes to update to the current plugin API (I have Datastar pro and the code is almost exactly the same)
https://github.com/starfederation/datastar/blob/v1.0.0-beta....
I'm interested in why this would be an anti-pattern? What would the alternative be?
I'm not qualified to comment as I don't use the feature, but people in their Discord would be happy to explain/discuss - its a wonderful place for learning more about the web, backend architecture and more.
I'm also sure this has already been explained in comments to other posts here as well.
Pay for the antipatterns?
I'm too tired to parse this logic, but I suspect it is a novel entry in techcorp doublespeak/dirty tricks.
I think the logic is the following:
* Datastar was re-written from the ground up, numerous times.
* They didn't want to update and maintain the plugins that they viewed as unnecessary/anti-patterns
* People wanted them still, so they said "fine, pay us to port it". Or, do it yourself - the MIT code is sitting right there and the changes are not all that significant. You'd also learn more about D* while at it. I linked in the parent comment to the MIT code - would not be difficult for anyone to do.
I suspect that in the long-run (probably not too far from now), they'll just make those plugins MIT again as the real value of Pro is the inspector, and soon their WIP web component framework (Rocket) and css framework (stellar) - all of which have always been being a commercial license.
p.s. there's no techcorp here. Its literally 3 guys with day jobs donating their time to a 501c3-registered non-profit. Funds go to things like going to conferences, or holding their own.
> the real value of Pro is the inspector
Ah, yes, a debugging tool. Only professionals need those.
I can't tell what sort of sarcasm this is - whether youre saying that the inspector should be available to all, or that no one actually needs it.
Whatever the case, you dont truly need it, but it is helpful. You buy it for convenience as well as to support the project.