News for hackers. Stuff that matters.
Re:Front-end design, React, and a bridge over the great divide by zbentley on Thursday July 18, 2019 @11:14PM (#20475909)
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.
Re:Front-end design, React, and a bridge over the great divide by jasode on Friday July 19, 2019 @05:57AM (#20477318)
>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.

Re:Front-end design, React, and a bridge over the great divide by save_ferris on Friday July 19, 2019 @09:02AM (#20478273)
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.

Re:Front-end design, React, and a bridge over the great divide by digitaltrees on Friday July 19, 2019 @10:59AM (#20479172)
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.
Re:Front-end design, React, and a bridge over the great divide by rhizome on Friday July 19, 2019 @09:29PM (#20483669)
Late loading artifacts is all the fault of JS, not server-side rendering. Not sure what you mean by "odd navigation."
Re:Front-end design, React, and a bridge over the great divide by digitaltrees on Saturday July 20, 2019 @12:32AM (#20484195)
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.
Re:Front-end design, React, and a bridge over the great divide by ng12 on Saturday July 20, 2019 @08:31PM (#20489189)
It doesn't, but blogs aren't built to present content they're built to sell advertisements and collect data. That's much easier with an SPA than a SSR app.
Re:Front-end design, React, and a bridge over the great divide by rhizome on Sunday July 21, 2019 @07:47PM (#20494435)
they're built to sell advertisements and collect data. That's much easier with an SPA than a SSR app

How easier? By dint of additional JS that an SSR doesn't have/need? Not sure how pulling a header nav (or any cell/element) from a server on pageload plays into that, but even today I've watched sites (plural) loading, pushing loaded parts all over the page for 30sec until everything settles down. Maybe blogs aren't quite so affected by this set of popular dark- and anti-patterns, but even so the post is almost always the last thing to load. Presumably, the monetization and data collection takes precedence over all else.

Re:Front-end design, React, and a bridge over the great divide by tambourine_man on Friday July 19, 2019 @08:40AM (#20478104)
>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.

Re:Front-end design, React, and a bridge over the great divide by TomMarius on Friday July 19, 2019 @05:58AM (#20477322)
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.
Re:Front-end design, React, and a bridge over the great divide by medof on Friday July 19, 2019 @06:17AM (#20477387)
So you mean universal application? That's how nuxt.js/next.js works
Re:Front-end design, React, and a bridge over the great divide by TomMarius on Friday July 19, 2019 @06:51AM (#20477512)
Yes I am aware of these technologies, and it's basically what I mean, in an abstract way
Re:Front-end design, React, and a bridge over the great divide by efdee on Friday July 19, 2019 @07:04AM (#20477577)
That is what we have today.
Re:Front-end design, React, and a bridge over the great divide by TomMarius on Friday July 19, 2019 @08:00AM (#20477885)
It is not nearly as polished and as widespread as it could be.
Re:Front-end design, React, and a bridge over the great divide by vast on Friday July 19, 2019 @08:25AM (#20478001)
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.
Re:Front-end design, React, and a bridge over the great divide by ng12 on Thursday July 18, 2019 @11:32PM (#20475969)
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.
Re:Front-end design, React, and a bridge over the great divide by kangoo1707 on Friday July 19, 2019 @12:36AM (#20476210)
SSR can be used with React (NextJS), Vue (NuxtJS) and Angular (Universal Angular).
Re:Front-end design, React, and a bridge over the great divide by sooheon on Friday July 19, 2019 @12:58AM (#20476289)
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.
Re:Front-end design, React, and a bridge over the great divide by vetinari on Friday July 19, 2019 @05:48AM (#20477283)
That and for the bots, that cannot run javascripts, but do render the page thumbnail for others (facebook et al).
Re:Front-end design, React, and a bridge over the great divide by skrebbel on Friday July 19, 2019 @01:41AM (#20476424)
This supports the argument you're replying to.
Re:Front-end design, React, and a bridge over the great divide by atombender on Friday July 19, 2019 @12:23PM (#20479969)
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.

Re:Front-end design, React, and a bridge over the great divide by ebiester on Friday July 19, 2019 @01:13PM (#20480531)
...and then they'll hit POST-redirect-GET and all the problems with the back button and holding state on the server.
Re:Front-end design, React, and a bridge over the great divide by magicnubs on Friday July 19, 2019 @12:35AM (#20476206)
So, basically video-streaming, but with websites instead of tv shows?
Re:Front-end design, React, and a bridge over the great divide by pjmlp on Friday July 19, 2019 @03:20AM (#20476776)
Basically what most web frameworks have been doing since we moved beyond CGIs.