

Netflix Likes React - trickz
http://techblog.netflix.com/2015/01/netflix-likes-react.html

======
e0m
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!

~~~
hgezim
Any links on React Native?!

~~~
peterjmag
It was just announced at React.js Conf:
[https://news.ycombinator.com/item?id=8961551](https://news.ycombinator.com/item?id=8961551)

------
sehr
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](http://i.imgur.com/cj9tD1p.png)

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

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

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

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

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

~~~
serve_yay
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/](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...](http://blog.ractivejs.org/posts/whats-the-difference-between-
react-and-ractive/)

~~~
cnp
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?

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

~~~
cnp
"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 :)

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

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

[http://techblog.netflix.com/2013/01/reactive-programming-
at-...](http://techblog.netflix.com/2013/01/reactive-programming-at-
netflix.html)

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

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

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

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

~~~
EGreg
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?

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

~~~
blktiger
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();

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

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

------
jonathancreamer
Reactflix

------
kuni-toko-tachi
People who chose AngularJS are looking more and more foolish everyday.

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

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

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

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

