Hacker News Reader

Comment by CharlesW | Hacker News Reader

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.

Reply on news.ycombinator.com