However, the display logic is implemented as a web component containing (a) a lot of tags written as a big HTML file for streaming state from the backend, and (b) a canvas element rendered by a WASM component. If that fits your definition of SSR for frontend apps, no problem and I think it's great. But that's not what I would have defined as SSR.

Some hurdles I imagine Datastar will need to overcome before this pattern can see widespread adoption:

- there doesn't seem to be a straightforward way to statically bind the frontend markup to the backend, so scaling this to multi-team apps will be a challenge.

- the markup and associated binding feels very similar to template-driven SPA frameworks (data- attributes for everything, really? That's fine in the resulting DOM tree but it's got to be a pain to author and maintain for large apps). Perhaps if someone could build a JSX-like code-to-markup DSL, that problem could be ameliorated.

- he is demoing it from his local machine, so we don't get to see (a) how much server-side compute is required at any scale (even >10 users), (b) how strongly latency can affect rendering, and (c) overall bandwidth requirements.

That being said, I know video game companies have streaming games deployed, so in theory this approach has merit (though I suspect only users who lack beefy home computers and have great internet connections opt for it).

Overall, this feels like less of an indictment of the SPA pattern in general* and more of a "let's see what happens if we change what we assume the constraints are."

*Yes, he's right that a lot of modern SPA development tooling is terrible. Dojo from the 2000s is still arguably easier to develop in than most modern SPA frontend stacks, especially since it can be run with only a static file server, no build required.