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

51–60 of 67 posts

Re: Server Side Rendering at scale

#51

Post by hunterb123 »

southerntofu wrote: post #19
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. Any .html page works offline. You don't need any JS or framework for that. If your JS-powered page doesn't work offline, it means either it requires online connectivity to solve problems, or its badly designed and does not respect "progressive enhancement" principles. > SSR improves the user experience for first time use of those app SSR improves UX for ev…

I'm talking specifically about SPAs, I feel I was clear about that.

Yes, people usually reach for an SPA when they just need a site, but SPAs have their uses.

Re: Server Side Rendering at scale

#52

Post by dgb23 »

DerArzt wrote: post #38
mahesh-hegde wrote: post #32

Earlier quoted context omitted.

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

Yeah, anything like what you described are going to be web apps and need all that logic. That being said for the majority of the web (news sites, simple message boards, shopping sites, etc) couldn't they all be rendered on the server? I have to wonder how much of the client-side rendering framework use is mainly from people forming a cargo-cult around "it's what Facebook does" when at the end of the day what Facebook…

All those sites have content, which require elaborate, interactive, collaborative editing and reasonably complex, flexible data models. Meaning you’re going to want to re-use much of the work you did for the editing/publishing part and you want those things to be integrated to such a degree that changing and extending things is reasonably ergonomic.

Re: Server Side Rendering at scale

#53

Post by pjmlp »

dgb23 wrote: post #52
DerArzt wrote: post #38

Earlier quoted context omitted.

Yeah, anything like what you described are going to be web apps and need all that logic. That being said for the majority of the web (news sites, simple message boards, shopping sites, etc) couldn't they all be rendered on the server? I have to wonder how much of the client-side rendering framework use is mainly from people forming a cargo-cult around "it's what Facebook does" when at the end of the day what Facebook…

All those sites have content, which require elaborate, interactive, collaborative editing and reasonably complex, flexible data models. Meaning you’re going to want to re-use much of the work you did for the editing/publishing part and you want those things to be integrated to such a degree that changing and extending things is reasonably ergonomic.

That is why for 20 years SSR frameworks have supported components.

Re: Server Side Rendering at scale

#54

Post by pjmlp »

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.

Just like JSF frameworks, with Prime being the best one.

Re: Server Side Rendering at scale

#55

Post by eyelidlessness »

sod wrote: post #43

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. Bu…

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

Depending on use case/workload, the bottleneck is mostly startup time. Message passing is much faster than most people think, and the main thread ideally is primarily just doing that and getting out of the way. Spinning up new processes is more expensive and so is IPC. Of course if you don’t need coordination…

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

Sure. If you’re running a stateless server. To be honest it’s not clear to me whether that’s the case here. But for other use cases where coordination is needed and which would benefit from concurrency, worker threads are often the best solution for Node.

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

There are lots of solutions in this space. Whether they’re worth adopting largely depends on their maturity and your team’s ability/willingness to adopt them.

Re: Server Side Rendering at scale

#56

Post by midrus »

I can't believe this madness. Is it worth? What if you just didn't build an SPA?

But pretty sure some engineers are having tons of fun building this stuff there. good for them and their CVs.

Re: Server Side Rendering at scale

#57

Post by LAC-Tech »

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.

Are you genuinely telling me there are no issues with sharing memory between different threads?

