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.
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.
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.
> 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.
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.
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.
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.
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.
This comment implies you've not used Go. It really isn't equivalent to the NPM and dependency hell that's node. Or picking the number of workers in Gunicorn. Or.. C#?
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.
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).
> 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:
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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:
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.
> 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.
> 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...
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.
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.
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.
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.
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.
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.
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.
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!
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!
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.
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.
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?
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.
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.
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.
> 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).
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.
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.
Have you ever given an iota of thought to how your website looks when the CSS doesn't load? Contemplated arranging elements into `<table>`s to preserve some semblance of formatting, crammed some truly necessary styling into `style=`? If not, then the users that disable JS are the primary driver of thinking about how your website looks when the JS doesn't load; any two given files are about equally likely to not load, JS isn't privileged here compared to CSS (and is much harder to gracefully handle its absence).
I do a fair amount of thinking around all failure states (CSS included).
I think you may be overthinking the appearance aspect of a failure state. The application doesn't need to look the same when CSS fails to load. However, the application should be functional.
This thinking carries over to the backend as well. My application server doesn't require all services to be up and running. Instead, it's able to query and tell what is working and what isn't. That information is then bubbled down to the UI in one way or another. That may mean certain functionality is unavailable (ex, if solr isn't reachable then search is disabled).
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.
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 :)
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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.
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.
> 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.
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
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.
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
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.
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?
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
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!
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/
Is sending 10,000 divs/sec the right solution for this problem, or is this an "everything looks like a nail" solution?
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...
This is a Wirth's Law solution - the reasoning goes: "computers are fast enough to deal with it, so why not?"
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.
> 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.
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.
Really? That's interesting. On a Pixel 7 with FF, it all renders nicely. A tiny bit of heat but that went away.
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.
"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.
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.
Wow, I've never done multiplayer GoL. Simple yet addictively fun. LONG LIVE THE ORANGE CIVILIZATION!!
edit: damn, purple civilization got hands
May the Yellows never forget
your server logs are going to be an intelligible mess. This framework will be a yuge money maker for AWS CloudWatch.
Tell me more!
Reading tfa I kept wondering "is this yet another framework where every click is a server round trip?" Judging by the demos¹, the answer is yes?
If this is "the Future", I'm branching off to the timeline where local-first wins.
¹. https://data-star.dev/examples/click_to_edit
Counterexample with just local signals: https://data-star.dev/guide/getting_started#data-on
A JavaScript framework, built by a person who hates JavaScript doesn’t sound right
With additional swipes at ecosystems and ‘must be written in go’ with no real justification as to _why_ more than the developers preference
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.
By "error handling" in Go you mean "if err == nil" repeating every five lines throughout the codebase?
[dead]
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.
So does C#, python, node and a variety of other languages.
This comment implies you've not used Go. It really isn't equivalent to the NPM and dependency hell that's node. Or picking the number of workers in Gunicorn. Or.. C#?
[flagged]
Reread the first comment you responded to. It was talking about cross compilation not error handling
There's no real comparison between Python/Node and Golang's cross-compilation.
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.
> 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).
> 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/
Use whatever backend language you want. No justification needed when it's agnostic, even, shocker, JS
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.
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.
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.
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.
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).
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.
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?
the site is just a Go app, https://github.com/starfederation/datastar/tree/develop/site
Amazing! Thank you.
oh my
What do you think about the Hotwire stack (Stimulus, Turbo) as compared to Datastar ?
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.
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.
Doesn't it make stateful the whole stack?
So how are your server bills? Does Datastar supports caching/prerendering?
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.
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.
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.
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.
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.
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.
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..
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
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.
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
I have the fastest internet in the whole country and I couldn't add new todo, also deleting the todo item is very slow.
Link?
> data-star.dev
Oh I know what happens, the todo app was removed from the front page.
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
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.
> 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/
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...
Reminds me of the joke "hey, check out the website I just made: localhost:8080"
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.
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.
You're right! 200-400% faster is so useless.
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.
> 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.
Everyone knows no one can beat physics. That doesn't excuse claiming you can beat physics.
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.
I think most people would have a different understanding of what's entailed in an "update".
The original bit from the datastar website that was quoted was talking about polling.
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...
Can't beat physics but can write better copy.
Latency doesn't affect server update rate it affects time to first data.
https://www.youtube.com/watch?v=0K71AyAF6E4
I found this talk really interesting. It's a cool framework for very interactive applications.
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
Ian is great, if you want progressive enhancement it would be my go-to every time!
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.
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!
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!
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.
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.
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.
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?
Is there anything I could read detailed explanation of issue, in particular w.r.t datastar?
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.
How does this compare to HTMX (security wise)?
Same, you control your signals and fragments. So you are responsible for proper escaping and thoughtful design.
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
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)
Hashes or nonces?
Hashed script content
Thank you for doing this. Is it possible to follow the work somewhere?
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.
I don't represent an enterprise; just a dev. It would make it easier to sell the idea of Datastar to clients if it was compatible with strict CSP.
could you please elaborate on this?
> 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.
[dead]
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.
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.
> 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).
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.
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.
Have you ever given an iota of thought to how your website looks when the CSS doesn't load? Contemplated arranging elements into `<table>`s to preserve some semblance of formatting, crammed some truly necessary styling into `style=`? If not, then the users that disable JS are the primary driver of thinking about how your website looks when the JS doesn't load; any two given files are about equally likely to not load, JS isn't privileged here compared to CSS (and is much harder to gracefully handle its absence).
I do a fair amount of thinking around all failure states (CSS included).
I think you may be overthinking the appearance aspect of a failure state. The application doesn't need to look the same when CSS fails to load. However, the application should be functional.
This thinking carries over to the backend as well. My application server doesn't require all services to be up and running. Instead, it's able to query and tell what is working and what isn't. That information is then bubbled down to the UI in one way or another. That may mean certain functionality is unavailable (ex, if solr isn't reachable then search is disabled).
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.
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.
> 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.
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 :)
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.
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.
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.
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.
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
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.
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.
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
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.
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
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.
People with 15+ years of experience are not the target audience for this framework.
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.
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.
Sounds like a django over abstraction problem. SSE is standard HTTP.
If laravel can do it django can.
Also worth checking out is the recent release of RedwoodSDK: https://news.ycombinator.com/item?id=43657215
Oh good, they finally realized GraphQL was holding them back.
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
[dead]
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.
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
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.
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.
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
Cool, it even has a ruby sdk, gotta check it out!
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>.
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?
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 ítems.
You might be using a template system for that. E.g. Jinja2, moustache, askama, templ, etc depending on your backend language and libraries.
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/
Betteridge's law of headlines? ;)
[1] https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
... was kinda inevitable that HTMX was going to bring about a Cambrian explosion in frameworks like the one it was built to escape.
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.
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
> "what is a signal?"
it's another word for event
Signals have dependencies and subscribers. It's a value and publisher and subscriber if you want to be more correct.
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)
I googled this and got a few different answers, but not this one. Is there a particular implementation you’re referring to?
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.
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
I think your confusing signals with observables
Hypermedia. The what now?
Ah another framework, will wait until it becomes unavoidable.
[dead]
The future is frameworkless.
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!