3 ms·

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

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 1y ago
> 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 1y ago
  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 1y ago
  Really? That's interesting. On a Pixel 7 with FF, it all renders nicely. A tiny bit of heat but that went away.

akdor1154 1y ago

> 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 1y ago
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 1y ago
Really? That's interesting. On a Pixel 7 with FF, it all renders nicely. A tiny bit of heat but that went away.