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

41–50 of 67 posts

Re: Server Side Rendering at scale

#41

Post by ec109685 »

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…

Yes, they could have rewritten their stack and used different technology on server and client.

Instead, this blog post shows they made small changes that resulted in a much better performing site with less server resources needed.

The idea of dropping server side rendering if the site is temporary overloaded is a good one that you can’t do if built in Java, .Net and Go.

A fork exec web server is not convoluted.

Re: Server Side Rendering at scale

#42

Post by manigandham »

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.

I have enough experience with large-scale internet services (building adtech platforms).

Yes, some things are just not that complicated. Sometimes it really is just poor tech.

Re: Server Side Rendering at scale

#43

Post by sod »

I dabbled with worker threads in the past. It feels like you are orchestrating a bunch of node.js instances (workers) with one single threaded entry point, which is now your new bottleneck.

It seems way easier and faster to instead start as many node.js instances as you need and distribute the load via nginx reverse proxy.

It's unfortunate that ssr for client frameworks has to run in node.js, which is rather slow. But that shouldn't invite someone to stack more server javascript on top of it. Maybe someday someone is brave enough to write a frontend framework that uses a compiled language (rust, go, java?), that can also compile to javascript for the client, but renders crazy fast in ssr.

Re: Server Side Rendering at scale

#44

Post by manigandham »

mahesh-hegde wrote: post #32
manigandham wrote: post #21

Earlier quoted context omitted.

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.

Something like a collaborative document editor or forms with non-trivial logic. Also, the interface of HN works because of its demographic.

Collaborative editors are the 1% of sites that are actually applications and need a SPA.

But Yelp is nothing like that. What part of the interface is so advanced? It's just a few links and buttons to navigate to pages and submit reviews. A few JS event handlers can handle AJAX/partial updates without an entire React frontend.

There's even stuff like https://alpinejs.dev/ and https://htmx.org/ to make this incredibly easy now.

Re: Server Side Rendering at scale

#45

Post by manigandham »

jaywalk wrote: post #34
rtpg wrote: post #18

Earlier quoted context omitted.

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…

More than a few years ago, but ASP.NET WebForms with the AJAX Control Toolkit did this. It was terrible for many reasons, but it did allow you to use one set of tools for everything.

I started my career with .NET and used/abused the AJAX controls too. Some of those sites are still running today, and still remain fast and responsive and simple to maintain.

The new cutting edge with Blazor is even more impressive and a serious contender for non-JS frontends. Similar advancements with Elixir/Liveview and Ruby/Hotwire

Re: Server Side Rendering at scale

#46

Post by manigandham »

whazor wrote: post #33
anentropic wrote: post #10

Earlier quoted context omitted.

Yeah... and then this: > We evaluated several languages when it came time to implement the SSR Service (SSRS), including Python and Rust. It would have been ideal from an internal ecosystem perspective to use Python, however, we found that the state of V8 bindings for Python were not production ready Wow, that is some convoluted architecture It seems like the problem here is React

I see a lot of React hate which I can understand, but don't forget that React allows you to release faster as a big company. React is a defacto standard that product people know and understand. They can ship complicated features faster across platforms (for example React Native), while the more technical engineers get to solve these more generic problems (dependency hells, integrations, CI/CD, performance). Alternati…

> "I see a lot of React hate"

Pointing out badly constructed solutions using the wrong tech is valid criticism. It's not "hate" to say that React and this SSR setup is used being used unnecessarily for a site that doesn't need it.

> "React allows you to release faster as a big company."

This is absolutely not a rule in any way. Again, using the proper tech for the situation is what matters. Large teams with complex frontends can sometimes move faster with React, but there are million other factors that go into this.

Re: Server Side Rendering at scale

#48

Post by bob1029 »

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…

The amount of damage you could do with simple string interpolation of HTML/JS/CSS source provided by a plain-ass HTTP server is pretty remarkable if you can use your imagination for 5 seconds.

Getting the desired plaintext documents across the network has never been such a clusterfuck in my experience.

Re: Server Side Rendering at scale

#49

Post by manigandham »

dewey wrote: post #31
Cthulhu_ wrote: post #29

Earlier quoted context omitted.

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

I do not, but from working in companies I know that a lot of things are not as simple as they look from the outside. Most times decisions are taken with a bunch of constraints factored in (can we attract talent to work on that stack?) that aren't necessarily just about "how can we build this in the simplest way possible". Thinking that they haven't thought about this one simple way of doing it is a bit naive.

On the contrary, the older and more experienced I get, the more I realize just how poorly organizations make decisions. Especially in tech/software. This is the norm. Exceptional engineering is rare.

Re: Server Side Rendering at scale

#50

Post by hunterb123 »

mrweasel wrote: post #25
hunterb123 wrote: post #9

Earlier quoted context omitted.

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.

Sometimes you don't have the resources to build a native app, or you need a web app specifically, or you need both.

What's with other's telling people what technologies is best for them when they aren't in the scenario they are in?

Post reply on HN