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

91–100 of 371 posts

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

#91

Post by runako »

nicoburns wrote: post #71
HideousKojima wrote: post #46

Earlier quoted context omitted.

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

> 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

This is also true for Web apps that do not have meaningful amounts of client-side code.

> Caching also works for client side rendering

There are obviously a lot of differences in how caching works, but client-side caching is generally strictly worse than doing so on the server. Using the e-commerce example in TFA, every browser has to maintain their own cache of the product information, which may include cache-busting things like prices, promotional blurbs, etc.

The server can maintain a single cache for all users, and can pre-warm the cache before any users ever see the page. Adding fragment caching, which allows parts of a page to be cached, a server-side caching strategy will typically result in less total work being done across the user population, as well as less work done at request time for each visitor.

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

#92

Post by unity1001 »

cyral wrote: post #36
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 downloade…

> 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

And that's what most of the web needs - few use cases require having to manipulate every bit of the dom to send constant updates to the end-user. Social networks, financial sites, banks, betting sites etc. The rest do not need these heavy frameworks and the extensive dom manipulating capability. The last thing you want in an ecommerce checkout process is to distract the user by manipulating the dom to give him 'updates'. So nobody does anything like updating the user with info like 'latest prices', 'your friend just bought this' etc right in the middle of the checkout process. Same goes for blogs, most of publishing.

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

#93

Post by [deleted] »

tlarkworthy wrote: post #87

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

[deleted]

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

#94

Post by MrOwnPut »

JohnFen wrote: post #86
MrOwnPut wrote: post #75

Earlier quoted context omitted.

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 pl…

You can swap out my examples for anything really.

The point is the more work the server does, the more data you have to send them to do that work.

As far as trusting it's client-side only, opening the network tab in devtools would suffice.

If you think they broke the sandbox (Google would pay millions for that!), yes sniffing would be the next step.

At least you have a sandbox on web, you usually don't have that for native apps.

But that's all better than willingly sending data to another entity's server and trusting them to not abuse/leak it.

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

#95

Post by jhp123 »

IanCal wrote: post #65
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. There is no reduction in total work Removing or shortening round trips absolutely removes work. Sending you a page, letting you parse the JavaScript, execute it to find out the calls to make, sending that to the API, the API decoding it and pulling from the database, rendering the JSON and returning that, you parsing the JSON…

yes, reducing round trips is very important for web performance. It can be done via a server-side architecture where external resources are sent immediately as prefetch headers, then the page is generated and sent after database calls etc are made. Or via a client-side architecture where API calls needed for initial render are either sent via prefetch headers, or included inline in the HTML response.

If you don't need page interactivity then a pure server-side approach works best because you do not need to send, parse, or execute any page logic. For highly interactive pages you tend to need all the logic to rerender each component on the frontend anyway, so client-side rendering makes sense as a simpler approach without significant performance costs. Isomorphic approaches are more complex and brittle, they tend to hurt time to full page interactivity because of duplicated work, but can be needed for SEO. Reducing overall page weight and complexity and lazy-loading where possible, and getting rid of the damn tracking pixels and assorted third-party gunk, are often more effective directions for optimization than worrying about where HTML is generated.

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

#96

Post by revskill »

runako wrote: post #81

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…

There's always a "what if".

What if you don't just stop at "adding a add to cart button" ?

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

#97

Post by forgotmypw17 »

dylan604 wrote: post #22
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'm of two minds. I want agree with you of well formed DOM for the browser to render. That's great. Now, do we have to go all the way back to flat files where the whole page has to refresh to update one silly field or selection update? No, we don't have to go full cave man for that. We can still use the front end to make changes after the initial load. we don't need an app to be running in each user's browser for a l…

Yes, the best of both worlds.

Fast-loading, complete, cacheable, archivable pages.

And DOM changes for updating them without reloading the entire page.

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

#98

Post by teaearlgraycold »

runako wrote: post #81

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…

IMO the big value add from React and friends is all of your rendering logic is in the same language and the same code base. I do not want to go back to templated HTML from Ruby/Java/PHP/whatever combined with ad hoc JS to handle whatever parts need to be dynamic. If you know your UI can be almost completely static (like with HN) then the trade-off from the old way is acceptable. But if you don't know where your site's going to go because you're a startup then it's hard to buy into old school SSR. NextJS, when done right, can be an acceptable 3rd option.

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

#99

Post by runako »

revskill wrote: post #96
runako wrote: post #81

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…

There's always a "what if". What if you don't just stop at "adding a add to cart button" ?

Correct. The design tradeoff is dependent on knowing how much of a Lisp interpreter you need to build. For most sites, the answer is "none" and it's not worth degrading user experiences just in case your e-commerce site ends up needing the ability to also serve as a designer for Minecraft levels.

(Even if it does, there is no requirement to ship the heavy JS needed for the Minecraft editor to all the e-commerce product description pages.)

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

#100

Post by macspoofing »

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.

Client-side rendering isn't immune to this. The server APIs they hit have to render the response in JSON after hitting the same kinds of backend resources (e.g. DB).

Post reply on HN