In 2022, David Guillot delivered an inspiring DjangoCon Europe talk, showcasing a web app that looked and felt as dynamic as a React app. Yet he and his team had done something bold. They converted it…
In 2022, David Guillot delivered an inspiring DjangoCon Europe talk, showcasing a web app that looked and felt as dynamic as a React app. Yet he and his team had done something bold. They converted it from React to HTMX, cutting their codebase by almost 70% while significantly improving its capabilities.
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.
I saw similar results when I switched my projects from HTMX to Datastar. It was exciting to reduce my code while building real-time, multi-user applications without needing WebSockets or complex frontend state management.
While preparing my FlaskCon 2025 talk, I hit a wall. I was juggling HTMX and AlpineJS to keep pieces of my UI in sync, but they fell out of step. I lost hours debugging why my component wasn’t updating. Neither library communicates with the other. Since they are different libraries created by different developers, you are the one responsible for helping them work together.
Managing the dance to initialize components at various times and orchestrating events was causing me to write more code than I wanted to and spend more time than I could spare to complete tasks.
Knowing that Datastar had the capability of both libraries with a smaller download, I thought I’d give it a try. It handled it without breaking a sweat, and the resulting code was much easier to understand.
I appreciate that there’s less code to download and maintain. Having a library handle all of this in under 11 KB is great for improving page load performance, especially for users on mobile devices. The less you need to download, the better off you are.
But that’s just the starting point.
As I incorporated Datastar into my project at work, I began to appreciate Datastar’s API. It feels significantly lighter than HTMX. I find that I need to add fewer attributes to achieve the desired results.
For example, most interactions with HTMX require you to create an attribute to define the URL to hit, what element to target with the response, and then you might need to add more to customize how HTMX behaves, like this:
<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>
One doesn’t always need all of these, but I find it common to have two or three attributes every timeAnd then there are the times I need to remember to look up the ancestry chain to see if any attribute changes the way I’m expecting things to work. Those are confusing bugs when they happen! .
With Datastar, I regularly use just one attribute, like this:
<span data-on-click="@get('/rebuild/status-button')"></span>
This gives me less to think about when I return months later and need to recall how this works.
The primary difference between HTMX and Datastar is that HTMX is a front-end library that advances the HTML specification. DataStar is a server-side-driven library that aims to create high-performance, web-native, live-updating web applications.
In HTMX, you describe its behavior by adding attributes to the element that triggers the request, even if it updates something far away on the page. That’s powerful, but it means your logic is scattered across multiple layers. Datastar flips that: the server decides what should change, keeping all your update logic in one place.
To cite an example from HTMX’s documentation:
<div>
<div id="alert"></div>
<button hx-get="/info"
hx-select="#info-details"
hx-swap="outerHTML"
hx-select-oob="#alert">
Get Info!
</button>
</div>
When the button is pressed, it sends a GET request to /info
, replaces the button with the element in the response that has the ID 'info-details', and then retrieves the element in the response with the ID 'alert', replacing the element with the same ID on the page.
This is a lot for that button element to know. To author this code, you need to know what information you’re going to return from the server, which is done outside of editing the HTML. This is when HTMX loses the ”locality of behavior” I like so much.
Datastar, on the other hand, expects the server to define the behavior, and it works better.
To replicate the behavior above, you have options. The first option keeps the HTML similar to above:
<div>
<div id="alert"></div>
<button id="info-details"
data-on-click="@get('/info')">
Get Info!
</button>
</div>
In this case, the server can return an HTML string with two root elements that have the same IDs as the elements they’re updating:
<p id="info-details">These are the details you are looking for…</p>
<div id="alert">Alert! This is a test.</div>
I love this option because it’s simple and performant.
A better option would change the HTML to treat it as a component.
What is this component? It appears to be a way for the user to get more information about a specific item.
What happens when the user clicks the button? It seems like either the information appears or there is no information to appear, and instead we render an error. Either way, the component becomes static.
Maybe we could split the component into each state, first, the placeholder:
<!-- info-component-placeholder.html -->
<div id="info-component">
<button data-on-click="@get('/product/{{product.id}}/info')">
Get Info!
</button>
</div>
Then the server could render the information the user requests…
<!-- info-component-get.html -->
<div id="info-component">
{% if alert %}<div id="alert">{{ alert }}</div>{% endif %}
<p>{{product.additional_information}}</p>
</div>
…and Datastar will update the page to reflect the changes.
This particular example is a little wonky, but I hope you get the idea. Thinking at a component level is better as it prevents you from entering an invalid state or losing track of the user’s state.
One of the amazing things from David Guillot’s talk is how his app updated the count of favored items even though that element was very far away from the component that changed the count.
David’s team accomplished that by having HTMX trigger a JavaScript event, which in turn triggered the remote component to issue a GET request to update itself with the most up-to-date count.
With Datastar, you can update multiple components at once, even in a synchronous function.
If we have a component that allows someone to add an item to a shopping cart:
<form id="purchase-item"
data-on-submit="@post('/add-item', {contentType: 'form'})">"
>
<input type=hidden name="cart-id" value="{{cart.id}}">
<input type=hidden name="item-id" value="{{item.id}}">
<fieldset>
<button data-on-click="$quantity -= 1">-</button>
<label>Quantity
<input name=quantity type=number data-bind-quantity value=1>
</label>
<button data-on-click="$quantity += 1">+</button>
</fieldset>
<button type=submit>Add to cart</button>
{% if msg %}
<p class=message>{{msg}}</p>
{% endif %}
</form>
And another one that shows the current count of items in the cart:
<div id="cart-count">
<svg viewBox="0 0 10 10" xmlns="http://www.w3.org/2000/svg">
<use href="#shoppingCart">
</svg>
{{count}}
</div>
Then a developer can update them both in the same request. This is one way it could look in Django:
from datastar_py.consts import ElementPatchMode
from datastar_py.django import (
DatastarResponse,
ServerSentEventGenerator as SSE,
)
def add_item(request):
# skipping all the important state updates
return DatastarResponse([
SSE.patch_elements(
render_to_string('purchase-item.html', context=dict(cart=cart, item=item, msg='Item added!'))
),
SSE.patch_elements(
render_to_string('cart-count.html', context=dict(count=item_count))
),
])
Being a part of the Datastar Discord, I appreciate that Datastar isn’t just a helper script. It’s a philosophy about building apps with the web’s own primitives, letting the browser and the server do what they’re already great at.
Where HTMX is trying to push the HTML spec forward, Datastar is more interested in promoting the adoption of web-native features, such as CSS view transitions, Server-Sent Events, and web components, where appropriate.
This has been a massive eye-opener for me, as I’ve long wanted to leverage each of these technologies, and now I’m seeing the benefits.
One of the biggest wins I achieved with Datastar was by refactoring a complicated AlpineJS component and extracting a simple web component that I reused in multiple placesI’ll talk more about this in an upcoming post. .
I especially appreciate this because there are times when it’s best to rely on JavaScript to accomplish a task. But it doesn’t mean you have to reach for a tool like React to achieve it. Creating custom HTML elements is a great pattern to accomplish tasks with high locality of behavior and the ability to reuse them across your app.
However, Datastar provides you with even more capabilities.
Apps built with collaboration as a first-class feature stand out from the rest, and Datastar is up to the challenge.
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.
Datastar uses a simple web technology called Server-Sent Events (SSE) to allow the server to “push” updates to connected clients. When something changes, such as a user adding a comment or a status change, the server can immediately update browsers with minimal additional code.
You can now build live dashboards, admin panels, and collaborative tools without crafting custom JavaScript. Everything flows from the server, through HTML.
Additionally, suppose a client’s connection is interrupted. In that case, the browser will automatically attempt to reconnect without requiring additional code, and it can even notify the server, “This is the last event I received.” It’s wonderful.
Being a part of the Datastar community on Discord has helped me appreciate the Datastar vision of making web apps. They aim to have push-based UI updates, reduce complexity, and leverage tools like web components to handle more complex situations locally. It’s common for the community to help newcomers by helping them realize they’re overcomplicating things.
Here are some of the tips I’ve picked up:
- Don’t be afraid to re-render the whole component and send it down the pipe. It’s easier, it probably won’t affect performance too much, you get better compression ratios, and it’s incredibly fast for the browser to parse HTML strings.
- The server is the state of truth and is more powerful than the browser. Let it handle the majority of the state. You probably don’t need the reactive signals as much as you think you do.
- Web components are great for encapsulating logic into a custom element with high locality of behavior. A great example of this is the star field animation in the header of the Datastar website. The <ds-starfield>
element encapsulates all the code to animate the star field and exposes three attributes to change its internal state. Datastar drives the attributes whenever the range input changes or the mouse moves over the element.
But what I’m most excited about are the possibilities that Datastar enables. The community is routinely creating projects that push well beyond the limits experienced by developers using other tools.
The examples page includes a database monitoring demo that leverages Hypermedia to significantly improve the speed and memory footprint of a demo presented at a JavaScript conference.
The one million checkbox experiment was too much for the server it started on. Anders Murphy used Datastar to create one billion checkboxes on an inexpensive server.
But the one that most inspired me was a web app that displayed data from every radar station in the United States. When a blip changed on a radar, the corresponding dot in the UI would change within 100 milliseconds. This means that *over 800,000 points are being updated per second*. Additionally, the user could scrub back in time for up to an hour (with under a 700 millisecond delay). Can you imagine this as a Hypermedia app? This is what Datastar enables.
I’m still in what I consider my discovery phase of Datastar. Replacing the standard HTMX functionality of ajaxing updates to a UI was quick and easy to implement. Now I’m learning and experimenting with different patterns to use Datastar to achieve more and more.
For decades, I’ve been interested in ways I could provide better user experiences with real-time updates, and I love that Datastar enables me to do push-based updates, even in synchronous code.
HTMX filled me with so much joy when I started using it. But I haven’t felt like I lost anything since switching to Datastar. In fact, I feel like I’ve gained so much more.
If you’ve ever felt the joy of using HTMX, I bet you’ll feel the same leap again with Datastar. It’s like discovering what the web was meant to do all along.
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.
You can send everything down at once with htmx too, with oob swaps.
yes you can, but the complexity is now moved to server side template wrangling. With SSE, its just separate events with targets. It feels much cleaner
Server side template wrangling is not really a big deal, if you use an HTML generation library...something like Python's Hpty/FastHTML or JavaScript's JSX. You can easily split the markup down into 'components' and combine them together trivially with composition.
I mean in practice you rarely target individual elements in datastar. You can sure. But targeting the main body with the entirety of the new content is way simpler. Morph sorts out the rest
"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.
if you use alpine, make sure to get the morph extensions for both htmx and alpine.
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.
> 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?
I don't think the difference would be significant. How many of your HTML elements would become interactive with htmx? There's a limit to how much interaction you can reasonably add on a page. This will also limit the number of new attributes you will introduce in the markup.
Also, by this argument should we leave out the 'href' attribute from the '<a>' tag and let the server decide what page to serve? Of course not, the 'href' attribute is a critical part of the functionality of HTML.
Htmx makes the same argument for the other attributes.
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
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!
It is 299$ lifetime. It is extremely cheap
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.
it depends strongly on why you want to write open source. if you like the idea of putting source code out into the world for other people to use and benefit from then go ahead and use whatever mix of open source and proprietary code you like, just be up front that that's what you are doing.
if you want to promise open source software simply to attract the mindshare and users who habitually ignore anything that isn't open source, trying to capture financial value may well be infeasible unless some rare confluence of stars lines up for you. the key is in the word "capture" - capturing the value implies making sure it goes to you rather than to someone else, and that means imposing restrictions that will simply piss those same users off.
Some solo dev projects are used as a platform to sell books, training, ads, speaking engagement, consulting, and development.
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.
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.
It will be, eventually, unless a maintainer is able to maintain during the day. It doesn't matter what the source of free time is however: retired, rich, runs a company from their open source project, paid by somebody else, etc., but full time job + open source maintainer = dead project, eventually.
Yes look at the active issues on GitHub. There's hundreds and some going back years with no traction.
I don't think open issues is a fair way to judge project liveness. TypeScript also has hundreds of open issues going back years with no traction. Is TypeScript dead?
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!
Wait so you pay to use the anti patterns? That’s a new one.
[dead]
I just come from writing a comment on the other Datastar post on the home page, literally saying that I don't see the point of it and that I don't like it.
But I'm now here to defend Datastar.
It's their code, which, up to now, they built and literally given away totally for free, under a MIT license. Everything (even what "they moved to the Pro tier") should still be free and under the MIT license that it was published under originally.
You just decided to rely and freeload (as, as far as I can tell, you never contributed to the project).
You decided to rely on a random third party that owns the framework. And now you're outraged because they've decided that from now on, future work will be paid.
You know the three magic words:
Just. Fork. It.
Calling the OP a freeloader is over the top.
The software was released as a free version, with NO expectation for it to go commercial.
The fact that they switch to a paid version, and stripping out features from the original free version, is called "bait and switch".
If OP knew in advanced, he will have been informed about this and the potential 299 price tag. And he will have been able to make a informed decision BEFORE integrating the code.
> You just decided to rely and freeload (as, as far as I can tell, you never contributed to the project).
But you complaint about him being a freeloader for not contributing to a project. What a ridiculous response.
I feel like you never even read the post and are making assumption that OP is a full time programmer.
Datastar can do whatever they want, its their code. But calling out a *bait and switch* does not make OP the bad guy.
Yeah, I agree, it's over the top. I'm just matching the over-the-top language of the original post, which pretty much calls the Datastar devs "disgraceful" and to "f them".
I did read the post. I know OP not a programmer. And that makes it even worse: OP has the audacity of saying they "make no money from the project" while it being a scheduling tool for their presumably plenty money-making clinic.
It would in fact be less shocking if they were a programmer doing a side project for fun.
This piece is not a rational, well tempered article. Is a rant by someone who just took something that was free and is now outraged and saying fuck you to those who made their project possible in the first place, not even understanding how licenses work or even being aware that the code they relied on is still there, on github, fully intact, and available for them.
This sort of people not only want to get it for free. They want their code to be maintained and improved for free in perpetuity.
They deserve to be called freeloaders.
The license makes it very clear that “no expectations” goes all round, including the right to other people doing free maintenance for you.
its not bait and switch, its main has features we are willing to continue to support given we did a whole rewrite and this is what we think you should use. Don't like it? Fork it, code is still there. I hope your version is better!
> its not bait and switch, its main has features we are willing to continue to support given we did a whole rewrite and this is what we think you should use. Don't like it? Fork it, code is still there. I hope your version is better!
It sounds like your are the dev of Datastar...
Let me give one piece of advice. Drop the attitude because this is not how you interact in public as the developers of a paid piece of software.
You can get away with a lot when its free/hobby project, but the moment you request payment, there is a requirement for more professionalism. These reactions that i am reading, will trigger responses that will hurt your future paycheck. Your already off on a bad start with this "bait and switch", do not make it worse.
I really question your future client interactions, if they criticize your product(s) or practices.
> I hope your version is better!
No need for Datastar, my HTMX "alternative" has been in production (with different rewrites) over 20 years. So thank you for offering, but no need.
>Drop the attitude
I have to be honest, I dont see what's wrong with it.
They were accused of bait and switch, which is not even half true. Old Pro code is still available under MIT. Newer version charges more. That is it.
I'll certainly defend d*'s right to do what they did, but the wisdom of doing so is going to come into question as soon as they reject a PR because it contains a feature that's in Pro. I don't think people who are concerned about that deserve to be called "freeloaders", but I guess a fork is a way out of such acidic rhetoric too.
D* has a core, which is open and will be set in stone soon when v1 is released, with the expectation that it'll barely, if ever, change again.
The rest is plugins, which anyone can write or modify. There's no need for the plugins to get merged upstream - just use them in your project, and share them publicly if you want. You could even do the same with the pre-pro versions of the pro plugins - just make the (likely minor) modifications to make them compatible with the current datastar core.
They're also going to be releasing a formal public plugin api in the next release. Presumably it'll be even easier to do all of this then.
Sounds like they put some real thought into it then, which is good news. I was picturing two different core distributions, which would create the sort of conflict I was imagining, but as long as core does stay maintained, it seems likely that fear will stay imaginary.
one might say they've put far too much thought into it all. Its very impressive
FUD is all hackernews runs on apparently
As I answered somewhere else, the over-the-top freeloader term I think is justified because OP clearly expects not only to benefit from the work already available, freely, but also to be entitled, for free, to any work and improvement that comes in the future.
This is nonsensical. Someone did something for free. Fantastic. They used it, successfully, for a production system that enables scheduling for their job.
Nobody took that away from them. They didn't force them to rebuild their tool.
The code is even there, in the git history, available for them.
If OP doesn't like what the devs decided to do with the project, just move on or fork and pay someone to help you fix any outstanding bugs or missing features.
There is a generation divide in open source ideology over the past 10 - 20 years.
The modern one is what op and lots of younger generation agree upon. It should always be open source and continue to be supported by the community.
The old folks are basically take it or leave it. Fork it into my own while taking the maintenance burden too.
Wait - what's wrong with that? It's their project, they can merge whatever PRs they want!
> Just. Fork. It.
The “outrage” is literally just people saying they’ll use a different project instead. Why would they ever fork it? They don’t like the devs of datastar they don’t want to use it going forwards. Yes the developers are allowed to do what they want with their code and time, but people are allowed to vote with their feet and go elsewhere and they are allowed to be vocal about it.
It gets worse.
I payed the one off 299$ for a pro license but have yet to find a reason to use any of the pro features.
I was hoping to need them for the google sheets clone [1] I was building but I seem to be able to do it without PRO features.
I don't understand. Why is it a problem with Datastar if you buy their Pro license without needing it?
The comment is tongue in cheek. On the discord it was discussed at length and some of the plugins in the Pro version were actually considered anti-patterns, it actually is kinda easy to complicate things needlessly when getting used to D* and I know I did this too in the beginning.
As was said by the commenter in another reply, the inspector is actually the bit that makes the Pro version much more appealing but most people wouldn't know from the sidelines.
Arguably that's good though - for the project. It means it's not a bait and switch like many have claimed. You can build pretty much anything with regular Datastar.
I, also, was swindled by those cultists.
I thought the devs' emphatic assertions in their Discord NOT to buy Datastar Pro was a psyop dark pattern. I bought it to spite them, and barely use any of it. I want my css-in-js back!
he is out of line but he is right
Could not tell if sarcasm or not. This seems awesome to me. You are using a piece of software and supporting it.
Sorry, yes it was sarcasm (I should have indicated that explicitly). I'm happy to fund a tool that I really enjoy using, even if I don't use any of the PRO features.
Datastar always rubbed me the wrong way. The author was constantly pushing it in the HTMX discord, telling anyone who would listen that if they liked HTMX how great Datastar would be for them. Some pretty classy comments from them on reddit too:
> It was a full rewrite. Use the beta release forever if it has all the tools you need. No one is stopping you.
> Open source doesn't owe you anything and I expect the same back.
> The author was constantly pushing it in the HTMX discord, telling anyone who would listen that if they liked HTMX how great Datastar would be for them
You know who else does that? THE DEVELOPER OF HTMX! https://htmx.org/essays/alternatives/
> Some pretty classy comments from them on reddit too:
What is unclassy about those comments? Seem sensible to me...
Agree nothing unclassy. People have this strange expectation that an open source project is out there to serve every single person using it with total attention. It’s not, feel free to fork the beta and use it forever, make your own changes. The pro tier cost is a pittance for anyone using it for profit.
HTMX doesnt do half of what datastar does. And datastar's free version does 99% of what the pro version does
And react should be paying people to take on its immense performance and maintenance burden
React is literally maintained by a consortium of the world's biggest companies and before this Facebook/Meta. This is a ridiculous thing to say.
Going to vouch for this. Why does it matter what other people do? This is such a non issue, you are free to fork it and do your own work. I actually believe more open source repos should tastefully have paid tiers to help pay for the continued work.
I feel like you can push your own thing in your own discord…
Something about riding the hype train for a fully open and free library you did not create to push your product just feels strange to me.
there is (or at least was) literally a dedicated Datastar channel in the htmx discord...
Which has since been archived. Last post from “Datastar CEO”. I mean cmon, it’s a little cringe. That meme is funny when it’s about HTMX. Like at least try your own memes instead of riding on Carson’s sense of humor too.
I dont disagree. I wouldn't dare try to follow in Carson's shitposting/memeing footsteps - that's a line far too fine for me to walk.
well Datastar started as an attempt to make HTMX an framework instead of just a library. It was part of the HTMX discord for years
I know the projects/specifics are completely different but this immediately reminded me of Meteor.js from back in the day
Technically very different but emotionally yes very the same but a lot simpler
Yeah cool, I think this is the point. People want to get paid for the work they produce and the dynamic in open source is not even quietly known to be unsustainable.
I like the communal aspect of open source, but I don’t like overly demanding and entitled free loaders. I’ve had enough of that in my well paid career over the last decade.
This way of getting paid may or may not resonate, but I applaud the attempt to make it work.
I don't get why people get so worked up over Datastar's pro tier - you almost certainly don't need it.
The inspector is great, but it's too much work to swap out the free bundle for the pro bundle every time I want to use it.
I'm only working in local dev right now, so i've got the pro version and inspector going. When I get to prod, perhaps this will be a problem.
Yet, surely, this could just be toggled with an env var or db setting or something? if dev, include pro and inspector component. If prod, use free version (or custom bundle that only has what you need)
That's how people tick. We aren't satisfied with what we have if there is more. Doesn't matter if we need it.
Finally someone is speaking truth to power. These registered non-profits that release their code for free and their leisure time for support need to be knocked down a notch.
We all know they are evil. But you know the most evil thing? That code that was previously released under a free license? Still sneakily on display in the git history like the crown jewels in the Tower of London. Except of armed guard defending the code that wants to be free once more it's hidden behind arcane git commands. Name me a single person that knows how to navigate the git history. I'm waiting. Spoiler alert: I asked Claude and they don't exist.
Sure, but this person is a doctor (or similar) who took time to learn to code this form up to better serve their patients. They are most likely blessedly ignorant of software licenses and version control.
As I read it the op said, "I don't like how they changed this license, this is a bad direction and I didn't think there was adequate transparency."
And your rebuttal is, "Well you can always recover the code from the git history?"
I mean, this is true, but do you think this really addresses the spirit of the post's complaint? Does mentioning they're a non-profit change anything about the complaint?
The leadership and future of a software project is an important component in its use professionally. If someone believes that the project's leadership is acting in an unfair or unpredictable way then it's rational and prudent for them to first express displeasure, then disassociate with the project if they continue this course. But you've decided to write a post that suggests the poster is being irrational, unfair, and that they want the project to fail when clearly they don't.
If you'd like to critique the post's points, I suggest you do so rather than straw manning and well-poisoning. This post may look good to friends of the project, but to me as someone with only a passing familiarity with what's going on? It looks awful.
[flagged]
Oh I did. I got rid of it. Inspiring both constant censure and the kind of response you're giving drove me to despair.
I don't write things for public consumption now.
But we're not talking about me or the post. We're talking about your refusal to engage with the implications of what the project did.
I don't care what Datastar does. I'd never use Datastar. Looks like exactly what I don't need. They can certainly govern their product as they see fit.
But I've disassociated from projects for less egregious unannounced terms changes. And I've never had that decision come out for the worst, only neutral or better.
Good luck with your future endeavors, I guess.
I love everything about this answer
1. Open LICENSE on GitHub
2. Click on the commit ID
3. You’ll see something like “1 parent: fdsfgsd” – click through to that commit
4. Browse
I mean, it’s a shitty move for sure, but eh.
Huh! I’m getting rusty.
Yes, much power! Datastar is the worst, how dare they?
[dead]
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.
except the trap isnt actually set, and there's a mound of cheese next to it anyway
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.
Thanks for the information.
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.
I'm normally not one to discourage anyone from open-source; but if toxic entitlement is going to get you this worked up, you might consider whether it's really your thing. The more successful you are the more you're going to encounter.
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?
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
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.
In any hypothetical open source project I make from now on where I am the owner and sole director I'll just get rid of the features entirely if they cause an undue support burden (which the datastar dev has gone up and down both threads saying this is what happened) to avoid specifically your comment.
Seems to fit in with your world view better and then I can just leave those people high and dry with much less concern!
You're not owed these people's time.
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.
Odd statement from a doctor using this at his practice:
"It is not like $299 is much for me, but I am just a hobbist."
It's one of the worst blog post I've ever read.
They kind of have a point but everything around it is ridiculous.
Yeah man. He’s a just a hobbit. But, aren’t we all just hobbits really?
Is the greedy developer in the title the one who wants the 3rd party for free without contributing, or the developer who wrote the said 3rd party and asking compensation?
I am confused.
The problem is that the developer of datastar did a bait and switch. Releasing the beta for free, and then removing features into a pro version with a price tag.
Nothing wrong with people making money on their software but you need to make it clear from the start, that it will be paid software and what price range.
Bait and switch is often used to get people to use your software, you spend time into it, and then if you need a Pro feature, well, fork up or rework your code again. So your paying with your time or money. This is why its nasty and gets people riled up.
Its amazing how many people are defending this behavior.
Correct me if I am wrong here, but what you had for free, you still have it for free, since it's a MIT license, what you cloned initially is still "yours".
Is the problem thar one needs to fork / maintain the code from now on? Is the problem that one wants free support on top of the free library?
MIT, source is still there, look at the tags and fork it. You have the same rites as me!
Take a chill pill sudodevnull ... As i stated before, turn down the rhetoric. Your not helping yourself with these "!" reactions.
A lot of PRO plugins can be self developed. An example: there is a poor-man's inspector plugin at [1].
The replace-url thing should be a simple JS code using history API no?
[1] https://github.com/sudeep9/datastar-plugins?tab=readme-ov-fi...
> But the one that most inspired me was a web app that displayed data from every radar station in the United States.
Anyone have a link for this?
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.
if a feature I want is in the paid product then I assume there's less chance of it being added to the free version. every feature has to go through a process to decide if it's paid or free.
If there's money to be made the possibility that the feature will ever exist at all goes way up. I'd rather have the ability to pay for a feature if I decide I need it than to hope some maintainer gets around to building it for free.
They've said that the feature they put in the premium product are the features they don't want to build or maintain without being paid to do so.
Having so many features behind a Pro gate makes this a non-starter for enterprise. How would anyone convince their company to adopt this?
People can develop open source equivalents you know, you're not required to use the pro version to get a certain feature. From my understanding, datastar was designed to be entirely modular and extensible.
EXACTLY which feature do you need?
> I had a running service written in htmx for some time. It is a clinic opening hour service to inform my patients when I will be available in which clinic. (Yes, I am not a programmer, but a healthcare professional.)
-> that was pretty freaking cool to read, loved it
also chuckled at the idea of my website making, health professional going all "What the fuck." in front of his codebase.
If the developer rug pulled once they will probably do it again. Thx for the heads up.
what was taken from you? point to the source history that's been removed please. It's funny that stuff like this means people won't ever develop in the open. Hope that makes y'all happy
I tried to understand this, but it seems like a non-native English speaker met an LLM and used it to create a blog post. Can someone please explain why this exists?
cause people hate how you give your own gifts to the world of open source. fuck 'em
DHH is spot on like he is on many issues!
There is a saying in my language which translates: give someone a hand and they'll take your whole arm.
I was looking for a tool to follow along with signal patches and was a bit disappointed to see the inspector is under "pro"- that and the query string sync are the two nice-to-haves.
so you want nothing to be useful in Pro? you are telling devs how to spend their time and effort?
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.
if we're talking about something immense, like redis, you might have a point. But we're talking about a few hundred lines of simple javascript that are still available to fork and update to be compatible with the new API. The fact that no one has done such a simple thing yet means this is a non-issue
The thing is there's not much practical difference for users. They might not be aware that it's only a few hundred lines of code, and it really doesn't matter. The point is that they were depending on a software feature one day, and the next they were asked to pay for it. That's the very definition of a rugpull. Whether it's a few hundred lines of code, several thousand, or the entire product, the effect is the same.
Forking is always an option, of course, but not many people have the skills nor desire to maintain a piece of software they previously didn't need to. In some cases, this causes a rift in the community, as is the case for Redis/Valkey, Terraform/OpenTofu, etc., which is confusing and risky for users.
All of this could've been avoided by keeping all existing features freely available to everyone, and commercializing new value-add features for niche/enterprise users. Not doing that has understandably soured peoples' opinion of the project and tarnished their trust, as you can see from that blog post, and comments on here and on Reddit. It would be a mistake to ignore or dismiss them.
One other comment though: a lot of what you said rests upon the notion that people were relying on these features.
First, barely anyone used datastar at that point, and those features were particularly arcane. So, the impact was minimal.
Second, its likely that even fewer of them contributed anything at all to the project in general, and those features in particular. What claim do they have to anything - especially when it was just freely given to them, and not actually taken away (the code is still there)?
And to the extent that they can't or wont fix it themselves, what happens if the dev just says "im no longer maintaining datastar anymore"? You might say "well, at least he left them something usable", but how is that any different from considering the pro changes to just be a fork? In essence, he forked his own project - why does anyone have any claim to any of that?
Finally, if they cant fix it themselves (especially when AI could almost certainly fix it rapidly), should they really be developing anything?
In the end, this really is a non-issue. Again, most of the furor is quite clearly performative. Its like when DHH removed typescript from one of his projects that he and his company maintain, and people who have nothing to do with ruby came out of the woodwork to decry the change in his github repo. And even if they do have something to do with ruby, they have no say over how he writes his code.
> a lot of what you said rests upon the notion that people were relying on these features.
They were, though. The blog post linked above, and several people in the Reddit thread linked in the blog post mentioned depending on these features.
We can disagree about whether it matters that a small percentage of people used them, but I would argue that even if a single person did, a rugpull is certainly a shitty experience for them. It also has a network effect, where if other people see that developers did that, they are likely to believe that something similar in the future can happen again. Once trust is lost, it's very difficult to gain it back.
> Second, its likely that even fewer of them contributed anything at all to the project in general, and those features in particular. What claim do they have to anything - especially when it was just freely given to them, and not actually taken away (the code is still there)?
I think this is a very hostile mentality to have as an OSS developer. Delaney himself expressed something similar in that Reddit thread[1]:
> I expect nothing from you and you in turn should expect nothing from me.
This is wrong on many levels.
When a software project is published, whether as open source or otherwise, a contract is established between developers and potential users. This is formalized by the chosen license, but even without it, there is an unwritten contract. At a fundamental level, it states that users can expect the software to do what it advertises to do. I.e. that it solves a particular problem or serves a particular purpose, which is the point of all software. In turn, at the very least, the developer can expect the project's existence to serve as an advertisement of their brand. Whether they decide to monetize this or not, there's a reason they decide to publish it in the first place. It could be to boost their portfolio, which can help them land jobs, or in other more direct ways.
So when that contract is broken, which for OSS typically happens by the developer, you can understand why users would be upset.
Furthermore, the idea that because users are allowed to use the software without any financial obligations they should have no functional expectations of the software is incredibly user hostile. It's akin to the proverb "don't look a gift horse in the mouth", which boils down to "I can make this project as shitty as I want to, and you can't say anything about it". At that point, if you don't care about listening to your users, why even bother releasing software? Why choose to preserve user freedoms on one hand, but on the other completely alienate and ignore them? It doesn't make sense.
As for your point about the code still being there, that may be technically true. But you're essentially asking users to stick with a specific version of the software that will be unmaintained moving forward, as you focus on the shiny new product (the one with the complete rewrite). That's unrealistic for many reasons.
> And to the extent that they can't or wont fix it themselves, what happens if the dev just says "im no longer maintaining datastar anymore"?
That's an entirely separate scenario. If a project is not maintained anymore, it can be archived, or maintenance picked up by someone else. Software can be considered functionally complete and require little maintenance, but in the fast moving world of web development, that is practically impossible. A web framework, no matter how simple, will break eventually, most likely in a matter of months.
> Finally, if they cant fix it themselves (especially when AI could almost certainly fix it rapidly), should they really be developing anything?
Are you serious? You expect people who want to build a web site and move on with their lives to dig into a foreign code base, and fix the web framework? It doesn't matter how simple or complex it is. The fact you think this is a valid argument, and additionally insult their capability is wild to me. Bringing up "AI" is laughable.
> Again, most of the furor is quite clearly performative.
Again, it's really not. A few people (that we know of) were directly impacted by this, and the network effect of that has tarnished the trust other people had in the project. Doubling down on this, ignoring and dismissing such feedback as "performative", can only further harm the project. Which is a shame, as I truly do want it to gain traction, even if that is not the authors' goal.
Anyway, I wish you and the authors well. Your intentions seem to come from the right place, but I think this entire thing is a misstep.
[1]: https://old.reddit.com/r/datastardev/comments/1lxhdp9/though...
The sibling comment already thoroughly addressed all of this, so there's no need to me to do so other than to say that, despite your good intentions, you don't seem to have even the slightest understanding of open source.
Here's the text of the mit license https://mit-license.org/
At no point does it say anything like "I am obliged to maintain this for you forever, or even at all, let alone to your liking"
> despite your good intentions, you don't seem to have even the slightest understanding of open source
Please. Resorting to ad hominem when you don't have good arguments against someone's opinion is intellectually lazy.
> At no point does it say anything like "I am obliged to maintain this for you forever, or even at all, let alone to your liking"
I'm well familiar with most OSS licenses. I never claimed they said this.
My point was about an unwritten social contract of not being an asshole. When you do a public deed, such as publishing OSS, and that project gains users, you have certain obligations to those users at a more fundamental level than the license you chose, whether you want to acknowledge this or not.
When you ignore and intentionally alienate users, you can't be surprised when you receive backlash for it. We can blame this on users and say that they're greedy, and that as a developer you're allowed to do whatever you want, becuase—hey, these people are leeching off your hard work!—but that's simply hostile.
The point of free software is to provide a good to the world. If your intention is to just throw something over the fence and not take users into consideration—which are ultimately the main reason we build and publish software in the first place—then you're simply abusing this relationship. You want to reap the benefits of exposure that free software provides, while having zero obligations. That's incredibly entitled, and it would've been better for everyone involved if you had kept the software private.
There's literally no ad hominem where you claimed there was. That itself is ad hominem.
I'll go further this time - not only do you not understand open source licensing or ecosystem even slightly, but it's genuinely concerning that you think that someone sharing some code somehow creates "a relationship" with anyone who looks at it. The point of free software is free software, and the good to the world is whatever people make of that.
Again, the only people who seem to be truly bothered by any of this are people who don't use datastar.
Don't use it. In fact, I suspect that the datastar maintainers would prefer that you, specifically, don't use it. Use it to spite them! We don't care.
I also retract my statement about you having good intentions/communicating in good faith. I won't respond to you again.
> the only people who seem to be truly bothered by any of this are people who don't use datastar.
Yeah, those silly people who were previously interested in Datastar, and are criticizing the hostility of how this was handled. Who cares what they think?
> Don't use it. We don't care. In fact, I suspect that the datastar maintainers would prefer that you, specifically, don't use it.
Too bad. I'll use it to spite all of you!
> I also retract my statement about you having good intentions/communicating in good faith.
Oh, no.
> a rugpull is certainly a shitty experience for them
It would certainly be a shitty experience, if there actually was a rugpull, which there was not. People who were using the version of Datastar that had all those features are still free to keep using that version. No one is taking it away. No rug was pulled.
> a contract is established between developers and potential users
Sorry, but no. The license makes this quite clear–every open source license in the world very explicitly says 'NO WARRANTY' in very big letters. 'No warranty' means 'no expectations'. Please, don't be one of those people who try to peer-pressure open source developers into providing free software support. Don't be one of the people who says that 'exposure' is a kind of payment. I can't put food on my table with 'exposure'. If you think 'exposure' by itself can be monetized, I'm sorry but you are not being realistic. Go and actually work on monetizing an open source project before you make these kinds of claims.
> why even bother releasing software?
Much research and study is not useful for many people. Why even bother doing research and development? Because there are some who might find it useful and convert it into something that works for themselves. Open source software is a gift. The giving of the gift does not place obligations on the giver. If you give someone a sweater, are you expected to keep patching it whenever it develops holes?
> If a project is not maintained anymore, it can be archived, or maintenance picked up by someone else.
Then why can't it be maintained by someone else in the case of using the old free version?
> A web framework, no matter how simple, will break eventually, most likely in a matter of months.
Sure, the ones that depend on a huge npm transitive dependency cone can. But libraries or frameworks like htmx and Datastar are not like that, they are single <script> files that you include directly in your HTML. There is no endless treadmill of npm packages that get obsoleted or have security advisories all the time.
> You expect people who want to build a web site and move on with their lives to dig into a foreign code base, and fix the web framework?
Well...ultimately, if I use some open source software, I am actually responsible for it. Especially if it's for a commercial use case. I can't just leech off the free work of others to fix or maintain the software to my needs. I need to either fix my own issues or pay someone to do it. If the upstream project happens to do it for me, I'm in luck. But that's all it is. There is ultimately no expectation that open source maintainers will support me for free, perpetually, when I use their software.
> A few people (that we know of) were directly impacted by this
What impact? One guy blogged that just because there are some paid features, it automatically kills the whole project for him. There's no clear articulation of why exactly he needs those exact paid features. Everything else we've seen in this thread is pile-ons.
> Doubling down on this, ignoring and dismissing such feedback as "performative"
Aren't you doing the same thing? You have been ignoring and dismissing the feedback that this is actually not that big of a deal. Why do you think that your opinion carries more weight than that of the actual maintainers and users of the project?
> People who were using the version of Datastar that had all those features are still free to keep using that version.
Why are you ignoring my previous comment that contradicts this opinion?
> No one is taking it away. No rug was pulled.
When Redis changed licenses to SSPL/RSAL, users were also free to continue using the BSD-licensed version. Was that not a rug pull?
In practice, it doesn't matter whether the entire project was relicensed, or if parts of it were paywalled. Users were depending on a piece of software one day, and the next they were forced to abide by new terms if they want to continue receiving updates to it. That's the very definition of a rug pull. Of course nobody is claiming that developers physically took the software people were using away—that's ridiculous.
> Sorry, but no. The license makes this quite clear
My argument was beyond any legal licensing terms. It's about not being an asshole to your users.
> I can't put food on my table with 'exposure'.
That wasn't the core of my argument, but you sure can. Any public deed builds a brand and reputation, which in turn can lead to financial opportunities. I'm not saying the act of publishing OSS is enough to "put food on your table", but it can be monetized in many ways.
> Open source software is a gift. The giving of the gift does not place obligations on the giver. If you give someone a sweater, are you expected to keep patching it whenever it develops holes?
Jesus. There's so many things wrong with these statements, that I don't know where to start...
OSS is most certainly not a "gift". What a ridiculous thing to say. It's a philosophy and approach of making computers accessible and friendly to use for everyone. It's about building meaningful relationships between people in ways that we can all collectivelly build a better future for everyone.
Seeing OSS as a plain transaction, where users should have absolutely no expectations beyond arbitrary license terms, is no better than publishing proprietary software. Using it to promote your brand while ignoring your users is a corruption of this philosophy.
> Then why can't it be maintained by someone else in the case of using the old free version?
I addressed this in my previous comment.
> Sure, the ones that depend on a huge npm transitive dependency cone can. But libraries or frameworks like htmx and Datastar are not like that
Eh, no. Libraries with less dependencies will naturally require less maintenance, but are not maintenance-free. Browsers frequently change. SDK language ecosystems frequently change. Software doesn't exist in a vacuum, and it is incredibly difficult to maintain backwards compatibility over time. Ask Microsoft. In the web world, it's practically impossible.
> What impact? One guy [...]
Yeah, fuck that guy.
> Everything else we've seen in this thread is pile-ons.
Have you seen Reddit? But clearly, everyone who disagrees is "piling on".
> Aren't you doing the same thing? You have been ignoring and dismissing the feedback that this is actually not that big of a deal. Why do you think that your opinion carries more weight than that of the actual maintainers and users of the project?
Huh? I'm pointing out why I think this was a bad move, and why the negative feedback is expected. You can disagree with it, if you want, but at no point did I claim that my opinion carries more weight than anyone else's.
Ive made similar points to the maintainers. It is what it is at this point.
But, honestly, to the people who actually understand, like and use Datastar, none of this matters. Most of the outrage is performative, at best - as can be seen by the pathetically superficial quality of the vast majority of criticisms in threads like this.
Frankly, if people can't/won't see that the devs are very clearly not VC rugpull assholes, and that the vast majority of the functionality is available for free, then they're probably also the sorts of people who aren't a good fit for something that is doing a great rethink of web development. The devs very explicitly are not trying to get rich (nor can they, due to the 501c3!) nor do they want this to be something massive - they're building it for their own needs, first and foremost, and for those who understand that vision.
> But no, the datastar dev somehow move a portion of the freely available features behind a paywall. What the fuck.
Bait & Switch. They're in their right to do it, but it's a bad move, and nobody should use their project^M^M^M^Mduct anymore.
and youre in your right to fork the pre-pro versions of the now-pro plugins, update them to be compatible with the current version of the open-source course (a surely trivial task) and share them with the world. You can call your plugin pack d-free
I'd rather not get spammed by Bait&Switch projects that turn into products, thank you.
that's just not true, the current ones are a complete rewrite. Use the old way to your heart's content. It's MIT
[flagged]
Yeah, but as the HTMX author said, HTMX sucks! Definitely should use Datastar!
[flagged]
Hah, I downvoted you, without realizing you're the guy.
Thanks for your work, and keep fighting the good fight!
i'm afraid this is rather the quality of a non native writer, sorry we are not all from the mother US of A
I'm not referring to the language barrier - I live in a place where I write and speak at a juvenile level. I'm referring to the very low quality of thinking on display in the article, and in this reply (english is not from the US of A. And, moreover, the level of literacy in that country is nothing to envy)
Here's a HN post from today for a coherent article about the same topic: https://news.ycombinator.com/item?id=45536000
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.