[HN Gopher] Datastar: Web Framework for the Future?
___________________________________________________________________
Datastar: Web Framework for the Future?
Author : 1659447091
Score : 142 points
Date : 2025-04-11 16:53 UTC (6 hours ago)
(HTM) web link (chrismalek.me)
(TXT) w3m dump (chrismalek.me)
| CharlesW wrote:
| The TODOS mini application at data-star.dev is slow and doesn't
| work correctly for me (checking/unchecking items isn't reliable).
| To me, this highlights one common problem I've seen with
| frameworks that insist on doing everything on the server.
| tevon wrote:
| Agreed, I have gig internet and a hardwire connection and still
| get more lag than I'd want from a web app.
|
| Potentially could be solved with some client side cache but
| still..
| sudodevnull wrote:
| Yeah something is DEFINITELY up. This is not the norm, we
| haven't seen this before. Fly.io free tier is not happy and
| I'm not sure why (we've been on it for years at this point).
| I'm gonna disable until I can dig deeper. Have day job stuff
| to attend to, this is not my ideal Friday afternoon :P
| smallerfish wrote:
| If you're on shared CPU you probably got throttled. Dig
| into the grafana dashboard and you'll see it
| somewhere...it's not nearly prominent enough in their UI.
| tasqyn wrote:
| I have the fastest internet in the whole country and I couldn't
| add new todo, also deleting the todo item is very slow.
| macmac wrote:
| Link?
| CharlesW wrote:
| > _data-star.dev_
| sudodevnull wrote:
| Yeah I'm seeing that too. We're getting ready for V1 and I
| probably missed a test around the Todo. My fault, didn't think
| we'd get hit by hackernews on a free shared fly.io server. I'll
| look into it now
| sudodevnull wrote:
| UPDATE: I have no idea why fly.io hate the TODO, but
| https://example.andersmurphy.com/ is a decent example (that's
| way more fun) that's running now. I'm commenting out that demo
| until I have more time to investigate. If y'all find other ones
| that are acting up please let me know. Looks likes it might be
| time to actual host this thing on a real server.
| tcdent wrote:
| > "what is a signal?"
|
| it's another word for event
| evertedsphere wrote:
| a signal is not a single event but rather a stream of events at
| given timestamps
|
| (or, if you wish, a stream where you have an Option<Event> at
| each timestamp)
| peacebeard wrote:
| I googled this and got a few different answers, but not this
| one. Is there a particular implementation you're referring
| to?
| sudodevnull wrote:
| Alien, Reactively, TC39 are all about the core semantics of
| signal, computed, effect. Much of the rest is
| implementation details. https://dev.to/this-is-
| learning/the-evolution-of-signals-in-... is a good intro.
| jmstevers wrote:
| this is how signals are described in the functional
| reactive programming world. here is the paper by the guy
| http://conal.net/papers/push-pull-frp/push-pull-frp.pdf
| sudodevnull wrote:
| I think your confusing signals with observables
| sudodevnull wrote:
| Signals have dependencies and subscribers. It's a value and
| publisher and subscriber if you want to be more correct.
| boogieknite wrote:
| first, great well structured and accessible post.
|
| convinced me to maybe try datastar out next prototype where its
| applicable. reminds me of htmx with hyperscript if hyperscript
| wasnt kind of a joke. to clarify, the author of hyperscript calls
| it a sort-of joke and im not trying to slam it.
|
| ive used htmx and hyperscript for prototyping because its
| entertaining and the novelty is motivating. i found similar
| issues as the author of this post where i talk myself out of
| using htmx for the product by the end of prototyping.
|
| all that said we've been evaluating a react sdk provided by ESRI
| (experience builder) and diving into that makes me stare
| longingly at datastar where it seems like i could use signals to
| update client-side data from 3rd party apis
| j13n wrote:
| This is the second post I've seen praising Datastar in the last
| 24 hours, and once again no mention of the requirement to punch a
| gaping hole in one's Content-Security-Policy.
|
| If this is the framework of the future, cyber criminals are going
| to have a bright future!
| max_ wrote:
| How does this compare to HTMX (security wise)?
| sudodevnull wrote:
| Same, you control your signals and fragments. So you are
| responsible for proper escaping and thoughtful design.
| j13n wrote:
| You can disable all use of eval with htmx. The tradeoff is
| one has to write a bit more JavaScript.
|
| https://news.ycombinator.com/item?id=43650921
| sudodevnull wrote:
| I have thoughts about a fully compliant CSP middleware,
| problem is it's per language so I'd probably only make for
| Go (maybe PHP & TS)
| sudodevnull wrote:
| That's the nature of anything that does this kind of work.
| React, Svelte, Solid. Alpine has a CSP version but it does so
| little that I recommend you just accept being a Web1 MPA basic
| site.
|
| I have ideas around ways around this but it's a per language
| template middleware.
| dpc_01234 wrote:
| Is there anything I could read detailed explanation of issue,
| in particular w.r.t datastar?
| nchmy wrote:
| could you please elaborate on this?
| ilrwbwrkhv wrote:
| The web framework of the future is for better or for worse what
| Vercel and YouTubers talk about.
|
| Original thinking is sorely lacking in the majority of the web
| dev community.
| sudodevnull wrote:
| I hate how right you are. We are now the smallest (v1 is on
| track to be 11.4Kb), have the fastest signal implementation and
| looking like over 2x faster than idiomorph. So it's the
| smallest and fastest shim to build real-time apps or simple
| CRUD. Shocked how much tech world is vibes based but so be it.
| rphumulock wrote:
| Guess we just gotta get some new YouTubers to cover other
| things then :)
|
| There was a funny convo about this a bit
|
| https://www.youtube.com/watch?v=y79L3fhJI3o&t=8636s
| johndevor wrote:
| Also worth checking out is the recent release of RedwoodSDK:
| https://news.ycombinator.com/item?id=43657215
| imjonse wrote:
| Oh good, they finally realized GraphQL was holding them back.
| devrandoom wrote:
| > fresh perspective, embracing server-driven architecture
|
| This is not fresh perspective. I used to be on "team everything
| on server" but it's a mistake on insist on that today.
| sudodevnull wrote:
| I think, at least as the creator, I've seen the "fight" be MPA
| vs SPA. IMO, both are wrong. It's about state management. MOST
| state lives in the backend but you still need fine grain
| reactivity on the frontend. On the number line between React
| and HTMX; Datastar is complex :)
| candiddevmike wrote:
| Data may live in the backend, but it is used more in the
| frontend. Having it local (in memory, or even indexeddb)
| makes more responsive apps, especially if it's a typical CRUD
| app with 70/30 or more split between reads/writes.
| sudodevnull wrote:
| We'll just have to disagree here. The browser is REALLY
| smart about caching and no amount of JS localStorage is
| gonna match proper E-Tags and CDNs. If it's dynamic content
| your point is moot anyways.
| matt_s wrote:
| Where the data is used most will vary by app. Some
| applications are really heavy in the backend, dealing with
| integrations to other systems, file processing, etc. and
| the UI is for setting up all that processing, some
| workflows and business logic.
| nchmy wrote:
| Its possible to run the datastar TS/JS SDK in a service
| worker, if you want to do (isomorphic with the backend)
| templating from there or just returning pre-cached html
| fragments.
| sudodevnull wrote:
| Datastar author here... AMA, but know that Datastar is pure yak
| shaving for me to do real work stuff so I have no golden calves,
| just approaches I've seen work at scale.
| theboywho wrote:
| What do you think about the Hotwire stack (Stimulus, Turbo) as
| compared to Datastar ?
| andersmurphy wrote:
| So I've used Turbo 8 to make a multiplayer app using a non
| rails backend. It was a struggle, the docs are incomplete. I
| mostly pieced things together from what others have done and
| written about. Which, is ironic considering your point about
| having a massive community behind it. The nice thing about
| Turbo 8 is morph (it uses idiomorph like datastar). It's also
| got a pretty simple refresh model.
|
| However, you quickly realise the limitation. You can even see
| this in the Turbo 8 demo (see this issue
| https://github.com/basecamp/turbo-8-morphing-demo/issues/9).
| You can try to fix this with `data-turbo-permanent` but
| you'll now run into another issue that you can't clear that
| field without resorting to JavaScript. Which, brings me to
| the next thing, I found I was still writing quite a bit of
| JavaScript with turbo. Like HTMX pushes you to use
| alpin.js/hypercript turbo pushes you to use Stimulus.js.
|
| Turbo.js is not push based it's mostly polling based. Even
| when you push a refresh event, it pushes the client to re-
| fetch the data. Sure this is elegant in in that you re-use
| your regular handlers but it's a performance nightmare as you
| stampede your own server. It also prohibits you from doing
| render sharing between clients (which is what opens up some
| of the really cool stuff you can do with datastar).
|
| I was using turbo.js with SSE so no complaints there. But,
| most turbo implementations use websockets (which if you have
| any experience with websockets is just a bad time: messages
| can be dropped, no auto reconnect, not regular http, proxy
| and firewalls can block it etc).
|
| Finally, according to the docs Turbo Native doesn't let you
| use stream events (which is what gives you access to refresh
| and other multiplayer features).
|
| I like turbo, I'd use it over react if I was using Rails. I
| use it for my static blog to make the navigation feel snappy
| (turbo drive). It gives you a lot without you having to do
| anything. But, the minute you start working on day 2 problems
| and you are not using rails the shine fades pretty quickly.
| There are 3 ways to do things, frames, streams and morph.
| None of them are enough to stop you having to import stimulus
| or alpine and honestly it's just a bit of a mess.
|
| If you need help with turbo the best blogs posts are from
| (Radan Skoric https://radanskoric.com/archives/).
|
| Specifically these:
|
| https://radanskoric.com/articles/turbo-morphing-deep-dive-
| id...
|
| https://radanskoric.com/articles/turbo-morphing-deep-dive
|
| I think he's also got a book on turbo he's releasing soon (if
| you go with turbo it's probably worth getting).
|
| Those posts helped me grok Torbo 8 morph and ultimately what
| sold me on datastar. Morph, signals and SSE is all you need.
|
| As for mobile I'll just wrap it in a webview (as an X native
| mobile dev I can tell you it will lead to a lower maintenance
| app than native or react native).
|
| TLDR: datastar solves all the problems I ran into with turbo
| and more. It's faster, smaller, simpler, more examples,
| better docs and easier.
| sudodevnull wrote:
| Not a fan (andersmurphy actually is better at explaining than
| me). However! I've been working with Micah from the Turbo.js
| team on idiomorph ideas. We are already multiples of v0.7.3
| right now and getting faster each day. Together we can solve
| the core ideas even if we disagree on the top level API.
| vb-8448 wrote:
| Doesn't it make stateful the whole stack?
| andersmurphy wrote:
| If you want a solid demo of what you can do with datastar. You
| can checkout this naive multiplayer game of life I wrote earlier
| in the week. Sends down 2500 divs every 200ms to all connected
| cliends via compressed SSE.
|
| https://example.andersmurphy.com/
| CharlesW wrote:
| Is sending 10,000 divs/sec the right solution for this problem,
| or is this an "everything looks like a nail" solution?
| andersmurphy wrote:
| It's deliberately naive. But brotli and a tuned compression
| window over SSE means it gets 150-250:1 compression ratio,
| combined with Datastar rendering speed and you can get away
| with it.
|
| The reason it's naive is although you can use datastar to
| drive SVG, a canvas or even a game engine the minute you do
| people think you are doing magic game dev sorcery and dismiss
| your demo. I wanted to show that your average crud app with a
| bunch of divs is going to do just fine.
|
| I break it down in this post.
|
| https://andersmurphy.com/2025/04/07/clojure-realtime-
| collabo...
| wavemode wrote:
| This is a Wirth's Law solution - the reasoning goes:
| "computers are fast enough to deal with it, so why not?"
| andersmurphy wrote:
| But, you can learn a lot doing dumb stuff. I learnt a lot
| about compression.
|
| If you go to google chrome and throttle the site to 3G it
| will still run fine.
|
| Rendering on the server like this will be faster for low
| end devices than rendering on the client (as the client
| doesn't have to run or simulate the game). It just gets raw
| HTML it has to render.
|
| Effectively, the bulk of the work on the client will be
| done by the browser native rendering code and native
| compression code.
|
| The other thing that might not be obvious. Is #brotli
| compression is not set to 11, it's set to 5 so similar CPU
| cost to gzip. But, the compression advantage comes from
| compressing the SSE stream. Tuning the shared window size
| cost memory on client and server but gives you a
| compression ratio of 150-250:1 (vs 30:1), at the cost of
| 263kb on both server on client (for context gzip has a
| fixed window of 32kb). This not only saves bandwidth and
| make the game run smoothly on 3G it also massively reduces
| CPU cost on both client and server. So it can run on lower
| end devices than a client heavy browser app.
|
| So server driven web apps are better for low end devices.
| The same way you can watch YouTube on a low end phone but
| not play some games.
| sudodevnull wrote:
| I'm am not of that opinion at all. I'm all about
| optimization but then people will say "that's not how web
| pages are made". Can't win opinions but can say, Datastar
| is not the bottleneck. You send as much, as often as you
| choose.
| danesparza wrote:
| "Sends down 2500 divs every 200ms to all connected cliends via
| compressed SSE."
|
| If I didn't know better, I'd say this was an April Fool's joke.
| sudodevnull wrote:
| It's a DOM render stress test. It's trying to show the
| network is not the bottleneck. TL;DR do this in React or any
| other framework compared to a one time tiny shim and see if
| you get better results.
| kaycebasques wrote:
| Wow, I've never done multiplayer GoL. Simple yet addictively
| fun. LONG LIVE THE ORANGE CIVILIZATION!!
|
| edit: damn, purple civilization got hands
| sudodevnull wrote:
| May the Yellows never forget
| thanhnguyen2187 wrote:
| Really well-written and well-structured post! I'll seriously
| evaluate Datastar in my next toy project because of the author's
| praises!
|
| For people who are looking for HTMX alternatives, I think Alpine
| AJAX is another choice if you are already using AlpineJS
| nz3000 wrote:
| I've been working with datastar for a bit now and have really
| been enjoying it. If you are looking to try it out, I created a
| boilerplate template that distills some of the examples from the
| datastar site to get up and running with:
|
| https://github.com/zangster300/northstar/tree/main
| midzer wrote:
| The future is frameworkless.
| sudodevnull wrote:
| I agree! That's kinda the point with Datastar. EVERYTHING is a
| plugin, the core is a < 300 LOC engine for parsing data-*
| attributes and making available to plugins. You can pick and
| choose what makes sense for you. If you want to have
| declarative spec compliant interfaces, it can't get any smaller
| from what I've seen in the wild. Happy to get help to shrink it
| even more!
| danek_szy wrote:
| Betteridge's law of headlines? ;)
|
| [1]
| https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
| Mister_Snuggles wrote:
| The section on the author's background could have almost been
| written by me. I'm also a PeopleSoft developer, and the ability
| to build fully-functional CRUD apps without needing to know about
| HTML, JavaScript, Browsers, etc, is severely underappreciated.
| For very simple CRUD pages, no code is required. For developing
| line-of-business apps it's actually an incredible toolset.
| 65 wrote:
| https://www.youtube.com/watch?v=0K71AyAF6E4
|
| I found this talk really interesting. It's a cool framework for
| very interactive applications.
| bitbasher wrote:
| Correct me if I'm wrong, but isn't half the point of htmx to
| allow for adaptive web design (ie, if js fails to load or is
| disabled it can still function via the form submission)?
|
| It seems like Datastar is doing away with that entirely and
| binding the UI more tightly to JavaScript to function correctly.
| sudodevnull wrote:
| I'm very much of the opinion that progressive enhancement leads
| to lowest common denominator and you should just do a static
| MPA (nothing wrong with that). Modern browsers are a
| combination of HTML+CSS+JS and you should just embrace that as
| what modern hypermedia is. We aren't fighting against the
| browser. If you want just links and forms, you should just do
| that and have less code to maintain. But in my experience
| that's not what most are looking for in their apps.
| bitbasher wrote:
| > But in my experience that's not what most are looking for
| in their apps.
|
| What are they looking for (in your experience)?
|
| In my experience, most people use an app (website) to solve
| some problem (buy something, pay taxes, whatever). They care
| more about functionality than how smooth the loading
| animation and transition was. Progressive enhancement seems
| like a very good way to build something people actually use
| (and rely on).
| timewizard wrote:
| My impression is people really like frameworks because they
| all ultimately end up with a plugin system. Then the use of
| the "the framework" really just becomes "gluing a bunch of
| plugins together."
|
| I've never liked where those code bases ultimately end up,
| which seems to be just a twisted maze of hacky solutions to
| make a bunch of poorly aligned code to work together.
| airmail wrote:
| I'll just leave this here. At first you might be afraid, or
| petrified. But then you'll realize how you cannot live without
| this by your side.
|
| https://gonads.net/
| dpc_01234 wrote:
| This matches 100% my experience and thoughts.
|
| I really enjoy HTMX and it's a blessing for my small-scale
| reactivity web interfaces, but I can immediately tell: "Well,
| this is hard to organize in a way that will scale with complexity
| well. It works great now, but I can tell where are the limits".
| And when I had to add alpine.js to do client-side reactivity, it
| immediately was obvious that I'd love to have both sides (backend
| and frontent) unified.
|
| Still need more time opportunities to roll some stuff with
| datastar in it, but ATM I'm convinced datastar is the way to go.
|
| For reference, my typical "web tech stack": Rust, axum, maud,
| datastar, redb.
| Alifatisk wrote:
| Cool, it even has a ruby sdk, gotta check it out!
| imiric wrote:
| This looks really good. Kudos to the authors!
|
| It's great seeing a rise of web stacks that embrace small
| libraries and native web technologies, and reject mega monolithic
| frameworks. It's about time the industry moved away from the
| React/Vue/npm insanity.
|
| I'm also intrigued by Nue, but Datastar fits nicely in a full
| stack solution. The choice of SSE is brilliant. It's great tech
| that's generally underutilized.
| PaulHoule wrote:
| ... was kinda inevitable that HTMX was going to bring about a
| Cambrian explosion in frameworks like the one it was built to
| escape.
___________________________________________________________________
(page generated 2025-04-11 23:00 UTC)