Netflix functions without client-side React, and it's a good thing | Hacker News Reader

Netflix functions without client-side React, and it's a good thing

jakearchibald.com

80 pointsrbanffy13 comments

React is already championing this - React 16 has the new hydration function specially designed for exactly this kind of scenario. There is now complete and official support for the following paradigm:

* Write your app as React views

* As much as possible, render either the app skeleton or the full view on server

* Serve rendered HTML with async/deferred JS tags https://reactjs.org/docs/react-dom-server.html

* Optionally hydrate the HTML with React whenever the JS is done loading. https://reactjs.org/docs/react-dom.html#hydrate

* If the current page is a static page and doesn't need JS, don't even bother loading any JS. Just use https://reactjs.org/docs/react-dom-server.html#rendertostati... to begin with.

So Netflix homepage, not signed in, has no React. It is the page that doesn't even need React.

If you are signed in, then you will not see Netflix landing page and go straight to their app which has React.

I feel people are misunderstanding what Netflix meant in their tweet.

Reading the post helps address a misunderstanding about misunderstandings:

>> Netflix uses React on the client and server, but they identified that the client-side portion wasn't needed for the first interaction, so they leaned on what the browser can already do, and deferred client-side React. The story isn't that they're abandoning React, it's that they're able to defer it on the client until it's was needed. React folks should be championing this as a feature.

I’m not sure I would consider this a feature. It’s just a trade off like anything else. If the page is blank on load for >2s, I’m gone. Similarly if the page is unresponsive for >2s I’m gone (even if it painted in that period). Netflix doesn’t necessarily have this issue because the general population knows what they provide, but generally speaking it’s 6 of one, half dozen of the other.

Neither of these are true of Netflix’s home page, though. They’re not deferring React and thus causing unresponsivity; they’re deferring React and handling the interactions on the home page using server-side rendering and regular JavaScript event handlers. React is loaded in the background so that it can be there when you log in and thus load the “app” part of Netflix; not so that it can “kick in” after 2s to drive the homepage.

What they've done makes complete sense, and is probably the way more developers should start looking at SPAs.

The initial page load doesn't use React. It doesn't need it. Its a pretty simple page with a bunch of links and a couple of signup/signin buttons. Once you click one of these links, the subsequent pages load React in order to handle the richer client-side interactions on those pages.

Seems reasonable. React allows for a better User Experience than static pages, but at the cost of additional load time. So don't load it on the first page, when your users are most likely to bail, and then load it once you need it.

Maybe we're starting to see the pendulum swing back the other way. 3 or 4 years ago, we seemed to go from 'SPA Nowhere' to 'SPA Everywhere,' and now maybe we're settling on 'SPA Where We Need It'

Call me cynical, but I've a feeling that "SPA Where We Need It" would creep into being the static pages plus more and more snippets of jQuery scattered around as time went on, to "just make it do this....". Projects go that way. In other words, back to the bad old days with swathes of unstructured frontend spaghetti. Walked into a lot of those codebases on contracts.

A headline like "Netflix functions without client-side React" is certainly not helping the confusion.

With the risk of being downvoted, I would like to share my thoughts.

IMHO I find that many people on HN continuously seek for an excuse to not ship that product or that particular feature that caused them so many hours of frustration. I know the feeling. I have this feeling constantly because making software is hard! Some of our internal modules took me months to develop and get them right. Regardless of the language, regardless of the platform there always will be tradeoffs.

Let's not panic when companies like Netflix decide to remove React from their landing page. They have their own problems and they are certainly not my problems. Frankly, I consume Netflix on my TV so I do not care how their web page loads.

In terms of React, it has been a godsend for my business and if I have to I will pay for it. React is not the kind of thing you want to put in a simple application or to build a simple widget. React is useful when you build complex, state-aware applications in web technologies or mobile. Although I will choose to use React if I need to build the UI of Netflix, it is true that given that the UI is rather simplistic, it can be done better in a bit of javascript and CSS.

I have also looked into other technologies that are advertised as React alternatives such as Vue.js. My personal experience is that they do not even come close. They may have similar features but there are certain things in React and JSX that are just better and straightforward. Some of the applications we are currently working on (not public yet) are so complex internally that I cannot even begin to contemplate re-implementing them in anything else. The productivity gain will be negative in my opinion. We are constantly looking for alternatives but React for me is the best that fits my problem domain.

I hope this comment is helpful.

TLDR: Clickbait

Let me fix the title for you:

"Netflix renders their landing page on the server. Preloads other code while you're signing in."

Revolutionary.

> A few days ago Netflix tweeted that they'd removed client-side React.js from their landing page and they saw a 50% performance improvement.

Are you telling me that serving a small, cached HTML page takes less time than downloading and running a full-fledged SPA? Gee whiz mister!

> It caused a bit of a stir.

Nope, but it gave people a good laugh.

> the headline boils down to: less code was executed and stuff got faster.

You bet.

Cant't wait for 2020: Did you know about this new cool thing? Render websites in back-end and cache them. It's super fast and non-taxing on the browser. It's clearly the future fo web-development!

At this point I fear it would take a strong carbon tax to achieve that.

Building inefficient systems is attractive when you externalize all that inefficiency onto other people.

Taken from this talk:

https://www.youtube.com/watch?v=V8oTJ8OZ5S0

Reply on news.ycombinator.com