The fundamental problem with serverside rendering is that it requires a round trip if the model changes. With modern interactive apps, the model changes a lot. People don't like waiting for things.

There's a factor, though, that never seems to find its way into this conversation: the native web handles a lot of client-side state (model) for you, for free. We forget this because React and Vue elevate things like temporary input buffers, and dropdown states, and validation, to the application-logic level. This gives you the flexibility to do with it whatever you want: want to bind your text input's content to something else in real time? Go for it! But it also means that for the bottom 90% of common cases, application logic has to manually juggle all of those values itself, which it didn't used to have to do. This means our mental concept of "model changes" has become much larger in scope than it actually is for a server-rendered app.

In server-rendered apps, the client/server boundary plays the role of a natural boundary between transient and domain-model state. Of course the pain points come when that approximation is wrong, but in most cases that's a pretty rare occurrence.

This is actually the primary thing I like about server-rendering. Not the performance side, but the reduction in state. The reduction in contingencies and in the potential for broken cases. When most of your state gets thrown away on every view change, there's so much less to keep track of.

> With modern interactive apps, the model changes a lot. People don't like waiting for things.

Given how long I have to wait for the ever fashionable JS heavy SPA's to do _anything_, I'd almost be willing to bet it would still take less time.

Try opening reddit on a mobile phone.

My home server was more responsive when I was half way across the world.

That is why I said most, not all. There are also things like intercooler.js (https://intercoolerjs.org/) which provides a nice middle ground.

Laravel LiveWire looks like a good middle ground for enabling more dynamic user interfaces from a server application:

https://laravel-livewire.com/

There are similar projects for Phoenix/Elixir and Django:

https://github.com/phoenixframework/phoenix_live_view

https://github.com/edelvalle/reactor/blob/master/README.md

Not to mention that server side rendering increases cpu load on your servers. Of course that may be a feature if you're a customer who's tired of slowly loading webapps.

Server side rendering CPU should be a round-off error compared with the cost of a network connection to a data store.

I don't think we are going full circle. Microsoft Blazor, WebAssembly is showing a lot of promises.

Patiently waiting for WebAssembly to take off. I cant wait to get out of JS hell on client side.

HTML+CSS is a beautiful thing for ui. Its JS thats holding it back. If we had, say C# on the client side, imagine the web landscape by now.

You mean that you're waiting for WebAssembly to be able to access the DOM ? Or is there anything else you're specifically waiting for ?

WebAssembly to access the DOM.

Can you tell more about this please ? Because this is what I find:

> By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript

https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...