https://example.andersmurphy.com/

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.

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...

edit: damn, purple civilization got hands

If I didn't know better, I'd say this was an April Fool's joke.

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.

Potentially could be solved with some client side cache but still..

https://github.com/zangster300/northstar/tree/main

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.

For people who are looking for HTMX alternatives, I think Alpine AJAX is another choice if you are already using AlpineJS

It seems like Datastar is doing away with that entirely and binding the UI more tightly to JavaScript to function correctly.

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).

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.

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.

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

I found this talk really interesting. It's a cool framework for very interactive applications.

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 have ideas around ways around this but it's a per language template middleware.

https://news.ycombinator.com/item?id=43650921

https://gonads.net/

it's another word for event

(or, if you wish, a stream where you have an Option at each timestamp)

There was a funny convo about this a bit

https://www.youtube.com/watch?v=y79L3fhJI3o&t=8636s