Netflix Likes React | Hacker News Reader

Netflix Likes React

techblog.netflix.com

197 pointstrickz55 comments

My experience says Netflix is spot on!

Runtime performance, modularity, headless testing have been absolutely critical as we've thought about how to make a hyper-extendable email client on Atom Shell. Having a consistent component architecture has let us enable 3rd party applications that just seamlessly integrate with the rest of the core email client. Now with React Native, we might be able to do this with mobile soon too!

Any links on React Native?!

It was just announced at React.js Conf: https://news.ycombinator.com/item?id=8961551

youtube video from react conf here: https://www.youtube.com/watch?v=KVZ-P-ZI6W4

Looks like they're using it for the initial profile switcher on desktop, I wonder if it will be making it's way over to the main list soon

Pic: http://i.imgur.com/cj9tD1p.png

Interesting. Also, I appreciate the included "how to screenshot" tab :)

You can also see React in use on the Your Account page: https://www.netflix.com/YourAccount

The 'main list' react app is currenty being user tested. It's likely to be more visible shortly.

Which is one thing I absolutely hate about Netflix nowadays! I usually "discover" movies to watch on "instant" directly on my Roku. When I want to use their website, it's because I saw a preview for a movie and want to add it to my (dvd) queue (since I already searched and they didn't have it in "instant"). So I type "netflix.com" in my browser, and wait 5-10 seconds before that screen loads and allows me to choose which profile to pick (and it doesn't save it, so each time I come back I have to do the same thing). Once I click a profile, it takes another 5-10 seconds to show me a list of "instant" movies and all the links actually become active. Then I can type my search term in the search box (for example, "Matrix") and faster than I can count, a list of movies pops up, and I notice I am forwarded to "dvd.netflix.com" (which, if I go to manually at the beginning, still takes >10s to load). I'm on a 100mbit connection on a late-model macbook pro and no matter which browser I choose (firefox, chrome) it's the same. Is all the slowness due to the massive amount of client-side javascript that has to be loaded and then processed? I'm not sure, but their web site has been getting slower and slower for years, not faster and definitely not more usable (don't get me started on the fact that they don't show the movie title in text w/out having to hover for 2 seconds -- trying to read the titles on many of the movie image thumbnails is unpleasant).

Streaming performance itself has always been top notch. Hard to understand how I can start a streaming movie in less time than it takes to load a list of movies in a browser.

That's strange indeed, for a couple of reasons. Even with the most JS heavy apps, 10 seconds is way too long. Most apps take 3-5 seconds for the initial load, gmail is the only app I know to take ~10 seconds. The nice thing about React is that it allows you to generate the template on a node server and send that, so you can cut down the initial load time to a second or two.

In this particular case, the Member homepage, there is a lot going on behind the scenes to render that page. Each row is computed with the most recent data possible, to ensure you see information that is pertinent for you. The pause is purely on the server side, not the client downloading assets. We are working on improving this.

They were using Ember at one point yea? I think I recall them contracting a pretty core Ember member, maybe ebryn, to work on a project.

We did and still do use Ember and Angular for various internal projects. The Netflix UI has never been Ember-based.

This is very interesting to see since I value Netflix's opinion. What's been holding me back was the pervasive JSX design. I know the react guys say that JSX is optional, but react without JSX seems cumbersome compared to, say, ember with handlebars.

It'd be interesting to hear from Netflix on the topic of JSX if they are going to grow their react codebase.

That being said, isomorphic javascript and using the vdom are really attractive and if react starts to lead those fields, then it becomes much harder to ignore.

If you think React seems interesting but JSX is a turn-off (or in my team's case a total non-starter), you might want to check out Ractive, http://www.ractivejs.org/ .

It uses some of the same ideas like a virtual DOM. Here's a writeup by Ractive's developer where he compares it to React: http://blog.ractivejs.org/posts/whats-the-difference-between...

I've been using Ractive + Reflux for two decently-sized projects and I'm very happy with it. I'll probably make the jump to React for most future project because of developer mind-share and a bunch of other smaller reasons, but I can definitely recommend Ractive.

riotjs has a complete html based style also that is interesting in this same category I think.

Curious why JSX is a total non-starter? I've always been intrigued by things that completely invalidate ideas, regardless of how good those ideas appear to be.

Is it just aesthetic (xml like)? Is it the precompiler? What is the harm with trying it out?

Boy, people never want to accept this. On my team, designers write the HTML. They own markup & styling.

Designers don't want to dig through JS files to change markup, but an even bigger problem is that it's only kinda-sorta markup. For example, if you want to set a class on an element in JSX, it's not class="", it's className="". Because class is a reserved word in JS. How many other little warts like that are there, and how are they supposed to remember stuff like that? It just wouldn't work without a lot of undue pain.

"How are they supposed to remember stuff like that?" Designers are never given enough credit. If they can handle all of the insanities of CSS (and various preprocessors), this will seem like cake.

Its just a single `render` method, generally living at the top or the bottom of a file; nothing complex.

Additionally, you stub out your static html markup first -- just like in a template -- and then you add interactivity. In an ideal world this always happens first.

It took our designer all of two minutes to learn the nuances of JSX -- className, that's it!

I would give it a shot, i'm sure they'll manage :)

No, I explicitly told them about this and they said it sounded like a nightmare. I have gotten responses like yours - that basically I don't think highly enough of designers. On the contrary, I don't think they should have to waste their time with such things just because the JSers want to do things a certain way.

A wrinkle I did not mention is that we are in the process of transitioning how we do views. The new stuff is Ractive, but the old stuff is another library whose templates are also straight HTML. So using JSX would not only incur the aforementioned problems but also "wait, this is JSX so I should use this attribute name, and this is HTML so I should use this one." It just sounds shitty to me. And to them.

The situation is not designers can't handle it, the situation is they shouldn't have to deal with that kind of crap.

So, I want to use a pretty lightweight framework, but then I'm not writing javascript anymore? I have to compile it like coffeescript? But what if I'm already using coffeescript? What if I want to use typescript?

Now I have to introduce a build step when I'm developing, or do I just say compile it on the client? If I use the new nodejs tools for visual studio, how does it affect debugging? How does it affect completion and highlighting? Does it break node-inspector? Maybe my team uses a bunch of different IDEs and debugging methods, now I have to see which ones break?

For me, it's a non-starter b/c having a framework say, "oh we recommend you write in a different language" seems so completely backwards to me.

I also don't think their justification is very convincing. Basically they say, "markup and code belong together because we think they should and that's why you should use JSX." So basically, they want people to use something that's not javascript because of a design decision they like. Weird.

All of this is trivial with the Node.js build ecosystem of 2015 -- all of it!

I am fairly certain that Ractive templates are similar to JSX in terms of overhead.

If you don't like compiling JSX you can run it with the JSX client compiler at the cost of compiling it on every client.

Ractive templates are parsed in JS just like JSX, which is why you have ractive compilers like this

https://github.com/ractivejs/rv

I think the difference the OP mentioned is that Ractive templates are mustache-formatted strings, and can be stored in external files. So you have a JS file and a template file, not the combination of both you find in React.

I don't think 16bytes said anything about any of that. React also uses mustache syntax.

Yes, indeed. I actually tried for a bit to get React templates in their own files separate from the JS, and I just couldn't do it. I know the React team's reasoning for why it's this way, but I still think it should be something devs can do if they want.

+1 for Ractive.js. The library is small and focused. It is trivial to integrate it to your application.

It seems everything Netflix touts these days has the word "react" in it :)

