Where we will go from here, is pretty obvious. Now that we've realized SSRs cannot be an optional afterthought, we'll soon realize SSRs with running JS on the

Where we will go from here, is pretty obvious. Now that we've realized SSRs cannot be an optional afterthought, we'll soon realize SSRs with running JS on the server is a nightmare to scale - https://engineeringblog.yelp.com/2022/02/server-side-rendering-at-scale.html https://engineeringblog.yelp.com/2022/02/server-side-renderi... Just search HN for "scaling server side rendering" and you'll land on a bunch of practical complications. That doesn't mean SSR is bad. It just means we know the solution but stuck with the wrong tools. My hypothesis is that we'll capitalize WebAssembly to run our UI rendering logic and a tiny platform-specific rendering layer to translate rendering commands from WASM to platform. Interesting side-benefit: Language choices other than Javascript. I've already started working on a proof-of-concept React-ish library that runs on a WASM VM. IT lets you specify your UI component declaration and behaviour in Kotlin - https://github.com/joelewis/kwasm https://github.com/joelewis/kwasm