Wait thats just weird -- if you're effectively removing the work from the client to the server anyways, such that its only executing on the server... I don't see what you've achieved beyond the original writing of standard language-agnostic SSR -- that you can design everything client-side, and conveniently migrate the heavier work serverside without interruption/rewrite?
It gives you the best of both worlds - fast initial load, accessible, works without JS. But then also get all the client side goodness - highly interactive views, animations, and far less bytes transferred for subsequent page loads. Plus, writing a complex frontend is simply a far better experience in something like React than in Ruby, Python, PHP, etc.
Finally, it lets you also render them to React Native using a lot of shared code. And you can share code between your backend APIs, etc.
To be honest, I’ll take Typescript over anything, even if it wasn’t the default for the web. It strikes the perfect balance of flexibility, concision, safety, debugging ux, and has a huge ecosystem to boot. I think client side JS these days if anything is underrated and the WASM hype won’t change much - if you want a lightweight, accessible app then doing a SPA in JS (with SSR) is actually not even a compromise, it’s truly superior to any alternative. Now, with a big caveat: you need to invest to get it all set up properly. No one has really “railsed” it yet, as far as I can tell.
It's not, it can run on both. You render on the server for the initial page load, and then on the client for every page after.
Or not! The point is, now that you've unlocked both, you can use either one, in the way that works best for your application, in whatever ratio makes sense.
A significant consideration here is SEO and crawlability. Rendering the page server-side will serve a page with content even without JavaScript running on the client, yet for clients that do have JavaScript they still get the enhancements of an interactive JavaScript app.
The actual client code is being executed.
Wait thats just weird -- if you're effectively removing the work from the client to the server anyways, such that its only executing on the server... I don't see what you've achieved beyond the original writing of standard language-agnostic SSR -- that you can design everything client-side, and conveniently migrate the heavier work serverside without interruption/rewrite?