15 ms·
Is ReactJS really fast?
- tothepixel 11y agoThe authors "prove me wrong" attitude is awesome, and I hope we see some deeper diving into virtual DOM performance in a follow-up article.
- mgkimsal 11y agoThe tl;dr I get from this is that angular docs don't do a good job of actually documenting "fast by default" options.
- whoisthemachine 11y agoThe 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. 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.
- dubcanada 11y agoReactJS is also a UI framework. AngularJS is a giant beast that literally does everything you need. They are not comparable, with the complexities of things like DI and stuff of course one of easier.
- aikah 11y ago> 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. While AngularJS(1.x) is a bit faster now, your comment is a bit like saying Ruby can be equally fast to Java if one does it homework. AngularJS has architectural problems that can only be reduced if one doesn't use much of angular features(scopes,watches) inside directives(which means writing components in pure js). So it takes a huge effort to make angular fast in general. That's the reason why they are creating an entirely new framework with version 2.x (which I believe is a mistake, Angular 1.x despite its flaws was pragmatic, 2.x isn't). React is faster for a few reasons: there are no templates in react, everything is js code React does all the heavy computation outside the DOM so manipulations are minimal and there is no two-way data binding by default, the data flow is unidirectional. Obviously the angular team wants the same stuff since it has proven it is a better architecture.
- dmak 11y ago> AngularJS has architectural problems that can only be reduced if one doesn't use much of angular features(scopes,watches) inside directives(which means writing components in pure js). That's an interesting piece of advice there. Could you go more into this?
- jhummel 11y agoWe've found this out at one of my contracts. We've moved off of the typical $watch/$apply model for our directives and replaced it with a simple observable solution like Scheming (https://github.com/autoric/scheming https://github.com/autoric/scheming). Our components are always watching attributes on our Scheming models, which are outside the digest cycle. It speeds things up, and is much nicer to work with IMO.
- awinder 11y agoGiven the above discussion about the great performance differences largely being rectified by using angular's `track-by`, I think we can rule out templates as a major driver of performance grief. Templates are usually compiled into native javascript code once (or at least, can and should be), so I really don't see how there should be grand differences between what React is doing and how template processors work. This, by the way, is an EXCELLENT example of the kind of arguments that have come out of the React.js camp that give me a lot of pause. There's radical differences made in how frontend applications are developed with React, and the primary selling point that I kept hearing was "embrace it, the performance difference is HUGE!". Then as arguments come out about how the performance differences have caveats, the arguments switch to "...well this is how we should be developing, for X, Y, and Z architectural reasons". I'm not saying that X, Y, and Z aren't valid discussion points, but it's been wrapped up in so much pseudo-technical FUD, and that's pretty unfortunate. Signed, Recovering Template-Aholic
- aikah 11y ago> Templates are usually compiled into native javascript code once no they aren't. > (or at least, can and should be) not by default. React doesn't have templates at all ,so case closed.
- Bahamut 11y agoReact just passes the gotchas to you in architecture - if you make a mistake, it increases the likelihood of the pain down the road. It also is more complex in required build tooling. That is not to say that it is a good or bad thing - each person's/company's needs are different. I use both React and Angular - I am a lot more performant developing with Angular due to exposure to it the past 2 1/2 years, but I like both libraries.
- whoisthemachine 11y agoHopefully that means the gotchas will be more visible to everyone, but obviously that's dependent on the direction of the architecture.
- Touche 11y ago> 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. shouldComponentUpdate is just as "deep" as this Angular optimization.
- TheCoelacanth 11y agoJust use PureRenderMixin for all components and you never have to implement shouldComponentUpdate.
- woah 11y agoshouldComponentUpdate is generalizable across any type of component. The angular thing looked like something array specific.
- Cshelton 11y agoI 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.
- Murkin 11y agoThis is a great point, ReactJS has many benifits. People should choose it based on those merits not "speed".
- moonchrome 11y agoIf you really buy in to react for the benefits of easier to reason about code then you should be using clojurescript on top of it.
- nogridbag 11y agoI was swept away by the React hype a bit. I tried to sell my team on React by stating many of the same points and eventually we decided to stick with our current JS framework: ExtJS. And I'm thankful I was overruled a bit. For our team and the types of applications we're building ExtJS simply makes much more sense. I've used React now for a simple web app and also a Chrome extension. For certain UIs scenarios like Facebook's ad example, the React method of rerendering everything definitely makes things easier. But in most applications, I think such a complex UI is usually rare and ~80% of the UI screens are usually fairly simple. For the majority of UI screens, React or perhaps React+Flux complicates things by adding unnecessary boilerplate even when using third party Flux implementations.
- buster 11y agoShows 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. Even if the article itself will be debunked as wrong, i feel that too many tech-savy people are too superficial.
- BFay 11y agoI think the bigger appeal of React isn't the "performance." It's the fact that you can reason about your app as if you are re-rendering the entire application with every change in state. That way you never have to think about mutating the DOM, and you have less places to screw up. If you actually re-rendered the whole app with every state change, it wouldn't be performant, but with the virtual DOM, it's totally feasible. It is definitely unfortunate that developers take statistics for granted (I'm guilty of this), but it doesn't undermine the usefulness of the framework.
- buster 11y agoAh yes, BUT you can't deny that one of the major selling points of React after its announcement was its superior performance due to its DOM magic. May be one selling point, but nevertheless a major selling point. Now, every one says "oh, but i don't care for the performance, i like that React can do XYZ" instead of proving the author wrong. Why? Because in truth 99% of developers would have no idea how to do it. I'm convinced that there is a significant amount of web developers who wouldn't even know how to write a web page in plain JS, CSS and HTML without the use of a myriad of tools that generate stuff for them. Same for other areas. If not for aphyr most people wouldn't even know how to test a database.
- marknutter 11y ago> It's the fact that you can reason about your app as if you are re-rendering the entire application with every change in state. That way you never have to think about mutating the DOM, and you have less places to screw up. This is really no different than Angular's value proposition - everything is bound to the DOM via the scope and re-renders automatically with every change in state.
- jlongster 11y ago> Or the strange lack of any demonstrable examples of the performance improvements achieved by this feature... except the comparison demos. 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. 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. 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.
- Ryan_Shmotkin 11y agoMongoDB ?
- feedjoelpie 11y ago> Blog posts are somewhat meaningless, arguing specific nuances back and forth. I disagree. Your "Bloop" blog post about React with its game loop analogy totally opened my eyes. That's the first time I really "got it". Moved my org to React for all new development and haven't looked back. So thank you for your "somewhat meaningless" blog post!
- ckluis 11y agoIronically, he mentions ember which is in the process of adopting the virtual DOM based approach.
- iamstef 11y agoThis isn't entirely accurate as ember essentially diffs the dynamic values, but not DOM (or vDOM). In Ember the DOM is typically produced from pre-compiled templates and values are used to hydrate those templates or choose which templates are rendered. Obviously exceptions exist, but this is by far the most common scenario. When ember goes to "Detect" what changed, is basically ignores the DOM, and looks at the dynamic joint values such as {{#if firstName}} or {{lastName}}. Using this information, in then decides what DOM mutations are needed to bring the DOM back into sync. As a side note: Babel.js has some related optimizations for JSX/react uses. This all means, for DOM creation and updates the actual DOM is used. Now this may sound scary, as we all hear the DOM can be slow. But as it turns out, some aspects of the DOM are actually quite fast, and often faster then the alternatives. For example: * fragment.cloneNodes to produce new content * node.textContent to update content – nicely leaves content inert, without needing costly JS based XSS escaping. There are obviously downsides to either approach and as such likely some hybrid is ideal.
- jerf 11y agoAs 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....) 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?). (The natural reaction to that 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....)
- feedjoelpie 11y agoReact.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. 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: http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-... Here's a choice quote: "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."
- iSnow 11y agoThe author however has focused specifically on the often read speed advantages. They use it themselves and he apparently likes it.
- feedjoelpie 11y agoI guess the point I'm getting at is that the virtual DOM's speed is really just the answer to the question "But isn't re-rendering the whole world over and over really slow?" Which is the first thing anyone deeply familiar with web UIs would ask. It's the solution to a problem that arises when you move to this programming model. It's the programming model that's the real advantage. The virtual DOM's speed is worth mentioning because it remedies what would otherwise make React completely impractical in the real world.
- axemclion 11y agoVirtual DOM makes rendering fast, but it has extra costs in eventing and in javascript timers. Virtual DOM is not free IMHO. Some quantitative results - http://blog.nparashuram.com/2015/03/performance-comparison-on-javascript.html http://blog.nparashuram.com/2015/03/performance-comparison-o...
- henriks 11y agoIt 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.
- dj-wonk 11y agoIn the article: > This little change ["track by"] invalidates 95% of comparisons between ReactJS and AngularJS. Please, let's stop using arbitrarily specific numbers with data to back it up.
- feketegy 11y agoIt's not everything is about speed, I would choose manageability over speed anytime
- arocks 11y agoWhile 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 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.
- tipiirai 11y agoRiot.js loops were fixed today. They are now around 4x faster than in React. React: http://jsfiddle.net/brianmfranklin/w674Lv7p/ http://jsfiddle.net/brianmfranklin/w674Lv7p/ Riot: http://jsfiddle.net/gianlucaguarini/cbjuek58/ http://jsfiddle.net/gianlucaguarini/cbjuek58/ just FYI
- hokkos 11y agoYour benchmark for React is not correct because when you do a second setState to show the duration it will be scheduled after requestAnimationFrame.
- andy_ppp 11y agoI 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.
- phillmv 11y agoWe need to stop this cargo cult stuff. "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 not too difficult to measure? 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.
- Cthulhu_ 11y ago> 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. This every time. If there's any bloggers among you: as soon as you start doing a 1:1 comparison between Angular and React, stop.
- mrisse 11y agoI (apparently incorrectly) thought they were similar enough to compare. What are the significant additional features that Ember and Angular provide?
- grumblestumble 11y agoNot sure about Ember, but Angular provides - a full MV* implementation - routing - DI - decorators - CSP / XSS protection - a ton of services for mocking for unit tests ($http, $window, et al) I'm sure I'm missing a fair amount of stuff here, too. This is just what I get out of Angular 1.x on a daily basis.
- c0achmcguirk 11y agoEmber provides everything Angular does plus: * More mature router (IMHO, the best router out of all JS frameworks) * A CLI for developers to generate their models, views, components, controllers, routes * An opinion on where things should live and how they should be structured (ups the learning curve but saves time in the seemingly endless developer debates when discussing architecture)
- egeozcan 11y agoVirtual 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. Edit: Down-voters care to comment?
- mrharrison 11y agoFrom 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.
- mmarklar 11y agoDrag and drop/scroll should work on the real DOM not the virtual DOM, no? I use Drag and Drop in a web app (using Om, which is a clojurescript library built on top of React) and it works just fine across all platforms.
- grayrest 11y agoThe 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. [1] http://engineering.flipboard.com/2015/02/mobile-web/ http://engineering.flipboard.com/2015/02/mobile-web/ 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. 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.
- naugtur 11y agoIs it really important? It exists to simplify app development, not to be fast. If you want fast, use similiar tools based on virtualdom module
- manishsharan 11y agoI 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 ?
- GijsjanB 11y agoEvents firing en listenTo'ing all over the place makes it really hard to reason about what will happen to your UI when state changes. The bigger the project (or the more complex the UI), the harder it is to keep track of all the events and their side effects.
- Zer8 11y agoSay you want a form with as-you-type validation. You can't have a view containing the whole form and just re-render that as someone types. If you did, you'd lose the user current focus on every render. This forces you to manipulate parts of the DOM "by hand", something React abstracts for you. I find Backbone events extremely hard to work with (error-prone, super hard to test / debug), because there are many operations that emit tons of events. So you either listen+render() on any event (very inconsistent performance if your app has any kind of complexity), or you hand-pick the events you want to react to (event-hell). Using immutable objects along with React's PureRenderMixin means you can just render() on any change, with great performance. It makes your UI purely functional, very easy to reason about, and easy to test.
- manishsharan 11y agoThanks. I get it now!
- Touche 11y ago> You can't have a view containing the whole form and just re-render that as someone types. If you did, you'd lose the user current focus on every render. This forces you to manipulate parts of the DOM "by hand", something React abstracts for you. This is not how most modern view engines work. Somehow the React community has convinced the entire JS world that they invented the idea of "only render what has changed" when that's just not the case.
- niix 11y agoThe 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.
- boroboro 11y agoHow is something 310% slower. My physics professor would have slapped me for such sloppiness in wording.
- deleted 11y ago[deleted]
- JDDunn9 11y agoI think many of the "advantages" of ReactJS are just hype - 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++. - 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. - ReactJS is so much faster - Only in unrealistic benchmarks as this illustrates (Mithril is faster in those benchmarks BTW) React also has a few major downsides: - JSX breaks your IDE's error checking and line numbers in error messages (and not using JSX is a pain/verbose) - 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.
- undefinedblog 11y agoI just smelt a load of prejudice here. Leave alone the technique detail(holding a debate which is better - Angular or React and here goes your rest of the day), IDE/error checking stuff isn't a problem anymore. Maybe you should try eslint, babel-eslint, babel-sublime or anything emerge since 21 century.
- megaman821 11y agoI don't tend to think ReactJS has many advantages, just differences. Angular 1.x is optimized around creating pages, where as React (and Angular 2.x) are optimized around creating small components. Angular 1.x uses two-way bindings by default and you can opt into one-way bindings. React essentially does the opposite. I have had infinite loops pop up in Angular, just by having floating point numbers that don't "settle" down to the same value. Also, it is too easy to end up with to many watchers on a page. Also, Angular is a much more complete solution than React but I have found react-router and the fetch api get me 80% there.
- grumblestumble 11y agoone-time bindings are not the same thing as one-way bindings.
- davnn 11y agoIMO 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. With Angular2 the discussion will be more interesting, but as far as I know Angular2 is not quite production ready.
- dmak 11y agoWhich is why we compare results, and not their philosophies and methodologies. It's like comparing CPUs from AMD and Intel, they have different architectures, but to understand real world performances, we compare results.
- mejari 11y agoExcept ReactJS and Angular are not the same class of thing. It's more like comparing an Intel CPU and an AMD motherboard.
- davnn 11y agoIMO 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. With Angular2 the discussion will be more interesting, but as far as I know Angular2 is not quite production ready.
- Kiro 11y agoSeems 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?
- filearts 11y agoThere are some situations where Angular 1.x's digest/compile cycle leads to degenerate performance and where clean solutions are all but unavailable. 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. 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. 1: http://embed.plnkr.co/1gOJjJ/ http://embed.plnkr.co/1gOJjJ/
- dmak 11y agoActually, I believe I am facing a similar issue. I have directives that encapsulate other directives, and compiling 1000 of them is slow, but they run pretty well after they are compiled. Any thoughts on speeding up that process?
- bitL 11y agoJust 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.
- ChrisGaudreau 11y agoIn the context of React, it allows you to implement a `shouldComponentUpdate` method which simply compares the references of two objects, which is extremely fast. If the references remain the same, then there is no need to invoke `render` again.
- RyanZAG 11y agoImmutability helps solve one of the hard problems in computer science: cache invalidation. Mutability can always be faster given perfect optimization, in the same way as self-modifying assembly code can always be faster. However, actually doing that optimization on a byte-by-byte level is basically impossible. Techniques such as immutability makes reasoning about how to optimize general cases much simpler. This often ends up with the trade off of higher ram usage and lower cpu usage, but a good enough general optimization can give lower ram usage too. Bad uses of immutability done for dogmatic reasons can often give you higher ram usage, higher cpu usage, and more complex code. As always, you do need to watch out for what you're using where and why.
- TickleSteve 11y agoNot saying you're wrong, but I've never heard this argument... How do you figure that immutability helps solve the cache invalidation problem? Immutability will cause cache issues, not help solve them. The answer to the question seems to be simply that immutability allows quick comparison due to references being the same so a deep comparison is not necessary, nothing to do with cache-invalidation
- dmak 11y agoWhat are more common arguments you heard of? I'm just curious.
- dgreensp 11y agoI 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). 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: > 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. 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. The original arguments for why React was fast were: * 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.) * 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. 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 necessarily or in general. Rather, they had concluded the two approaches were comparable in practice. 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.
- hokkos 11y agoOk 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.
- dmak 11y agoYou could still continue to use the track by syntax in the nested ng-repeats, but I would be careful. O(n^2) is always worrisome.
- wnevets 11y ago>People have sent me links to a number of other demos. All are simply missing 'track by'. really people? I knew most of the people spewing the angular hate didn't know what they were doing but this is kinda silly.
- drapper 11y agoWhen I was using Angular I thought doing something like setTimeout(function() { $scope.$digest(); }, 0); was an ugly hack and a sign of angular's leaky abstractionism showing up. Is this considered a good practice now (or always was)? Edit: just to clarify, I'm asking because in OP this was given as a one of the way to fix Angular speed issues.
- jsprogrammer 11y agoNo.
- timruffles 11y agoThat's a sign someone has fundamentally misunderstood Angular and is hacking around their misunderstanding.
- dmak 11y agoIt's the same thing as using $timeout; It runs a digest at the end after a setTimeout. I wouldn't call it a good practice, but it wouldn't bother me either if I saw it in a codebase. You are also welcome to use things like $evalAsync.
- lucisferre 11y agoIt's not the same thing, as the author points out since using `$timeout` in the example without an isolate scope was the source of the original problem. Instead he's suggesting you use $timeout without it's default behaviour (something that's possible now through the false argument or by calling setTimeout directly). This is absolutely a leaky abstraction, and whether or not it's necessary sometimes when using Angular, it should still bother you.
- ExpiredLink 11y ago>> Is ReactJS really fast enough? FTFY
- oimaz 11y agoDevelopers 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
- tracker1 11y agoThank you.. for me React/Flux and the like just felt better than Angular 1.x while being fast enough. The tooling and support for something like Polymer just doesn't fit as well. React with a flux-like flow is simply easier to reason with... When I've used Angular, I always hit points of frustration or weirdness that simply didn't make sense... the more advanced bits of React are less surprising in my mind. It's a shift in thinking about larger component based applications. It's also worth noting that Angular was started some time ago in 2009 and likely in development farther back than that... this is before CommonJS or AMD were widespread, and jQuery was a rising star. This is very much reflected in Angular 1.x. React is a different approach with a slightly more functional mindset (though I'm still not 100% sold on the structure). With a flux-like workflow, it's very easy to reason/structure your events and data.. yes events take some extra declaration, but your workflows become a lot easier.
- lhorie 11y agoPet peeve: Can we please stop blindly abusing `track by $index` without understanding it? 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: http://plnkr.co/edit/qKm7fYZFCkXHI5pkPMYL?p=preview http://plnkr.co/edit/qKm7fYZFCkXHI5pkPMYL?p=preview 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. 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. 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).
- grumblestumble 11y agoThis is absolutely a contrived example. $index is the equivalent to `var ctrl = angular.controller`, something that serves very well to communicate basic concepts but that you would never use in a real-world application. If you're dealing with server side data, your model should have a real unique key/id, and that is what you track by.
- sanderjd 11y agoThe amount of stuff in AngularJS that "serves very well to communicate basic concepts but that you would never use in a real-world application" is a huge problem with the framework. It's a perfect storm of a documentation site and blogosphere full of misleading and/or contradictory advice and examples, combined with conceptual and implementation complexity that makes it incredibly hard to just read the source and deduce best practices from first principles. This article contains a good example of the phenomenon: it suggests switching from `$timeout` to `setTimeout` with `$digest` to "give both frameworks the same information". Is that a silver bullet solution, or does it come with trade-offs, and if it does, what are they? I'm not sure, but my gut says that I shouldn't change this pattern in my code everywhere without doing a bunch of research to understand exactly what is going on. That's fine, researching how our tools work is a big part of the job, but I feel like Angular has a disproportionate amount of this sort of complexity compared with other tools I've used.
- axemclion 11y agoI tried to quantify the performance numbers - and react does show virtual DOM rendering improvements, but eventing is expensive. http://blog.nparashuram.com/2015/03/performance-comparison-on-javascript.html http://blog.nparashuram.com/2015/03/performance-comparison-o...
- bunkerbewohner 11y agoPersonally I never heard of the alleged speed advantages. I'm only using React for its architecture, i.e. functionally "pure" UIs.
- PuercoPop 11y agoDo you use ReactJS because it is fast?
- deleted 11y ago[deleted]
- EGreg 11y agoNo 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. 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. 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. Personally, I will prefer http://platform.qbix.com http://platform.qbix.com ;-)
- justin_d 11y agomy experience with react is that it's really fast.
- jwr 11y agoFrom 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. 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). 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.
- sebringj 11y agoSpeed is just one concern but there is a huge ecosystem and native aspects that is more than just one dimension.
- d0m 11y agoWe 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). 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.
- jbhatab 11y agoThe 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, http://www.producthunt.com/posts/jsblocks http://www.producthunt.com/posts/jsblocks, 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. original test (with hidden td elements) js blocks: 800ms react: 1250ms After removing hidden element jsblocks: 350-400ms react: 200-350ms 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, https://github.com/facebook/react/issues/3771 https://github.com/facebook/react/issues/3771 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. revised test (original test of 5000 elements to 18000 elements) jsblocks: 600ms (they posted 700ms, so ill give them that) react: 700ms (they posted 950ms) After removing half of the data to about 9000 elements react already started to tie jsblocks jsblocks: 450ms react: 450ms Going down to about 5000 elements jsblocks: 250ms react: 200ms 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. 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. 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!!). So there's my rant. Please stop promoting your library like you are, it's just distasteful. edit: https://drive.google.com/folderview?id=0BxTyg4RuMOHUfjlvTkN3dzRaSU4wckh0b3lST3lrb3lzekdWVWhVSlJfWlRsLWszR0RuYjQ&usp=sharing https://drive.google.com/folderview?id=0BxTyg4RuMOHUfjlvTkN3... 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!
- natmaster 11y agoAngularJS 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. (note: I've done professional angularjs and reactjs projects)
- _pb 11y agoSetting 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. 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). 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". ...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.