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

31–40 of 371 posts

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

#31

Post by revskill »

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.

I guess you're a backend dev watching all frontend framework shines with a jealous eyes. Keep watching :)

Those heavyweight framework exist for a reason, they're not born out of thin air. It's about your use case, you don't need it for other's use case.

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

#32

Post by cristianpascu »

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.

“A plain .html file” - This made me chuckle. :)

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

#33

Post by blobster »

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.

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

#34

Post by ushercakes »

anonymousDan wrote: post #27

Is SSR still much better for seo?

Yeah, big time. It's faster, so crawlers give you better scores for page speed, which is important. Secondly, it automatically renders all of your content, vs if you dynamically load content, the crawler may just see a page with a "Loading" element and never actually view the content itself.

Google argues that it is able to handle javascript heavy client side code in it's crawlers, but the data seems to show otherwise.

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

#35

Post by jhp123 »

> 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 client, but this is not always true.

> Complexity is lower because the server does most of the work of generating the HTML so can often be implemented with a simpler and smaller codebase.

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

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

#36

Post by cyral »

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.

> Well done, modern devs! A plain .html file does that

And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place. HN has some weird hate for this new server side rendering, when it's really the smart thing to do and equivalent to what any app is doing: the "frame" of the app is downloaded once (and we can send the initial data with it), and then it can become interactive from there. e.g. if the data needs to be reloaded we can make a small JSON request instead of reloading the whole page and re-rendering it.

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

#38

Post by umvi »

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.

> Well done, modern devs! A plain .html file does that.

Yes but a plain html file is static, so that's not going to work unless your site is purely static (i.e. a blog).

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

#39

Post by superkuh »

ArcaneMoose wrote: post #24

The issue I have with SSR is that it offloads processing power onto the server. That means I have to pay more as the host instead of relying on user's browser to handle the compute "for free".

I'm probably not in your target demographic but when a website pushes computation to me for simple things like displaying text and images I close the tab.
Post reply on HN