React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead.<p>I wasn't truly interested in React until I read this, which does a better job of spelling out React's real advantages than I ever could: <a href="http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome" rel="nofollow">http://jlongster.com/Removing-User-Interface-Complexity,-or-...</a><p>Here's a choice quote:<p><i>"Rerendering everything (and only applying it to the DOM when something actually changed) vastly simplifies the architecture of our app. Observables+DOM elements is a leaky abstraction, and as a user I shouldn't need an intimate knowledge of how the UI is kept in sync with my data. This architecture opens up lots of various ways to optimize the rendering, but it's all completely transparent to the user."</i>
I wouldn't say React isn't fast, but the OP is right, the claim that React is faster than the alternatives is basically just hype (or good marketing).<p>Going back years to React's inception and public launch, everyone's concern about virtual DOM diffing was that it would be impractically slower than fine-grained dependency tracking. Note that React's own home page expects people may be concerned about performance, and rightly does not respond with sweeping statements promising better-than-Brand-X performance:<p>> One of the first questions people ask when considering React for a project is whether their application will be as fast and responsive as an equivalent non-React version. The idea of re-rendering an entire subtree of components in response to every state change makes people wonder whether this process negatively impacts performance. React uses several clever techniques to minimize the number of costly DOM operations required to update the UI.<p>The React team and early proponents got out ahead of this concern, pushing the message that React is fast. It's faster than you'd think, they said, and in some cases faster than the alternatives. Their arguments seem to have gotten distorted and simplified by those repeating them.<p>The original arguments for why React was fast were:<p>* The DOM is very slow compared to pure JS. To the extent React's diffing is saving you from re-rendering DOM, you are winning. (Compare it to re-rendering a Backbone template, for example.)<p>* While it's true that other libraries have schemes that track fine-grained data dependencies, allowing them to go straight to the nodes that need re-rendering without doing any tree diffing, these schemes have their own overhead, which could in theory be just as high as React's.<p>When I pressed a couple React devs on the second point, it was clear they couldn't argue that tracking data dependencies would be worse than diffing <i>necessarily</i> or in general. Rather, they had concluded the two approaches were comparable in practice.<p>In summary, the DOM is pretty slow, and virtual DOM diffing is pretty fast. It means you don't have to track data changes at a fine-grained level, and you never over-render the DOM. Performance is comparable to other leading frameworks.
I don't use React for it's speed, I'm sure I can make anything using vanilla or ember, or whatever just as fast. It's the way it makes you think about things...the developers on my team are now much more productive. They can jump onto something another developer has been working on and see what each component is doing. It's the declarative nature of React and the way it makes developers think about how they compose their components that makes it a great framework. And let's not forget the reason behind a framework...for developer efficiency. There are no frameworks that are the panacea to everything either, which is probably why the framework arguments break out every single day in the JS world...people think the framework they choose is the one true solution, when in fact, there are many ways to build a building.
Pet peeve: Can we please stop blindly abusing `track by $index` without understanding it?<p>The thing with `track by $index` that nobody talks about is that, like many of the workarounds in Angular, it's a footgun in disguise. Consider this: <a href="http://plnkr.co/edit/qKm7fYZFCkXHI5pkPMYL?p=preview" rel="nofollow">http://plnkr.co/edit/qKm7fYZFCkXHI5pkPMYL?p=preview</a> and focus on the first input. Notice that the focus stays on the first input, instead of sticking with the value as it jumps around, so if you start typing, you'll acccidentally modify another item as well. Oops.<p>If you don't use `track by` (or, if you use keys as they recommend you do if this was React/Mithril/some other vdom library), you'll see that the focus stays in the input that corresponds to the value you originally clicked on, which is the correct behavior.<p>While this may seem like a contrived example, the underlying problem is that it silently messes up state synchronization between your data and the DOM. This can become a nightmare because anything ranging from jquery plugins and directives to mundane things like inputs (as is shown in the plunkr) or links with onmouseup handlers or filters become potential minefields where you are eventually forced to choose between decent performance and correctness (after the hours it took you to finally understand the problem).
The basic premise seems to be that AngularJS can be just as performant as ReactJS if you do your homework and avoid common pitfalls of AngularJS.<p>I would argue that the beauty of ReactJS is that it doesn't have any gotchas. It's performant without needing a deep knowledge of the framework.
The most important thing about React's update performance is that it's ~O(n) of the size of the virtual dom. If React's performance is a problem you can window the input data, do things more efficiently in your render, tweak shouldComponentUpdate. The goal isn't to be as fast as possible but rather to be fast enough and for non-mobile you can hit that target with only the occasional tweak. For mobile, you can get as exciting as you like[1] but I've never had to go beyond the above steps.<p>[1] <a href="http://engineering.flipboard.com/2015/02/mobile-web/" rel="nofollow">http://engineering.flipboard.com/2015/02/mobile-web/</a><p>You can build things that are faster than React in benchmarks. Pretty much every vdom based library/framework/language is faster than React in benchmarks and absolute performance has never been a stated goal of the project. The framework does help you out in ways that don't show up on benchmarks like this. An example would be batching DOM updates, which is much harder when you have components mucking around directly with their internal set of nodes.<p>I also favor using an immutable data tree with a corresponding shouldComponentUpdate and only rendering on rAF but those force architectural decisions on the project.
We need to stop this cargo cult stuff.<p>"Speed" as determined by rendering stuff to a page is actually something we can determine. Is it not possible to simply trace the framework execution? What's the point of having silly hype pieces back and forth when we're debating trivial examples that ought to be <i>not too</i> difficult to measure?<p>Finally, wrt to React: it's just a view layer. Comparing it to Ember or Angular as if it were a fully fledged, swappable alternative doesn't really make sense.
> Or the strange lack of any demonstrable examples of the performance improvements achieved by this feature... except the comparison demos.<p>React is winning because of real-world experience. Blog posts are somewhat meaningless, arguing specific nuances back and forth. Who knows what's actually right. But when you actually sit down and learn React, and use it in a complex app, you understand how easily it lets you fine-tune performance, and instead of getting in the way it helps you along the path to blazingly fast UIs.<p>Nothing is magical out of the box, the key is to help the user along the way and that's exactly what React excels at. Performance is a definite factor for choosing React.<p>Software doesn't achieve the level of fame of React (or Ember, or Angular for that matter) solely by hype. It may have a brief period of fame, but several years long of building a passionate community means there probably is something there.
There are some situations where Angular 1.x's digest/compile cycle leads to degenerate performance and where clean solutions are all but unavailable.<p>Building arbitrarily recursive structures in Angular leads to degenerate performance[1]. In this example, I had to introduce artificial timeouts during rendering so that the browser's UI thread is not completely locked out for several seconds.<p>The crux of the problem is that to make a recursive directive, Angular needs to swap back and forth between `$compile`ing newly-added markup and `$digest`ing the `$scope` that is assigned to the new markup as a part of the linking phase. It is my understanding that this issue is not manifested in React.<p>1: <a href="http://embed.plnkr.co/1gOJjJ/" rel="nofollow">http://embed.plnkr.co/1gOJjJ/</a>
From a ClojureScript viewpoint, the whole "really fast" thing is a red herring anyway. I don't care whether it's faster than Angular at rendering some tables. What I do care about is the model: my views can now be functions of my immutable data structures and I can write components that react to changes.<p>There are two performance-related issues I care about: React doesn't modify the DOM if it doesn't need to, and my components do not even re-render most of the time, because they don't need to if the data hasn't changed (and thanks to immutable data structures the comparisons are really cheap).<p>It is this approach that is revolutionary. "Really fast" has nothing to do with it. Sure, I'm glad that I can easily create complex apps that have exactly zero performance issues right from the start, but I'm not going to compete in any benchmarks anyway.
I have been using Backbone + moustache/handlebar templates and I am not clear on why use a virtualDOM. My application has several views and in my views, I use events to sync data model changes with the view and the view's render function maintains the DOM element . None of my views have to deal with the whole DOM. Therefore, I am really confused. So with my apologies for asking a dumb question : why maintain the whole virtual DOM? And what am I missing with Backbone + mustache based approach ?
It seems to me they're missing the point. The implementation of ng-repeat is quite complex, and if, for some reason, it doesn't do what you want and you decide to write your own directive you have to deal with mutating the DOM in an efficient manner yourself.
React on the other hand allows you to just generate your DOM structure and be fairly confident in it performing well by default.
We worked really hard to try to optimize angular code to make it "Fast enough" for our cordova app.. On the web, it doesn't really matter because everything was <20ms, but on the phone, the same operation was >250ms. We tried lots of hack with angular, and eventually, I tried replacing the slowest view with React. And without hack it was so much faster. It's obviously possible to do the same thing with Angular by not using the dirty checking (or not using $scope at all), but at this point, you're not really using angular anymore).<p>Point is, for us, React led to a much cleaner and faster code. I was also waiting for an excuse to jump on ES6 and prefer the controlled state/props to the $scope/directives philosophy. We're not using flux but have been highly inspired by it and (Optmimizely's) nuclear.js library.
Developers have a tendency to get overly excited about speed. Fast database, fast search, fast framework, etc. The truth of the matter is that speed should be evaluated within a spectrum. As long as your application latency is within a spectrum, you should be just fine
Riot.js loops were fixed today. They are now around 4x faster than in React.<p>React: <a href="http://jsfiddle.net/brianmfranklin/w674Lv7p/" rel="nofollow">http://jsfiddle.net/brianmfranklin/w674Lv7p/</a>
Riot: <a href="http://jsfiddle.net/gianlucaguarini/cbjuek58/" rel="nofollow">http://jsfiddle.net/gianlucaguarini/cbjuek58/</a><p>just FYI
While the article shows some really good performance improvements, the tone is really sensationalist. While challenging 'comparison demos' in leiu for proof, the author responds with... yet another comparison demo<p>The title is not entirely falsified either - ReactJS is fast out of the box. Other frameworks can be tuned to achieve comparable speeds. But in most cases, ReactJS still wins.
When I was using Angular I thought doing something like<p><pre><code> setTimeout(function() { $scope.$digest(); }, 0);
</code></pre>
was an ugly hack and a sign of angular's leaky abstractionism showing up. Is this considered a good practice now (or always was)?<p>Edit: just to clarify, I'm asking because in OP this was given as a one of the way to fix Angular speed issues.
As I was mumbling to myself in a recent other HN comment, it has become clear to me that few people take the time to actually understand the speed differences between various technologies. Even as "everybody" says how benchmarks are useless, "everybody" still uses the most trivial microbenchmarks to decide what's fast. (Perhaps the uselessness of benchmarks has more to do with "everybody" taking cognitive shortcuts than the benchmarks themselves....)<p>Amusingly, this produces the result that almost every technology is faster every other tech, with the exception of the technologies that are vastly more powerful than something else, but still at least as fast (i.e., Python is at least as fast as C at some task, so it must be as fast as C in general, right?).<p>(The natural reaction to <i>that</i> is to assume that there is no such thing as speed differences, but, alas, that's not true either. No easy answers! There are things that are faster than other things at some tasks. And there are jobs where you really need to know which is which because even today, the difference between a 50-node cluster and 1 machine that does it all is quite monetarily significant....)
The final point of the argument is the best to me. I originally chose using React because it appeared different from everything else. Thus far I feel I have been able to be much more productive and also think about things in my web application differently. The fact that is it fast is only secondary to the fact that I feel I can great a robust and maintainable codebase with more ease than I could with other frameworks.
Seems strange that you have to use "track by" to get a speed up when it's meant to be used for something completely different. Is this really a "fix" to slow ng-repeats? Are there any side effects?
I think many of the "advantages" of ReactJS are just hype<p>- Immutable data, one directional data flow are easier to learn, understand, harder to break etc. - This isn't anything new, these are just concepts taken from declarative programming. You could always have used those concepts in your JS. They aren't better/worse than imperative programming. That's like saying Haskell is better than C++.<p>- Two-way binding creates infinite loops! - Umm... not if you're a half-decent programmer. I've worked with complex single page apps for years, even with junior developers, it's never been a problem.<p>- ReactJS is so much faster - Only in unrealistic benchmarks as this illustrates (Mithril is faster in those benchmarks BTW)<p>React also has a few major downsides:<p>- JSX breaks your IDE's error checking and line numbers in error messages (and not using JSX is a pain/verbose)<p>- Being only the V in MVC leaves out too much. Now you have to patch together a URL router, http/socket communication script, custom solution for managing the model, etc.
Ok the authors of 2 talks missed the Angular DSL to speed up the rendering of a 2D table. But what about deeply nested tree structure that change ? Is there a DSL to speed up that too ? If the author want a demonstration maybe he could try that.
No kidding. I've been saying that frameworks like Angular, Ember etc. do their dirty-checking in the MODEL, whereas React, Mithril and others do their dirty-checking in the VIEW.<p>The former sometimes get some misses when the underlying data changes but the bound views stay the same. And how often does that really happen? On the other hand, "two-way data binding" is extra sugar that is, indeed, slow. Even Angular 2 got away from that.<p>So what is the point of using React or Mithril? Well, there are two. One is if you enjoy having idempotent rendering functions rendering EVERYTHING OFFSCREEN ON EVERY FRAME for making 1-1 correspondence between "state" and "view" explicit. The other is that Facebook actually uses it in their own products, and open-sources React Native, so you can technically build native apps (if you're willing to put up with their embedded JS environment instead of the browser's). And since they are so enthusiastic about it, maybe someday you will be able to re-use a bunch of components Facebook, or others, write for you, in your apps.<p>Personally, I will prefer <a href="http://platform.qbix.com" rel="nofollow">http://platform.qbix.com</a> ;-)
Setting aside all arguments in the article, I am just generally annoyed by the simple fact that he calls React a "framework" in the article. It's a library, not a framework.<p>Angular is a framework; it includes everything that you need (and in most cases, significantly more than what you need). You can build an entire web application using Angular without any other external libraries. On the other hand, you usually need to combine React with a router and some library to manage state (or stores/actions if Flux).<p>For this reason, we shouldn't even be comparing "Angular v. React". They aren't equal and they were not meant to be compared. If want to make a worthwhile comparison, try a "Angular v. React with Flux Architecture".<p>...but, honestly, can we just stop writing articles like this? What purpose do articles like this serve other than saying, "X tool that I use is better than Y tool that you use and here is why"? If you really want to share knowledge, write about best practices, anti-patterns, etc. Good riddance.
>People have sent me links to a number of other demos. All are simply missing 'track by'.<p>really people? I knew most of the people spewing the angular hate didn't know what they were doing but this is kinda silly.
Virtual DOM diffing (the approach taken by React) is "faster" because, in the most simplistic definition, you can intuitively come up with the optimization mentioned in the article as it needs to know what exactly changed to calculate. What's good with React is that it does some of it automatically (with the keys and the structure you have to provide) and also gives you control with the "shouldComponentUpdate" method.<p>Edit: Down-voters care to comment?
The jsblocks library authors are being incredibly deceitful with the tests they are showing off. Their entire premise is that they are faster than react but their tests are just manipulated.
They posted this up on product hunt, <a href="http://www.producthunt.com/posts/jsblocks" rel="nofollow">http://www.producthunt.com/posts/jsblocks</a>, and at that point it claimed to be at 800ms on initial load where as react had 1250ms. I checked out the react code and there was a hidden input that was being rendered with every td element on the table. React has very heavy inputs which is why you are supposed to use state.<p>original test (with hidden td elements)<p>js blocks: 800ms<p>react: 1250ms<p>After removing hidden element<p>jsblocks: 350-400ms<p>react: 200-350ms<p>So yes, jsblocks can render a lot more input elements that you shouldn't be using faster than react. The react team explains why the inputs are fairly heavy when rendering a large amount, <a href="https://github.com/facebook/react/issues/3771" rel="nofollow">https://github.com/facebook/react/issues/3771</a>
They didn't stop there though and they responded to my claims and came back with a new test. This time they just ramped up the number of data points by double and added an extra td element to make it an unreasonable absurd amount of elements.<p>revised test (original test of 5000 elements to 18000 elements)<p>jsblocks: 600ms (they posted 700ms, so ill give them that)<p>react: 700ms (they posted 950ms)<p>After removing half of the data to about 9000 elements react already started to tie jsblocks<p>jsblocks: 450ms<p>react: 450ms<p>Going down to about 5000 elements<p>jsblocks: 250ms<p>react: 200ms<p>Whether or not there is any merit to this library, you can't just go claiming that you have the fastest library so audaciously like this blog post and their marketing. It's terrible for the community. There are an absurd amount of javascript libraries and getting devs to push a few key frameworks forward is already difficult enough. And if you are going to add another library to the list, at least be able to back up your claims.<p>I will admit that jsblocks seems to be better at rendering extremely large amounts of tabular data, but that is never an issue for me and you should be using lots of different techniques to mitigate that anyway. But once you get to realistic scenarios react is still faster and comes with tons of other advantages.<p>I didn't test the angular one because I don't know enough to spot odd code, but without even looking into the code the fact that angular was the only one that didn't have a minified library seems fishy. It's at 900+kb compared to the jsblocks/react at 125ish kb. To me it seems like since status qua is react is faster and angular is slower, they just constructed these tests to make it 3. angular, 2. react, 1. jsblocks (the fastest library ever!!).<p>So there's my rant. Please stop promoting your library like you are, it's just distasteful.<p>edit: <a href="https://drive.google.com/folderview?id=0BxTyg4RuMOHUfjlvTkN3dzRaSU4wckh0b3lST3lrb3lzekdWVWhVSlJfWlRsLWszR0RuYjQ&usp=sharing" rel="nofollow">https://drive.google.com/folderview?id=0BxTyg4RuMOHUfjlvTkN3...</a> Here's a link of the original test without the hidden elements, the response test that required a ton of elements, and the email they sent still talking about their amazing speed!
IMO Angular1 and React are so different in their approaches that it does not even make sense to compare them. If you want to base your application on a 'kind of' functional design with sane reasoning you should know what to use.<p>With Angular2 the discussion will be more interesting, but as far as I know Angular2 is not quite production ready.
I tried to quantify the performance numbers - and react does show virtual DOM rendering improvements, but eventing is expensive.<p><a href="http://blog.nparashuram.com/2015/03/performance-comparison-on-javascript.html" rel="nofollow">http://blog.nparashuram.com/2015/03/performance-comparison-o...</a>
I really don't like Angular (mostly down to dependency injection, issues I had getting some of the components to work with mobile and it's markup ngAttributes mess) and it put me off React until recently. React is superb and a really new way of thinking about user interface components.
AngularJS is like writing in assembly. Sure, if you work really hard you can make it as performant as compiled C (ReactJS), but by that time your C buddy has built so much functionality you might as well stop all together.<p>(note: I've done professional angularjs and reactjs projects)
Just a question - why is immutability considered a performance improvement when in general it leads to performance degradation? I always assumed it supports a nice conceptual framework when dealing with difficult parallel algorithms but that's about it.
From other devs I know they have said React functionality on mobile is quite poor. Drag and drop and scroll, doesn't work as well, because the virtual DOM isn't adapted work to well on mobile. So for that reason, I won't use React, and rather go Vanilla or use Backbone. After getting burned by Angular, I'm really weary to adopt another fancy framework.
Shows how far too many developers don't question claims but take this stuff for real. Put it on a nice website with a cool domain name, fake some statistics and voila: Your new, web3.0 tech is out there. Bonus points if you are Google/Facebook/Apple.<p>Even if the article itself will be debunked as wrong, i feel that too many tech-savy people are too superficial.