4 ms·

I feel like we are going to go full circle pretty soon, with more people realizing that server-side rendering is better for most websites/apps. I say this as so

I feel like we are going to go full circle pretty soon, with more people realizing that server-side rendering is better for most websites/apps. I say this as someone who has used Angular and Vue extensively (and still do). The problem is, it is extremely easy to get things wrong, and I have seen mediocre (not great, but not bad) front-end devs make a complete mess using these frameworks.

johnday 6y ago
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.
MangoCoffee 6y ago
I don't think we are going full circle. Microsoft Blazor, WebAssembly is showing a lot of promises.
- kumarvvr 6y ago
  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.
  - 1337shadow 6y ago
    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 ?
    - kumarvvr 6y ago
      WebAssembly to access the DOM.
      - 1337shadow 6y ago
        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/Concepts https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...

johnday 6y ago

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.

MangoCoffee 6y ago

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

kumarvvr 6y ago
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.
- 1337shadow 6y ago
  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 ?
  - kumarvvr 6y ago
    WebAssembly to access the DOM.
    - 1337shadow 6y ago
      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/Concepts https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...