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

Server Side Rendering at scale

engineeringblog.yelp.com

Post reply on HN
Print view View original

21–30 of 67 posts

Re: Server Side Rendering at scale

#21

Post by manigandham »

rtpg wrote: post #18
diek wrote: post #3

> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…

It's actually not how things worked just a few years ago. How things worked a few years ago: you wrote SSR pages with one set of tools (like Django Template Language), then hooked into it with another set of tools. If your pages are complex enough, you end up with weird brittleness because the "initial page load" is not handled the same way as modifications of that page. Now it's much closer to using the same set for…

Why do you need all that client-side interactivity in the first place? Most interactions can easily be handled with a full refresh, as proven by the very site you're reading this on (hackernews).

Server-side web frameworks even have modern component-based UI templating now, and features like maps can be layered on top as progressive enhancement without this bloated frontend mess.

Re: Server Side Rendering at scale

#22

Post by manigandham »

LAC-Tech wrote: post #12
diek wrote: post #3

> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…

> They could have built this in Java, .Net, Go, really any shared memory concurrency runtime and threading, and would not run into any of these issues. Right, they'd have brand new issues because they were dealing with shared memory.

Like what? Server-side frameworks have existed for decades. It's not difficult to run, and modern languages make concurrency very easy.

JS doesn't have an advantage here, it's just limited to being single-threaded.

Re: Server Side Rendering at scale

#23

Post by manigandham »

This article is just embarrassing. How is a internet tech company so bad at producing basic static webpages? Nothing on the Yelp site needs React or a massive frontend framework.

No real-time updates, no complex rendering, no serious in-depth application abilities. The only big JS feature is the maps which can be wired up with relatively little code.

Re: Server Side Rendering at scale

#24

Post by dewey »

manigandham wrote: post #23

This article is just embarrassing. How is a internet tech company so bad at producing basic static webpages? Nothing on the Yelp site needs React or a massive frontend framework. No real-time updates, no complex rendering, no serious in-depth application abilities. The only big JS feature is the maps which can be wired up with relatively little code.

Do you think you have full insights into what's going on there from the outside? This sounds like a "can't they just use a static site generator" kinda-comments without knowing about the whole scope of the company.

Re: Server Side Rendering at scale

#25

Post by mrweasel »

hunterb123 wrote: post #9
diek wrote: post #3

> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…

Client side rendering is needed for apps that work offline. SSR improves the user experience for first time use of those apps and enables SEO. What you say is subjective but I somewhat agree with your opinion, but only for web sites, not web apps. Overall I agree Yelp should have stuck with the existing system as their product functions as a site.

> Client side rendering is needed for apps that work offline.

Couldn't you built a native application and NOT have this problem? It seems like yet another self inflicted problem.

Re: Server Side Rendering at scale

#26

Post by pjmlp »

diek wrote: post #3

> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…

Not only that this statement "Server Side Rendering is a technique used to improve the performance of JavaScript templating systems (such as React). " can only be understood as a joke.

Really? A technique invented for JavaScript?!?

Re: Server Side Rendering at scale

#27

Post by andrewingram »

manigandham wrote: post #22
LAC-Tech wrote: post #12

Earlier quoted context omitted.

> They could have built this in Java, .Net, Go, really any shared memory concurrency runtime and threading, and would not run into any of these issues. Right, they'd have brand new issues because they were dealing with shared memory.

Like what? Server-side frameworks have existed for decades. It's not difficult to run, and modern languages make concurrency very easy. JS doesn't have an advantage here, it's just limited to being single-threaded.

I remember from using Tapestry (a Java framework) in the day, it had really aggressive in-memory caching, and you had to be really careful to disable it for components which rendered personalised or user data. We had some huge privacy leaks (which luckily we caught quickly) because we didn't realise it had this behaviour, as it didn't generally show up in local development.

Re: Server Side Rendering at scale

#28

Post by Cthulhu_ »

aaronbrethorst wrote: post #5
ksec wrote: post #4

Earlier quoted context omitted.

I dont want to name names, but do any tech company actually apologise after their high evangelism to the world and industry and walk back 70% of their decision five years later? And for some strange reason this mostly happens to Web Development in general.

Why would they? They weren’t responsible. The people who championed these approaches have left for new jobs.

I've seen that a few times now, really intelligent people over-engineering and selling a new system, moving up in the company then out. They sell technology that doesn't age well, get a fat paycheck, and never have to live with the consequences. I'm kinda done with that.

Mind you, sometimes it's inadvertent. I'm currently the only web developer at my company building a big system in Go and React. I don't believe they are very difficult or esoteric technologies, but I'm still not sure if they will be able to find a replacement if I decided to move on.

But I don't know what the alternative would have been. Probably keep trudging on with the old PHP + Dojo bombsite, but it would have the same problem because who would want to work with that tech stack? Who would be able to be productive in a 200K LOC pile of shit? I mean even if it wasn't shit, it's still 200K LOC representing a decade of work, dozens of domains and hundreds / thousands of individual features.

Which is where technology choices come in again; use simple and few tools, the problem to be solved is difficult enough already.

Re: Server Side Rendering at scale

#29

Post by Cthulhu_ »

dewey wrote: post #24
manigandham wrote: post #23

This article is just embarrassing. How is a internet tech company so bad at producing basic static webpages? Nothing on the Yelp site needs React or a massive frontend framework. No real-time updates, no complex rendering, no serious in-depth application abilities. The only big JS feature is the maps which can be wired up with relatively little code.

Do you think you have full insights into what's going on there from the outside? This sounds like a "can't they just use a static site generator" kinda-comments without knowing about the whole scope of the company.

Do you? You sound like you're making apologies without bringing compelling arguments to the contrary of the person you're replying to.

Re: Server Side Rendering at scale

#30

Post by wil421 »

ksec wrote: post #4
diek wrote: post #3

> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…

I dont want to name names, but do any tech company actually apologise after their high evangelism to the world and industry and walk back 70% of their decision five years later? And for some strange reason this mostly happens to Web Development in general.

They will keep spitting out frontend frameworks that push computation out to the consumer. It’s probably cheaper to develop new frontend frameworks than it is to pay for server side rendering.
Post reply on HN