6 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, Maybe your prediction is

by 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.
tambourine_man 7y ago
>Server-side rendering (which means painful page reloads) is user hostile on slow network connections. So is downloading an entire app when you only want to read one page.
save_ferris 7y ago
You didn’t mention all of the new features coming to HTTP 2 that will alleviate network performance issues (prefetch, multiplex connections, etc.) I’ve found many sites that use frameworks like react to be much more user hostile, particularly from a performance and accessibility standpoint. The reddit redesign comes to mind. It’s so much slower now than it used to be on a browser (perhaps they’re intentionally doing this to push people to their mobile app), that it’s noticeably reduced the quality of the experience. I guess I just don’t understand how people see page reloads with proper caching as unacceptable from a performance standpoint compared some JavaScript app maintaining a virtual DOM, which is also likely regularly communicating with a server.
- deleted 7y ago
  [deleted]
- digitaltrees 7y ago
  Same with TechCrunch, every time I visit I am reminded how frustrating react sites can be compared to server rendered pages with all the flicker, slow page reveal, and odd navigation it introduced.
  - rhizome 7y ago
    Late loading artifacts is all the fault of JS, not server-side rendering. Not sure what you mean by "odd navigation."
    - digitaltrees 7y ago
      To close an article there is a x button and back swipe is disabled. I agree that flicker is introduced by Javascript. That is what I was saying. Might be ok for an app, but a content driven site seems like it should stick to the concept of pages where navigation is like turning a page. Just seems like server rendering fits that mental model better. Not sure why react even makes sense for a blog.
      - ng12 7y ago

by jasode 7y ago

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.

tambourine_man 7y ago

>Server-side rendering (which means painful page reloads) is user hostile on slow network connections. So is downloading an entire app when you only want to read one page.

save_ferris 7y ago

You didn’t mention all of the new features coming to HTTP 2 that will alleviate network performance issues (prefetch, multiplex connections, etc.) I’ve found many sites that use frameworks like react to be much more user hostile, particularly from a performance and accessibility standpoint. The reddit redesign comes to mind. It’s so much slower now than it used to be on a browser (perhaps they’re intentionally doing this to push people to their mobile app), that it’s noticeably reduced the quality of the experience. I guess I just don’t understand how people see page reloads with proper caching as unacceptable from a performance standpoint compared some JavaScript app maintaining a virtual DOM, which is also likely regularly communicating with a server.

deleted 7y ago
[deleted]
digitaltrees 7y ago
Same with TechCrunch, every time I visit I am reminded how frustrating react sites can be compared to server rendered pages with all the flicker, slow page reveal, and odd navigation it introduced.
- rhizome 7y ago
  Late loading artifacts is all the fault of JS, not server-side rendering. Not sure what you mean by "odd navigation."
  - digitaltrees 7y ago
    To close an article there is a x button and back swipe is disabled. I agree that flicker is introduced by Javascript. That is what I was saying. Might be ok for an app, but a content driven site seems like it should stick to the concept of pages where navigation is like turning a page. Just seems like server rendering fits that mental model better. Not sure why react even makes sense for a blog.
    - ng12 7y ago