Node.js is 13 years old now. I get that a lot of people think it's some new thing that only dumb frontend programmers who only know JS use, back in my day, grumble grumble. But at this point it's established, mature technology, es6 is an expressive language (much, much more so than Go, C# or Java). The multi process concurrency model is sometimes a pain in the ass and sometimes just want you want.

I've used ASP.NET and node.js in anger, have you? Or do you just attack it because you hate the JS of 2010?

Re: Server Side Rendering at scale

#58

Post by anko »

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

Earlier quoted context omitted.

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.

Are you genuinely telling me there are no issues with sharing memory between different threads? Node.js is 13 years old now. I get that a lot of people think it's some new thing that only dumb frontend programmers who only know JS use, back in my day, grumble grumble. But at this point it's established, mature technology, es6 is an expressive language (much, much more so than Go, C# or Java). The multi process concur…

> Node.js is 13 years old now.

> But at this point it's established, mature technology

I have to disagree. Day to day I maintain a variety of node.js, scala and kotlin services. By far, the most gotchas have been from the node.js services.

Simple things like validating incoming payloads are made ridiculously complex. You can get a library to do that, but which do you use? And then most of them don't export the typescript type signature so you don't get any type safety unless you re-define the type in typescript.

Let's say you want a tiered caching library? I've spent weeks of my life debugging concurrency issues because the memory store shared objects whereas the redis store didn't (because they were serialised and sent to redis). That's on the most voted caching library for node.

The quality of node.js libraries in general is far below that of scala/kotlin, and the maintenance cost is way higher. You can't easily tell if signatures for the apis of the libraries you import have changed as well. The ecosystem is still moving very fast, and while I agree that es6+ makes it a much better language, it causes its own issues when interacting with older code/libraries.

Expressive as the language may be, in production systems it leads to poorly understood code because of all the ways to do simple things, and the gotchas associated (something i believe it shares with scala).

> The multi process concurrency model is sometimes a pain in the ass and sometimes just want you want.

Give elixir a serious go and see if you ever say this again. Concurrency should be managed, much like garbage collection has been for 30 years.

Re: Server Side Rendering at scale

#59

Post by LAC-Tech »

anko wrote: post #58
LAC-Tech wrote: post #57

Earlier quoted context omitted.

Are you genuinely telling me there are no issues with sharing memory between different threads? Node.js is 13 years old now. I get that a lot of people think it's some new thing that only dumb frontend programmers who only know JS use, back in my day, grumble grumble. But at this point it's established, mature technology, es6 is an expressive language (much, much more so than Go, C# or Java). The multi process concur…

> Node.js is 13 years old now. > But at this point it's established, mature technology I have to disagree. Day to day I maintain a variety of node.js, scala and kotlin services. By far, the most gotchas have been from the node.js services. Simple things like validating incoming payloads are made ridiculously complex. You can get a library to do that, but which do you use? And then most of them don't export the typesc…

Simple things like validating incoming payloads are made ridiculously complex. You can get a library to do that, but which do you use? And then most of them don't export the typescript type signature so you don't get any type safety unless you re-define the type in typescript.

I strongly recommend Zod[0]. You write your schemas in code, it validates incoming JSON at runtime, and you end up with either an error or well typed code. The schemas themselves are powerful (you can check properties of strings, etc), and the derived typescript type comes out for free and looks like a human wrote it. A very powerful tool, with a very intuitive interface.

Give elixir a serious go and see if you ever say this again.

Ah you hit me where it hurts - really need to seriously try the Erlang ecosystem.

[0]https://github.com/colinhacks/zod

Re: Server Side Rendering at scale

#60

Post by anko »

LAC-Tech wrote: post #59
anko wrote: post #58

Earlier quoted context omitted.

> Node.js is 13 years old now. > But at this point it's established, mature technology I have to disagree. Day to day I maintain a variety of node.js, scala and kotlin services. By far, the most gotchas have been from the node.js services. Simple things like validating incoming payloads are made ridiculously complex. You can get a library to do that, but which do you use? And then most of them don't export the typesc…

Simple things like validating incoming payloads are made ridiculously complex. You can get a library to do that, but which do you use? And then most of them don't export the typescript type signature so you don't get any type safety unless you re-define the type in typescript. I strongly recommend Zod[0]. You write your schemas in code, it validates incoming JSON at runtime, and you end up with either an error or wel…

appreciate the tip on Zod :) It looks like what i've been looking for!
Post reply on HN