Datastar: Lightweight hypermedia framework for building interactive web apps
data-star.dev299 points by freetonik 3 days ago
299 points by freetonik 3 days ago
Datastar is run by some principled (and opinionated) guys who are immensely generous with their time and supportive to newcomers.
What’s getting lost in the whole kerfufflw over the Pro version is that this is NOT a monetization strategy. There is no intent to hook you - in fact they go out of their way to tell your you don’t need it. And the company is a registered non-profit.
Based on their own extensive experience they know which tiny set of features are likely to appeal to a very small group of people and at the same time are likely to incur the vast majority of support burden. By keeping these features out of the core they keep the base product simple and universal.
It is in fact an innovative and fair way of (a) signaling that these features are likely footguns, (b) getting just some of their costs covered by the people who either need the most support or are getting so much value from Datastar that they’re paying, (c) thereby freeing up their time to spend on the larger community.
data-animate - Animates element attributes over time.
data-on-resize - Runs an expression on element resize.
data-scroll-into-view - Scrolls an element into view.
I don't have any problem with them charging for whatever they want to. But let's not make up excuses.
1. You should be using CSS for animations
2. You should be using data-on to listen to the window level resize event (which doesn't require a pro plugin).
3. Scroll element into view can be replicated with data-on-load="el.scrollIntoView()"
The main benefit of pro is supporting the project.
> You should be using CSS for animations
CSS can only animate appearance, not HTML attributes like the `value` of a `<meter>`
> You should be using data-on to listen to the window level resize event
That event is fired when the window is resized, not when an element is resized
Copy-to-clipboard is a support heavy feature?
Do you really think Datastar is of such ridiculously bad quality that even simple features require a lot of support to get working?
Use the Navigator API directly then? Why do _need_ a declarative version of it?
I implemented copy to clipboard in datastar in maybe 1 minutes with an AI agent. What exactly are you providing to the world for free?
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.
> They have all survived the front page of HN
Right but this says “bring your own backend” in big letters on the splash page. So surviving HN isn’t really something Datastar is doing here.
Sure. You're not wrong. I'd argue Datastar's fat morph model is what lets me write a much simpler backend that's amenable to batching/better compression. It's also fast enough on the client that this immediate mode style rendering of HTML is actually possible.
I'm also not doing anything fancy on the backend, I'm using a dynamic language not known for it's speed (Clojure). Really, most of the work here is being done by SQLITE, batching, and brotli compression, which you can all use from any language.
I will concede that languages with access to real threads (GO, JAVA, C# etc) do better out of the box for this kind of CQRS architecture.
I don't understand what point you're trying to make.
He shared examples of some immensely dynamic apps that are running on a potato and survived HN, showing that this simplifies things greatly and can scale. Hypermedia-first is a very viable, and simplified, approach.
I think my point is pretty straightforward. Datastar is a front end framework. If any frontend framework can’t survive HN traffic it’s doing something wrong in a truly unholy way.
Surviving, or not surviving, a traffic influx is a backend restriction.
It's a frontend framework and a backend SDK in multiple languages, for SSE and more.
Data star is a backend agnostic backend framework that happens to have a 10kb on the frontend. You should probably read the guy before coming to conclusions on what it is
And yet, most frontend frameworks barely on even the simplest of sites. This is not only well documented, but most of them have now moved towards some sort of SSR hybrid - at great complexity cost.
I disagree with “most”. 99% of the sites featured on HN do just fine.
OP is a talented developer that wrote a backend capable of surviving a ton of traffic. Other developers on the internet have written backends that cannot sustain a ton of traffic.
The choice of frontend framework is separate from both. You can write a performant web app that uses React. I’m sure you can write one that falls over immediately with Datastar.
Thank you for the kind words.
I think for me the key thing is Datastar lets me keep most of my state on the backend, which makes the backend much simpler to write. It also lets me do immediate mode streaming of the HTML, which again is non trivial in something like react without a lot of added complexity.
So it's an enabler in that sense. But, yes it's totally possible to write a backend that falls over with datastar like any technology.
I also agree, that Datastar does benefit from backend experience and if you don't have that experience it can to some extent feel like:
"Draw some circles. Now draw the rest of the Owl".
That's a fair point.
But I think that the real point that /u/andersmurphy was trying to convey was that hypermedia is VERY performant because immensely talented C++ engineers have optimized precisely this, for decades. The notion that "frontend" devs have that the DOM can and must be managed via JS is simply ridiculous, and is one of the primary things that datastar and hypermedia approaches in general are trying to combat.
In fact, he openly states elsewhere how the sites' backends are actually done in a deliberately dumb, unperformant way, where the backend streams the ENTIRE DOM with each sse message, which gets morphed into the DOM. He could have done something more granular, like streaming only the checkboxes that have changed, but it wasn't at all necessary because the dumb way worked well.
Moreover, the SSE streams benefit from immense compression ratios because somehow the compression window overlaps across messages. Something like 95+%, IIRC.
> The notion that "frontend" devs have that the DOM can and must be managed via JS is simply ridiculous
The idea that UI state should be managed locally is ridiculous now?
Its interesting, and telling, that that's the only part of my comment that you replied to...
Anyway, browsers are built specifically to render HTML. And html/hypermedia is specifically meant to manage and transfer state. The web has lost its way. If you want to read more about this, this free book is a great start: https://hypermedia.systems/book/contents/
Or the essays at HTMX https://htmx.org/essays/
Good luck to you