http://techblog.netflix.com/2013/01/reactive-programming-at-...

They mention several ambitious projects and, at the risk of beating a dead horse, I would presume that includes working with AngularJS.

I'd love to read about the shortcomings of the projects that were shelved after they settled on React.

I don't read this as saying "a series of failed projects". I think it's more about orthogonal improvements. But I don't work on this team (I do work for Netflix) so my knowledge is only slightly less indirect than anyone else.

For what it's worth, we do use Angular on some internal tools.

Can someone explain to me why virtual DOM is faster than DOM implementations of browsers?

When I read the article I understood it to be that individual actual DOM operations are expensive compared to the virtual DOM. So, if you have N operations, if you apply them to the virtual DOM, and then do a diff, you may end up with M <= N operations one must apply to the actual DOM to do to get it to an equivalent state.

Actually changing the DOM has a lot of implications. Recalculating CSS, layout, possible side effects that generate events, repainting, etc, etc. It's a lot of work to go through for an intermediate state that may not even last long enough to be visible to the user. Buffering and batching those changes can save a lot of that effort. I suppose in theory the browser could optimize this as well but in practice it seems most are still optimized for rendering static pages very quickly rather than for handling rapid changes.

Yes but WHY don't the browser makers optimize for what seems to be this very common use case? Why does a third party library outperform them?

