7 ms·
Netflix Likes React
- ihsw 12y agoThey 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 12y agoI 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.
- lsdafjklsd 12y agoThey 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 12y agoWe did and still do use Ember and Angular for various internal projects. The Netflix UI has never been Ember-based.
- sehr 12y agoLooks 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
- ohitsdom 12y agoInteresting. Also, I appreciate the included "how to screenshot" tab :)
- mjr578 12y agoYou can also see React in use on the Your Account page: https://www.netflix.com/YourAccount https://www.netflix.com/YourAccount
- bshenanigan 12y agoThe 'main list' react app is currenty being user tested. It's likely to be more visible shortly.
- saberworks 12y agoWhich 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.
- mjr578 12y agoIn 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.
- findjashua 12y agoThat'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.
- 16bytes 12y agoThis 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 12y agoIf 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-react-and-ractive/ http://blog.ractivejs.org/posts/whats-the-difference-between...
- mercer 12y agoI'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.
- proksoup 12y agoriotjs has a complete html based style also that is interesting in this same category I think.
- cnp 12y agoCurious 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?
- 12y ago
- kuni-toko-tachi 12y agoPeople who chose AngularJS are looking more and more foolish everyday.
- illicium 12y agoAngularJS was first released seven years ago. React, barely two.
- robertfw 12y agoI had no idea it had been so long! Time surely flies
- lucisferre 12y agoYou mean like Netflix? There's already a comment here mentioning they've used both Ember and Angular internally. Seriously, what a pointless comment.
- svachalek 12y agoI 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.
- foxclaw 12y ago> 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.
- lumpypua 12y agoDead 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.
- deleted 12y ago[deleted]
- e0m 12y agoMy 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 12y agoAny links on React Native?!
- peterjmag 12y agoIt was just announced at React.js Conf: https://news.ycombinator.com/item?id=8961551 https://news.ycombinator.com/item?id=8961551
- deleted 12y ago[deleted]
- joeyyang 12y agoyoutube video from react conf here: https://www.youtube.com/watch?v=KVZ-P-ZI6W4 https://www.youtube.com/watch?v=KVZ-P-ZI6W4
- deleted 12y ago[deleted]
- zkhalique 12y agoIt seems everything Netflix touts these days has the word "react" in it :) http://techblog.netflix.com/2013/01/reactive-programming-at-netflix.html http://techblog.netflix.com/2013/01/reactive-programming-at-...
- EGreg 12y agoCan someone explain to me why virtual DOM is faster than DOM implementations of browsers?
- collinvandyck76 12y agoWhen 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.
- svachalek 12y agoActually 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 12y agoYes 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 12y agoBecause 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.
- jonathancreamer 12y agoGreat explanation.
- jonathancreamer 12y agoReactflix