[HN Gopher] Datastar: Web Framework for the Future?
___________________________________________________________________
Datastar: Web Framework for the Future?
Author : 1659447091
Score : 241 points
Date : 2025-04-11 16:53 UTC (1 days 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_
| macmac wrote:
| Oh I know what happens, the todo app was removed from the
| front page.
| 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)
| geoka9 wrote:
| Hashes or nonces?
| sudodevnull wrote:
| Hashed script content
| geoka9 wrote:
| Thank you for doing this. Is it possible to follow the
| work somewhere?
| sudodevnull wrote:
| Not right now. CSP in a Datastar context is mostly a red
| herring. If an enterprise wants it to check a box then
| please reach out.
| 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?
| jazoom wrote:
| Alpine CSP version works fine. You just can't write JS code
| in strings, which one may wish to avoid anyway.
|
| I also didn't have a problem with CSP and HTMX.
|
| Nor with SvelteKit.
|
| I'm not sure why you think these are all equivalent to
| DataStar's hard requirement on unsafe-eval.
|
| FYI, this is the reason I didn't try out DataStar.
| pie_flavor wrote:
| Svelte only requires a CSP hole in its default config as a
| standalone library; SvelteKit does proper CSP by default, and
| if you're not using SvelteKit you can build CSP handling into
| whatever you are using instead. I assume the others are the
| same way.
| tauroid wrote:
| Could you avoid eval by having a CSP mode that forces
| reactive expressions to only allow functions users have
| registered with datastar in a lookup table?
| nchmy wrote:
| could you please elaborate on this?
| andersmurphy wrote:
| Please don't cargo cult CSP without understanding it.
|
| unsafe-eval constrained to function constructors without inline
| scripts is only a concern if you are rendering user submitted
| HTML (most common case I see is markdown). Regardless of your
| CSP configuration you should be sanitizing that user submitted
| HTML anyway.
| 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.
| aiiizzz wrote:
| Haha, didn't realize redwood was already deprecated and forked
| into redwoodsdk under new management.
|
| Looks good though, like remix except without those pesky route
| handlers. Then again I didn't get around to using the RR
| version. I wish the doc had a "differences with RR" section
| 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 is fully plugin based. If you don't like my take
| on SSE, cool let's talk. The core is just making data-*
| attribute into reactive expressions, everything else is a
| plugin by design. I want it to be OK for me to be wrong
| without losing the declarative approach
| nchmy wrote:
| Did you mean to respond to another comment? Because I'm
| not following either the relevance or tone of your
| comment.
|
| The parent comment wanted a way to "serve" requests on
| the client device, so I suggested a way to do that that
| is also compatible with normal d* usage...
|
| How to get the data to the client and keep it in sync is
| an entirely other problem that they'd face with any
| framework/approach. Would be foolish for some
| applications and perfectly possible for others.
| Offline/local-first apps are getting considerable
| attention these days, for good reason.
|
| I'm a big fan and cheerleader of everything you've done.
| Keep up the great work.
| 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?
| buangakun wrote:
| Hello, I've heard of Datastar before but didn't really pay
| attention to it since all the air in the room was sucked up by
| HTMX.
|
| I tried HTMX and I found that it is really, really hard to
| manage complexity once the codebase gets big.
|
| Is there an example of Datastar being used with Go in a highly
| interactive application that goes beyond just a TODO app so I
| could see how the project structure should be organized?
| sudodevnull wrote:
| the site is just a Go app,
| https://github.com/starfederation/datastar/tree/develop/site
| buangakun wrote:
| Amazing! Thank you.
| whalesalad wrote:
| oh my
| postepowanieadm wrote:
| So how are your server bills? Does Datastar supports
| caching/prerendering?
| andersmurphy wrote:
| So being on the front page of hacker news twice in 24 hours.
| The multiplayer game of life game is running on a
| 15.59$/month 4 core AMD 8GB ram shared VPS (hetzner) and only
| at about 30% load. That's with a Clojure backend running very
| naive code.
| mattgreenrocks wrote:
| I believe it. Part of the issue I suspect is that
| generation JS truly does not understand how fast the old
| school GC'd runtimes (e.g. JVM/CLR) are at this point.
| api wrote:
| It reminds me of the articles you see from time to time
| about how someone successfully moved _millions_ of rows
| of data in the cloud for less than a hundred dollars or
| some such absurdity.
|
| It'd be hilarious if it weren't so deeply discouraging
| and tragic.
|
| You might have heard of Eroom's Law, which is Moore's Law
| backwards. It states that software bloat will soak up all
| gains from Moore's Law.
|
| Well, with cloud we now have a whole industry with an
| economic incentive to put Eroom's Law into practice,
| since cloud makes more money the more inefficient things
| can become. So to do what a simple local app could do in
| a minute must now be done across five different services
| with microservice backends, etc.
| andersmurphy wrote:
| It's not just the performance, it's that there is a lot
| less ecosystem churn. I can run Clojure/Java code I wrote
| 10 years ago and it will still work.
| 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.
| akdor1154 wrote:
| > 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.
|
| I'm not sure about that - it's a hypothesis with merit,
| but as an anecdote, my Firefox on a new reasonably beefy
| Android gets quite laggy and unresponsive.
| andersmurphy wrote:
| That's the number of divs combined with the CSS
| transition animation on each cell. If I remove the
| animation on each cell it runs much better on lower end
| devices (looks a lot worse though). In general though
| older devices can't handle as many cells.
|
| I'm sure you can write hyper specific hand tuned code for
| this example that will run better, but you'll lose all of
| the flexibility (and you have to load that hand tuned
| code first too). I could send down purely a string of
| data and have either an expression swap classes or wrap
| it in a web component (you can do both in Datastar). But,
| in short passing json and running your logic on the
| client adds up.
|
| Like anything though test and measure.
| disgruntledphd2 wrote:
| Really? That's interesting. On a Pixel 7 with FF, it all
| renders nicely. A tiny bit of heat but that went away.
| 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
| jgalt212 wrote:
| your server logs are going to be an intelligible mess. This
| framework will be a yuge money maker for AWS CloudWatch.
| andersmurphy wrote:
| Tell me more!
| 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
| sudodevnull wrote:
| Ian is great, if you want progressive enhancement it would be
| my go-to every time!
| 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.
| pie_flavor wrote:
| Progressive enhancement is about accommodating JS being
| disabled. You have missed, in your description of what
| users care about, anything about disabling JS. Having JS
| disabled is a preference observable among Opinion Havers
| which crawl out of the woodwork on HN, but not observable
| among your target audience, even when your target audience
| is mostly HN.
| bitbasher wrote:
| Progressive enhancement isn't about supporting the
| minority of users that disable JavaScript. It's about
| sound engineering and building a robust system that is
| tolerant to errors. A system that can fail gracefully.
|
| There's nothing wrong with using JavaScript. There's
| nothing wrong with depending on JavaScript for specific
| functionality. However, I don't think it's acceptable to
| completely break down if that JavaScript fails to load.
|
| With SPAs and "modern" web development practices, it's
| all or nothing. Either everything works, or nothing
| works.
|
| Not with things I build.
| 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.
| naasking wrote:
| > 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.
|
| https://alpine-ajax.js.org/
| 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.
| sudodevnull wrote:
| Datastar started as an attempt to help shape HTMX2 before that
| was a thing... https://github.com/delaneyj/nothtmx2
|
| Not sure the negativity. It's a superset of HTMX and it's 40%
| smaller with more features. Can you please tell me issue? I'm
| to dumb dumb grug please teach me senpai
| devnull3 wrote:
| It will still be much lesser than perma Cambrian explosion in
| js frameworks.
|
| Infact, a lot of the patterns in the likes of HTMX will be
| standardised.
| rodolphoarruda wrote:
| I just wanted to say I love this entire "ecosystem", if I may
| call it. Hypermedia is cool. HTMX looks like the natural
| evolution of HTML we all were expecting from the 90s. The
| simplicity of hx tags and the fact they get the work done is
| really refreshing. Datastar looks promising as well. It is
| already on my radar for a hobby project. Kudos to the dev team!
| dalmo3 wrote:
| Reading tfa I kept wondering "is this yet another framework where
| every click is a server round trip?" Judging by the demos1, the
| answer is yes?
|
| If this is "the Future", I'm branching off to the timeline where
| local-first wins.
|
| 1. https://data-star.dev/examples/click_to_edit
| sudodevnull wrote:
| Our free shared fly.io was not built to handle hackernews. We
| are looking into alternatives but in the mean time checkout
| https://andersmurphy.com/2025/04/07/clojure-realtime-collabo...
| as it's the same tech but on a slight better machine.
| tipiirai wrote:
| A JavaScript framework, built by a person who hates JavaScript
| doesn't sound right
| hsbauauvhabzb wrote:
| With additional swipes at ecosystems and 'must be written in
| go' with no real justification as to _why_ more than the
| developers preference
| throwaway519 wrote:
| Robust performance, error handling that's not stuck in
| 1982, and cross platform would be my guesses, but agree the
| OP could be more spicific as there _are_ more benefits.
| throw1223323 wrote:
| I hate Go as much as anyone, but it has incredible cross
| platform support.
|
| There's built in cross compilation for building a static
| binary across window/mac/linux.
|
| It's the number 1 feature in Go, lol.
| PufPufPuf wrote:
| By "error handling" in Go you mean "if err == nil"
| repeating every five lines throughout the codebase?
| mdhb wrote:
| I am not in any way "pro go" but it's also very clear that
| JS is not the future. I know it's where a LOT of people are
| right now but it's been artificially pumped up to such a
| massive degree by being literally the only viable choice
| for the web for the entirety of its existence... and that's
| starting to change and from both a technical, performance
| and development experience it is going to lose when that
| advantage goes away.
| joshstrange wrote:
| > also very clear that JS is not the future
|
| I assume you are talking about WebAssembly/WASM/etc?
|
| Foreword: I'm not super up-to-date on the state of these
| things, I'll refer to to as WASM from here on out but if
| that's not the right term then substitute it for
| "whatever it is that lets you write code, compile it to
| something that runs in the browser that isn't JS".
|
| I don't think the future is clear at all. Honestly, I'd
| expect to see some kind of "Compile your JS ahead of time
| to this WASM bundle" before we see web developers
| switching over in droves to some other language that can
| be compiled to WASM.
|
| Unless you take over full rendering, my understanding is
| you have to provide some kinds WASM<->DOM bridge to
| interact with it, my knowledge may be dated.
|
| I write web apps in Javascript (Typescript), real "apps",
| not "everything should be a SPA just because", and would
| be interested in anything that improves performance
| and/or developer experience. There are some data-
| crunching operations that might run faster in something
| WASM and/or some aspects that I'd love to share between
| client and server (and the server can't run JS in this
| case). That said, everything I have seen is a significant
| downgrade in developer experience for something that is
| semi-supported.
|
| I look forward to WASM support maturing and the developer
| experience improving. To my knowledge there is not a
| Vue/React-WASM-type framework out there yet or any
| framework for building web apps in WASM (without starting
| from a blank canvas).
| rapnie wrote:
| > To my knowledge there is not a Vue/React-WASM-type
| framework out there yet or any framework for building web
| apps in WASM (without starting from a blank canvas).
|
| Not sure if these qualify, but these Rust web frameworks
| use wasm:
|
| https://dioxuslabs.com/
|
| https://leptos.dev/
|
| https://yew.rs/
| sudodevnull wrote:
| Use whatever backend language you want. No justification
| needed when it's agnostic, even, shocker, JS
| infamia wrote:
| idk if I'd put it quite that strongly. https://data-
| star.dev/examples/dbmon
|
| Also, multiplayer for free on every page due to SSE (if you
| want it).
| fbn79 wrote:
| Every time I read "Web Framework" I run.
|
| Ripley: These techs are here to protect you. They're
| frameworks.
|
| Newt: It won't make any difference.
| andersmurphy wrote:
| Here's the thing datastar isn't really a framework in the
| traditional sense (ruby on rails), you can bring your own
| backend and use it in a variety of ways. I use it a push
| based CQRS style, but you just as easily do request/response,
| hell even polling if that's your thing.
| zamalek wrote:
| I think the happy place is somewhere in-between. Use JS to
| allow the user to build up a request/form (basically DHTML
| circa 2000), but use one of these hypermedia frameworks when
| interacting with the server. I think that these are
| successfully showing that BFFs were a mistake.
| tauroid wrote:
| Counterexample with just local signals: https://data-
| star.dev/guide/getting_started#data-on
| resonious wrote:
| Nitpicking but
|
| > SSE enables microsecond updates, challenging the limitations of
| polling in HTMX.
|
| How is this true? SSE is just the server sending a message to the
| client. If server and client are in opposite sides of the world,
| it will not be a matter of microseconds...
| ivanjermakov wrote:
| Reminds me of the joke "hey, check out the website I just made:
| localhost:8080"
| sudodevnull wrote:
| Well obviously there's a difference between latency and
| throughput. Of course it's going to be microsecond plus your
| rtt/2. Sorry, we can't beat physics.
| recursive wrote:
| Everyone knows no one can beat physics. That doesn't excuse
| claiming you can beat physics.
| andersmurphy wrote:
| Latency doesn't affect server update rate it affects time
| to first data. I can have a ping of 500ms and still get an
| update from a stock ticker every 5 milliseconds. They will
| arrive at 500 505 510 etc.
| recursive wrote:
| I think most people would have a different understanding
| of what's entailed in an "update".
| andersmurphy wrote:
| The original bit from the datastar website that was
| quoted was talking about polling.
| recursive wrote:
| I'll take your word for it, as I can't find the quote in
| context.
|
| But I'm unfamiliar with any polling pattern where poll
| requests are expected to overlap. If updates take
| microseconds, does that mean I can comfortably run 10,000
| of these in a second?
|
| I even think datastar looks cool, but I just think that
| quote is misleading, and I still think that.
|
| I'd like to see some realistic results, like the kind
| measured by this[1] type of benchmark. "Microsecond"
| updates sounds like microbenchmarks with very carefully
| crafted definitions.
|
| [1]: https://krausest.github.io/js-framework-
| benchmark/2025/table...
| zdragnar wrote:
| > Sorry, we can't beat physics.
|
| In a way, you can with optimistic updates. That requires
| having a full front end stack, though, and probably making
| the app local-first if you really wanted to hammer that nail.
|
| There's always the cost of the round trip to verify, which
| means planning a solid roll-back user experience, but it can
| be done.
| throwaway519 wrote:
| Can't beat physics but can write better copy.
| andersmurphy wrote:
| Latency doesn't affect server update rate it affects time
| to first data.
| andersmurphy wrote:
| You can have microsecond updated, once the connection is
| established you can stream. Regardless of your latency.
|
| Say your ping is 100 (units are irrelevant here). It will take
| you 100 before you see your first byte but if the server is
| sending updates down that connection you will have data at
| whatever rate the server can send data. Say the server sends
| every 10.
|
| Then you will have updates on the client at 100 110 120 130
| etc.
| xyzzy_plugh wrote:
| That's still 100 irrelevant units later than the server sent
| the update. This is like saying the first byte of the packet
| takes 100ms to arrive but the subsequent bytes in the packet
| are instant!
|
| It's not quite right. You'll never have updates in
| microseconds even if your ping is, say, 7ms.
|
| At best you can be ~2-4x as fast as long polling on HTTP/1 --
| an order of magnitude is a ridiculous statement.
| sudodevnull wrote:
| You're right! 200-400% faster is so useless.
| brap wrote:
| Future? Looking at some of the examples, this seems a lot like
| the same old web server frameworks we had like 15 years ago,
| maybe more. Granted they didn't have SSE but regardless the DX
| was pretty bad. I don't see a compelling reason to go back.
| sesm wrote:
| People with 15+ years of experience are not the target audience
| for this framework.
| andersmurphy wrote:
| I'd argue the opposite.
|
| I feel if anything Datastar is targeted ad veteran devs who
| are done with endless ecosystem churn, who want to use their
| favorite backend language and to make performant fullstack
| realtime collaborative apps.
|
| If you haven't run the gauntlet you probably won't see the
| appeal.
| mrbluecoat wrote:
| > Did I mention I hate javascript ... Avoid Javascript ...
| Javascript makes me queezy ... I broke out in hives because I
| hate JavaScript
|
| Web development may not be your thing.
| raggi wrote:
| As you escape the React/JSX intoxification, you can drop the XML
| syntax.
|
| It took us a while back in the day after the XHTML arc, but for
| sure it'll be ok.
|
| I know this looser SGML universe might feel a little kooky, but
| trust me it wears baggy trousers, rocks gifs with a hard g and
| offers great <hugs>. <thank><you>
| <nothankyou/>
| nhumrich wrote:
| I love the idea of datastar, but wonder how does one test it
| without using e2e testing? Also, I think it would be amazing and
| so much simpler if instead of using SSE, it just included all the
| events in a response. Maybe with SSE as an option for those who
| need true server pushes? I feel like most apps don't require
| server push, and instead just need a list of events/things to
| update from an action.
| sudodevnull wrote:
| So unlike HTMX we support merge in both fragments and signals.
| We also support custom events natively for purely local state.
| We just make the browser declaratively reactive, that's it
| memset wrote:
| This is probably a silly question, but how do I use loops? For
| example, if my backend returns an array of TODO items, how can i
| iterate through that and display on the frontend?
| fnord123 wrote:
| Htmx and datastar use backend rendering. So you write the html
| in the backend and serve that. In the case of an array, you
| render them as Todo items.
|
| You might be using a template system for that. E.g. Jinja2,
| moustache, askama, templ, etc depending on your backend
| language and libraries.
| kookamamie wrote:
| Hypermedia. The what now?
| devnull3 wrote:
| On thing about datastar vs htmx: Datastar embraces htmx's OOB
| swap and makes it a first class concept.
|
| HTMX's OOB swap appears to be an after thought.
| udioron wrote:
| From datastar's docs:
|
| _> Backend Setup_
|
| _> Data star uses Server-Sent Events (SSE) to stream zero or
| more events from the web server to the browser. There's no
| special backend plumbing required to use SSE, just some syntax.
| Fortunately, SSE is straightforward and provides us with some
| advantages._
|
| As a django developer, this is very far from true. With htmx i
| get almost no backend changes (mainly in template code), where
| datastar would require me to rewrite it and may not be possible
| to implement at all.
| andersmurphy wrote:
| Sounds like a django over abstraction problem. SSE is standard
| HTTP.
|
| If laravel can do it django can.
| rapnie wrote:
| The other day I bumped again into Markus Lanthaler's hypermedia
| adventures with Hydra [0] "Hypermedia driven web API's" dating
| back from Semantic Web days, and later revived and stalled again
| as the W3C Hydra Community Group [1]. Though very different it
| hinted at the great power of hypermedia at the time. And I am
| very happy to see things getting explored again, in this
| different and refreshing approach. Greatly enjoyed watching the
| interview [2] of Delaney Gillilan on the hypermedia-tv Youtube
| channel.
|
| [0] https://www.markus-lanthaler.com/hydra/
|
| [1] https://www.w3.org/community/hydra/
|
| [2] https://www.youtube.com/watch?v=HbTFlUqELVc
| reneberlin wrote:
| One idea i found interesting on top: why not use a service-worker
| to mock the backend completely (https://mswjs.io/) and mock the
| server answers with the service-worker. Then you still have a
| local-only PWA-style frontend and can choose yourself, how to
| sync it back to a server if you really like or need to.
|
| What datastar is great for is: throw all that overcomplicated
| frontend-junk away and concentrate on the real innovation or
| simply get things done. Not to forget: ignore the dependecy-hell
| of every nodejs-based project you can encounter. After the
| lowcode-initiative, now it's time for the "nodeps"-initiative.
| Deprecate npmjs.com.
___________________________________________________________________
(page generated 2025-04-12 23:02 UTC)