Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future (and the past) of the web is server side rendering

deno.com

Post reply on HN
Print view View original

71–80 of 371 posts

Re: The future (and the past) of the web is server side rendering

#71

Post by nicoburns »

HideousKojima wrote: post #46
jhp123 wrote: post #35

> Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded. but the page is loaded later because you have to wait for the server to perform this work. There is no reduction in total work, probably an absolute increase because some logic is duplicated. If there is a speed improvement it is because the server has more clock cycles available than the c…

>but the page is loaded later because you have to wait for the server to perform this work. What is caching?

Caching also works for client side rendering of course (you can usually cache the entire client side app so that the browser doesn't have to hit the network at all to start running client side code).

Re: The future (and the past) of the web is server side rendering

#74

Post by runako »

jhp123 wrote: post #35

> Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded. but the page is loaded later because you have to wait for the server to perform this work. There is no reduction in total work, probably an absolute increase because some logic is duplicated. If there is a speed improvement it is because the server has more clock cycles available than the c…

> no reduction in total work

This does not 100% track with observed client-side performance. Another poster mentioned caching, which obviously reduces total work. I would also add shifting the work via pre-computation as another commonplace way to improve performance.

> It takes less code to build a string in a datacenter than it does in a browser?

The string build in a datacenter might be happening in a warmed-up JIT of some language, on a machine with enough capacity to do this effectively. By contrast, the browser is possibly the slowest CPU under the most outside constraints (throttling due to power, low RAM, multitasking, etc.). It is generally going to be better to do the work in the datacenter if possible.

Re: The future (and the past) of the web is server side rendering

#75

Post by MrOwnPut »

JohnFen wrote: post #16
rektide wrote: post #11

Earlier quoted context omitted.

What is it you dont trust? This Fear Uncertainty & Doubt clashes heavily with the excellent security sandbox the web browser is. What is the harm you are afraid of? What are you supposing the risk is/what's in jeapordy here?

Relying on sandboxes seems unwise to me. They're a useful backstop, but shouldn't be the primary defense. The primary defense is to minimize the exposure to risk in the first place. As to what harm I'm avoiding, it's mostly around tracking -- which is something that browsers have a very difficult time preventing, especially if sites are allowed to run code in them.

So lets say a resume generator website, or a document converter, etc.

You trust uploading your personal information to a server to generate the pdf/image/whatever vs doing it in solely in the browser?

Doing more on the server would lead to more tracking, not less.

Re: The future (and the past) of the web is server side rendering

#76

Post by [deleted] »

trollied wrote: post #17

“Server side rendering” is such a terrible term. The server isn’t doing rendering, the browser is. The server is sending a complete well-formed DOM for the client to render. Well done, modern devs! A plain .html file does that. I really hope some of the heavy front-end frameworks die a death, some common sense prevails, and we get a lighter, faster loading, more responsive web. I can dream.

[deleted]

Re: The future (and the past) of the web is server side rendering

#77

Post by capableweb »

spiffytech wrote: post #19
csixty4 wrote: post #13

Earlier quoted context omitted.

Googlebot has been able to index SPAs since 2019. They use a Headless Chrome instance and allow a number of seconds for things to render after each interaction.

With the caveat that server-generated HTML is indexed immediately, while pages that need client-side rendering get put into a render queue that takes Google a while to get to (days?).

Hence you don't build documents with SPAs, they are meant for applications. And usually you don't care about indexing the inside of applications, only the landing pages and such, which are documents (should not be a part of the SPA).

A blog built as a SPA? Sucks. A blog built as a collection of documents? Awesome.

Re: The future (and the past) of the web is server side rendering

#78

Post by taftster »

blobster wrote: post #33
anonymousDan wrote: post #27

Is SSR still much better for seo?

Yes. There's a separate queue for sites that need js rendering and it eats much more into your crawl budget. Best way to avoid it imo is to use something like Rendertron, which is made and recommended by Google.

Rendertron is deprecated

Please note that this project is deprecated. Dynamic rendering is not a recommended approach and there are better approaches to rendering on the web.

Rendertron will not be actively maintained at this point.

https://github.com/GoogleChrome/rendertron

Re: The future (and the past) of the web is server side rendering

#80

Post by habibur »

altdataseller wrote: post #47
revskill wrote: post #45

Earlier quoted context omitted.

Trust me, everything exits for a reason, to solve (maybe specific problem). It's nonsensical to want it to die for "no reason".

Not arguing they aren't useful. Just that no backend dev is ever jealous of what's happening with front end frameworks.

Another interesting question : are frontend developers jealous of what the backend developers are doing, or are they not?
Post reply on HN