4 ms·

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.

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.

darkhorse13 6y ago
That is why I said most, not all. There are also things like intercooler.js (https://intercoolerjs.org/ https://intercoolerjs.org/) which provides a nice middle ground.
- brylie 6y ago
  Laravel LiveWire looks like a good middle ground for enabling more dynamic user interfaces from a server application: https://laravel-livewire.com/ https://laravel-livewire.com/ There are similar projects for Phoenix/Elixir and Django: https://github.com/phoenixframework/phoenix_live_view https://github.com/phoenixframework/phoenix_live_view https://github.com/edelvalle/reactor/blob/master/README.md https://github.com/edelvalle/reactor/blob/master/README.md
tynpeddler 6y ago
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.
- recursivedoubts 6y ago
  Server side rendering CPU should be a round-off error compared with the cost of a network connection to a data store.
_bxg1 6y ago
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.
FridgeSeal 6y ago
> 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.
buzzkillington 6y ago
Try opening reddit on a mobile phone. My home server was more responsive when I was half way across the world.

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.

darkhorse13 6y ago

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

brylie 6y ago
Laravel LiveWire looks like a good middle ground for enabling more dynamic user interfaces from a server application: https://laravel-livewire.com/ https://laravel-livewire.com/ There are similar projects for Phoenix/Elixir and Django: https://github.com/phoenixframework/phoenix_live_view https://github.com/phoenixframework/phoenix_live_view https://github.com/edelvalle/reactor/blob/master/README.md https://github.com/edelvalle/reactor/blob/master/README.md

tynpeddler 6y ago

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.

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

_bxg1 6y ago

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.

FridgeSeal 6y ago

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

buzzkillington 6y ago

Try opening reddit on a mobile phone. My home server was more responsive when I was half way across the world.