Because when your code changes DOM, browser does not know whether you are going to stop at it for now, or do something else, so it has to re-render. In React you explicitly request application of virtual DOM changes to real DOM once you are done.

Great explanation.

In theory they could add some new methods to the DOM api to allow for this, but it would be non-standard and currently none of the browsers have it.

Something like this maybe?

batchDomChanges(); ... dom changes here ... flushDomChanges();

Or use fastdom[1], which batches reads and writes to reduce layout thrashing.

[1]: https://github.com/wilsonpage/fastdom

Well I thought that is why there is requestAnimationFrame.

React simply stores a /representation/ of what the DOM looks like (just the tree of nodes). When actually hitting the DOM, the browser recalculates styles, layout, and may preemptively calculate other things for speedier rendering. Additionally, it's a lot "heavier" so jumping through a node's children, children's children, etc. is much more expensive than plain nested objects. Therefore, it's most efficient to wait until the browser is actually about to render (requestAnimationFrame) and update only what is different in one go.

More specific details here: http://facebook.github.io/react/docs/reconciliation.html

Reactflix

People who chose AngularJS are looking more and more foolish everyday.

AngularJS was first released seven years ago. React, barely two.

I had no idea it had been so long! Time surely flies

You mean like Netflix? There's already a comment here mentioning they've used both Ember and Angular internally.

Seriously, what a pointless comment.

I wouldn't choose Angular for a new project right now because it's in no man's land: 1.x is dead, 2.x is not available, and there's no path between the two.

That said, Angular gets the job done. It scales better than people think it does (it's inefficient but modern browsers are just so fast it rarely matters) and it's a lot more complete than React. Angular is a full MVC framework while React is just about the V.

> 1.x is dead

What does that even mean? It's very much alive and 1.4 is going to be released this year.

That's like the people who called Perl 5 dead because Perl 6 was announced back in 2000.

Dead over the long term, as it has lost momentum.

Perl 5 is dead in the same way. What programming language would you recommend to someone looking to learn programming?

In 2000, you could make a strong case for Perl.

In 2015, there are a half dozen languages ahead in line.

Anyone new picking up Perl is likely doing it just for a project. Same with angular.

Completely agree with this. You can be really productive with Angular and as long as you avoid the most common pitfalls its more than fast enough, and comes with batteries included and a rich eco-system.

The crazy roadmap to 2.x, and the decisions around 2.x in general just makes it a no-go for new projects at this time.

React has a better chance because it is a micro framework or component or just the V like you mentioned.

Typical evolution of new tech is monolithic to micro, frameworks to components/modules/libraries.

In the end micro frameworks or libraries allow more flexibility to change over time.

Always bet on the micro frameworks and libraries, they can be swapped more easily and typically don't create blocks in overall architecture/design.

React is quite large in terms of lines-of-code. I would refer to it as a mili-framework instead of a micro one :)

I would say that lines of code is not a useful metric. From a developer standpoint, what I care about is how much "surface" a library adds, and in how many places. The React API is relatively small, easy to understand, and confined to a single place - rendering my views.

Why? It was a very good technology (the best?) at the time, and it remained so for a few years.

I'm very happy I picked it for my projects and I'm also very excited about React, which I would probably choose today.

Reply on news.ycombinator.com