5 ms·

I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code, just as current template-in

I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code, just as current template-in-javascript metalanguages are being discovered now as a cure for spaghetti frontend-plus-backend-rendered code.

ng12 7y ago
I don't think so, at least not for the kinds of apps I build. My biggest problem is largely around interactivity -- shuffling lots of data back-and-forth between the client and the server. If I'm going to have a SSR app with lots of AJAX code running on the client, I might as well just go all-client.
- kangoo1707 7y ago
  SSR can be used with React (NextJS), Vue (NuxtJS) and Angular (Universal Angular).
  - sooheon 7y ago
    Isn't that use case just to save time on initial load? An SPA with SSR for load times is different from a webapp structured to have logic mostly in the server.
    - vetinari 7y ago
      That and for the bots, that cannot run javascripts, but do render the page thumbnail for others (facebook et al).
  - skrebbel 7y ago
    This supports the argument you're replying to.
magicnubs 7y ago
So, basically video-streaming, but with websites instead of tv shows?
- pjmlp 7y ago
  Basically what most web frameworks have been doing since we moved beyond CGIs.
jasode 7y ago
>I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code, Maybe your prediction is informed by different internet usage scenarios but for general mainstream web surfers, I can't see how the industry will migrate back to server-side rendering in 3 years. The unavoidable technical issue is the round-trip latency of the network. The same delays from the speed-of-light will still be there in 3 years. Most of the world is accessing the web through mobile phones which has worse latency than desktops. Server-side rendering (which means painful page reloads) is user hostile on slow network connections.
- TomMarius 7y ago
  I believe in a mix of these two. It's going to be server rendered JS app that will download itself on the background and install itself as a PWA. The best of both worlds.
  - medof 7y ago
    So you mean universal application? That's how nuxt.js/next.js works
    - TomMarius 7y ago
      Yes I am aware of these technologies, and it's basically what I mean, in an abstract way
  - efdee 7y ago
    That is what we have today.
    - TomMarius 7y ago
      It is not nearly as polished and as widespread as it could be.
- vast 7y ago
  So parallelism after one initial slow load is the cure all? I also propose that front end will rediscover that parallelism is hard and isn't always the best fit.
atombender 7y ago
This already happened. Frameworks like Next.js, Vue and Gatsby do server-side rendering out of the box. Svelte also extremely promising. It brings a brilliant hybrid solution to the table.
ebiester 7y ago
...and then they'll hit POST-redirect-GET and all the problems with the back button and holding state on the server.

ng12 7y ago

I don't think so, at least not for the kinds of apps I build. My biggest problem is largely around interactivity -- shuffling lots of data back-and-forth between the client and the server. If I'm going to have a SSR app with lots of AJAX code running on the client, I might as well just go all-client.

kangoo1707 7y ago
SSR can be used with React (NextJS), Vue (NuxtJS) and Angular (Universal Angular).
- sooheon 7y ago
  Isn't that use case just to save time on initial load? An SPA with SSR for load times is different from a webapp structured to have logic mostly in the server.
  - vetinari 7y ago
    That and for the bots, that cannot run javascripts, but do render the page thumbnail for others (facebook et al).
- skrebbel 7y ago
  This supports the argument you're replying to.

magicnubs 7y ago

So, basically video-streaming, but with websites instead of tv shows?

pjmlp 7y ago
Basically what most web frameworks have been doing since we moved beyond CGIs.

jasode 7y ago

>I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code, Maybe your prediction is informed by different internet usage scenarios but for general mainstream web surfers, I can't see how the industry will migrate back to server-side rendering in 3 years. The unavoidable technical issue is the round-trip latency of the network. The same delays from the speed-of-light will still be there in 3 years. Most of the world is accessing the web through mobile phones which has worse latency than desktops. Server-side rendering (which means painful page reloads) is user hostile on slow network connections.

TomMarius 7y ago
I believe in a mix of these two. It's going to be server rendered JS app that will download itself on the background and install itself as a PWA. The best of both worlds.
- medof 7y ago
  So you mean universal application? That's how nuxt.js/next.js works
  - TomMarius 7y ago
    Yes I am aware of these technologies, and it's basically what I mean, in an abstract way
- efdee 7y ago
  That is what we have today.
  - TomMarius 7y ago
    It is not nearly as polished and as widespread as it could be.
vast 7y ago
So parallelism after one initial slow load is the cure all? I also propose that front end will rediscover that parallelism is hard and isn't always the best fit.

atombender 7y ago

This already happened. Frameworks like Next.js, Vue and Gatsby do server-side rendering out of the box. Svelte also extremely promising. It brings a brilliant hybrid solution to the table.

ebiester 7y ago

...and then they'll hit POST-redirect-GET and all the problems with the back button and holding state on the server.