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

81–90 of 371 posts

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

#81

Post by runako »

In theory, the "modern" frontend frameworks could be useful for a subset of applications. In practice, they are wildly overused, largely (IMHO) because front-end developers have forgotten how to build without them.

If I gave this as an example, people would say I'm being unfair to the front-end folks. But since Deno posted it, I think it's fair say that it's overkill to use a front-end framework like React (mentioned as a comparator in TFA) to implement add to cart functionality on an e-commerce site. And that for users with slow browsers, slow/spotty Internet, etc., an architecture that uses a heavy front-end framework produces a worse overall experience than what most e-commerce sites were able to do in 1999.

Edit: IMHO all of this is an artifact of mobile taking a front seat to the Web. So we end up with less-than-optimal Web experiences due to overuse of front-end JS everywhere; otherwise shops would have to build separate backends for mobile and Web. This, because an optimal Web backend tends to produce display-ready HTML instead of JSON for a browser-based client application to prepare for display. Directly reusing a mobile backend for Web browsers is suboptimal for most sites.

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

#82

Post by oakwhiz »

OliverJones wrote: post #23
mikece wrote: post #2

And the future beyond that will be client-side rendering. In the beginning everything was rendered on the mainframe; then CICS allowed partial screen updates and even dynamic green screen design. Then the early web where everything was server which made the job of web indexing much easier. Then we moved back to rich client apps -- applets, flash, eventually SPAs -- with no way for search engines to easily index thing…

The client-server wheel of life just keeps turning, and turning, and turning. It's an eternal human truth: each generation yearns to improve on the previous generation's efforts. This server-client zeal to improve has been tremendously productive of good ideas over the last few decades. It will continue. Hopefully saving power and CO2 can be the focus of the next couple of turns of the great wheel.

Extracting money and creating walled gardens, while removing user choice, is also a focus of this server side cycle.

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

#84

Post by wizofaus »

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".

Surely most of the compute cycles for turning a web page into pixels happen on the client anyway? I'm not convinced the server necessarily has to do massively more work to return HTML over JSON (though it would obviously depend on how the HTML-generation was coded. If you're trying to use the client-style page rendering techniques on the server, issuing API calls over the network and interpreting Javascript code, then you have a point).

Edit: my "most" claim is probably too strong on reflection: while there's still a lot of work to do to convert an in-memory DOM into pixels, it's likely to be highly optimized code (some of it handled at the GPU level) that uses minimal compute cycles. And while the V8 engine may be similarly optimised, it still has to interpret and execute arbitrary JS code supplied to it, plus handle all the necessary sandboxing. It'd be interesting to get a breakdown of what compute cycles are used converting a typical SPA into pixels, and of course a comparison with how much time is spend waiting for data to come across the network.

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

#85

Post by ehutch79 »

superkuh wrote: post #39
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.

And congrats on getting fired for refusing to use the companies internal tools. Not all web sites are brochure-ware. Sometime the target demographic is a limited number of internal employees who open the app once and keep it open.

Never mind that i don't know how you would display images server side.Your client needs to decode that image and render it to screen at some point

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

#86

Post by JohnFen »

MrOwnPut wrote: post #75
JohnFen wrote: post #16

Earlier quoted context omitted.

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.

Well, I wouldn't use such a website anyway (especially a document converter -- that is better done using a real application), regardless of where the processing was done, unless I was very certain that the website was trustworthy. For one thing, even if the website purports to not move my data to their servers, how do I know they're being truthful without going to extremes such as sniffing traffic?

There have been plenty of sites that have lied about such things.

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

#87

Post by tlarkworthy »

It's obviously nonsense. The lowest latency cache and state storage is clientside. You can piss around with multi regions and SSR to minimize latency but that's just placing a lot of regional caches near your users. The nearest place is in their actual browser -> offline first is the future

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

#90

Post by Havoc »

trashburger wrote: post #25
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".

The problem with this idea is that the user's browser's compute is not "free". Offloading the computing means the users have a worse experience, which will affect your userbase and page rankings.

>Offloading the computing means the users have a worse experience

Does it though? Loading a webpage barely registers in cpu usage etc on a reasonably modern device

Post reply on HN