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

Netflix: Removing client-side React.js improved performance by 50%

twitter.com

Post reply on HN
Print view View original

121–130 of 172 posts

Re: Netflix: Removing client-side React.js improved performance by 50%

#122

Post by davidpatrick »

bigmanwalter wrote: post #109
maxhallinan wrote: post #85

Earlier quoted context omitted.

> Laravel + Bootstrap + JQuery + MySQL works pretty well then this modern stuff. It's interesting to remember that Facebook started out as a PHP application. I imagine that Facebook's original tech stack closely resembled the stack you're recommending. And scaling that stack is what led to the creation of React. If you choose to build a rich user interface (like Facebook or Netflix) on top of that stack, you will lik…

That's completely untrue. I've built both SPA and traditional fullstack applications similar to the mentioned architecture (although I prefer Python over PHP). Fullstack is a fraction of the complexity, with much more power. You can even use a simple library like PJAX to get all the same speed boosts an SPA offers without introducing any of the additional complexity. To be honest, I don't see what React offers beyond…

SPAs arent meant for solving the issue of offline apps and building games in web browsers. Their target was to address the difficulty of building, maintaining, extending an ever changing UI in a corporate development environment.

Having worked on a ui in this setting, built with erb, jquery, and pjax... It is not about the degree of difficulty building it, but extending/modifying it, and collaborating with multiple crews in the same codebase. These are problems enough teams have experienced that they have moved away from the approach of jquery+handlebars.

Now granted, SPAs have a bandwagon effect because of where the job opportunities are, so you get people using them not to solve those problems, but to align their technical skills with employable skills.

Re: Netflix: Removing client-side React.js improved performance by 50%

#126

Post by dontlikeitupem »

christophilus wrote: post #83
dontlikeitupem wrote: post #47

Earlier quoted context omitted.

Considering the various components of the front end stack - increasing the number and depth of the turtles is a win now? That lady was right - turtles all the way down!

If you can get all three of these-- good performance, simple application code, and a rich UI experience-- then yes, it's a win.

If you can get all three of these -- overly complicated bloated stack, NIH compliant newness driven development, and yet another crappy poor UI experience -- then no, it's a loss.

Re: Netflix: Removing client-side React.js improved performance by 50%

#127

Post by devrandomguy »

clarle wrote: post #52

Hey, I work on the team at Netflix that gave the talk on React in the signup flow in the tweet. The full talks are available here if people want to watch them: https://www.youtube.com/watch?v=V8oTJ8OZ5S0&t=11m30s Thought I'd also provide some more context on some common questions that people have asked. ### Why are you using React to render a landing page? The Netflix landing page is a lot more dynamic than most peop…

I've been ranting here occasionally about the infuriating unprofessionalism of a web app that can't operate without JS. There is very little that you can do with JS that can't also be done with the help of a server, unless you start making up overly-specific requirements about what technologies are used, or writing user stories for robots. As a diehard NoJS guy and a developer who uses React professionally, my community's willingness to accept of the problem, and obliviousness to the solutions established by the React devs themselves, are pretty embarrassing. And it's not like I hate the language, Node has been my go-to application server for years now (Clojure is displacing that for me, but I digress).

Last year, I was building a simple SVG based chart dashboard for internal usage. Being a NoJS guy, I would sometimes disable JS while developing, on purpose or otherwise, and aside from forcing me to manually hit refresh in the browser, things generally worked. I added a couple links (styled as buttons) for zooming, to supplement the JS based drag-window zoom, and let the browser scroll the potentially very wide SVG chart within a div. If necessary, I could have even embedded the whole thing in an iframe, to avoid triggering whole page reloads, but our caching story was tight enough to compensate. Also, the React-rendered SVG represented the bulk of the markup on the page anyway.

Interactive visualisation, no JS needed. It added maybe an extra 10% to my workload (we already had the SSR stack), and helped me to avoid a variety of little glitches that plague many client-only apps, glitches that users learn to tolerate with mild disgust. The satisfaction of seeing our in-house dashboard pop up "instantly" with data, while Parsely and New Relic were still churning spinners or stuttering while waiting on JS, or even waiting for initial data after waiting on JS, was very cathartic. TTI can equal TTR, we have the technology, we've had it for a decade or so.

Re: Netflix: Removing client-side React.js improved performance by 50%

#128

Post by tomdale »

christophilus wrote: post #31

I was at the All Things Open conference this week, and Yehuda Katz gave a talk on Glimmerjs[0]. It was enlightening. The size of your front-end application is generally dominated by view code. So, they precompile views into a super simple set of binary VM instructions (making your views very compact). These views don't go through the JS compile / parse phase on the client (saving hundreds of ms, up to seconds on slow…

For folks who want to play around with this, we've got an interactive playground at https://try.glimmerjs.com/ that lets you add components, templates and helper functions.

In a nod to The Net, you can click the π symbol in the bottom right corner where you'll get a debug view of the disassembled binary bytecode.

Re: Netflix: Removing client-side React.js improved performance by 50%

#129

Post by devrandomguy »

weego wrote: post #99
solidr53 wrote: post #96

Earlier quoted context omitted.

Split code by routes? Split interactions and the view layer? fiber? Stream the render?

So just keep throwing more shit at it till it gets faster?

Yes, just like Intel. We engineered our way into this, we'll engineer our way out, and then smooth it all over with more engineering. Entropy wins again.
Post reply on HN