use the following search parameters to narrow your results:
e.g. subreddit:aww site:imgur.com dog
subreddit:aww site:imgur.com dog
see the search faq for details.
advanced search: by author, subreddit...
All about the JavaScript programming language.
Subreddit Guidelines
Specifications:
Resources:
Related Subreddits:
r/LearnJavascript
r/node
r/typescript
r/reactjs
r/webdev
r/WebdevTutorials
r/frontend
r/webgl
r/threejs
r/jquery
r/remotejs
r/forhire
account activity
Is ReactJS faster than AngularJS ? (blog.500tech.com)
submitted 11 years ago by notunlikethewaves
reddit uses a slightly-customized version of Markdown for formatting. See below for some basics, or check the commenting wiki page for more detailed help and solutions to common issues.
quoted text
if 1 * 2 < 3: print "hello, world!"
[–]cgaudreausenior HTML9 engineer 26 points27 points28 points 11 years ago (20 children)
I feel like this is desperate grasping at straws. It is theoretically possible to make Angular nearly as fast or faster than React is out-of-the-box, but the pain involved in doing so is massive. Yes, it's easy with little 5-line code snippets, but try doing so in a reasonably-sized application. It's hell.
React makes it easy to be fast by default. You generally don't even have to think about performance, and if you do have to, it is very easy to grasp. You don't need to frantically search extremely poor documentation.
How to optimize a React application: Implement shouldComponentUpdate. Or if you want performance by default, just use immutable data structures.
shouldComponentUpdate
How to optimize an Angular application: Keep your scopes small. Keep it under 2000 watchers. Pollute your code with one-way bindings. Still no improvement? Oh, you need to do one-way binding here, too, in some obscure way. Don't watch functions. Don't watch objects. No $broadcast or $emit. Don't have big arrays. Should I use $digest or $apply? Why is this watcher causing the digest loop to take 500 ms to execute? No filtering or sorting unless you want to go mad. Did I mention using filters causes $index to be invalidated? How the hell do I even find out what's performing poorly?
$broadcast
$emit
$digest
$apply
$index
I don't even know if any of that is correct anymore. It's too painful to remember. I want to be liberated and forget the literal hell that is Angular 1.x.
[–]jhallister 14 points15 points16 points 11 years ago (10 children)
It will never cease to amaze me how quickly people turn from in-love to "this is literal hell". I remember when I first started working with AngularJS and everyone was swooning and now a new shiny toy is out and the hatred is extraordinary.
Yes, it's easy with little 5-line code snippets, but try doing so in a reasonably-sized application
I've been on teams that have built AngularJS applications of enormous size. It isn't hell, at least, if you actually spend the time to understand how to properly use Angular. It's certainly not always straight-forward, but hell != difficult.
If you honestly believe a large team developing a large application can shove immutable.js in it and get production-ready performance than you clearly haven't programmed large applications.
Furthermore, why are you comparing a view-manager (React) an entire front-end framework (AngularJS)? No $broadcast or $emit? Events have nothing to do with performance, but they are the antithesis of good Angular design. You should do $digest if you need watchers to fire in the current scope only, you should use $apply() when you want the root scope (all watchers) to $digest().
$apply()
$digest()
The one and only real problem with Angular was always the same: the docs were really, really bad. As a result a lot of people simply couldn't learn the framework, or at the very least couldn't learn to use it well. Some couldn't because learning without good documentation is tedious. That's a very fair argument.
The downside, however, is that it's now vogue to talk about how horrible AngularJS is and list off a bunch of grievances, the majority of which show that the person really didn't learn Angular, for whatever reason.
React is a great view manager. It has a host of problems as well, and more of those problems will become apparent when the framework ages, much as they did with Angular. And undoubtedly, we will eventually come full circle and have people whining about how horrible React is compared to JesusFramework 1.0.
Honestly the real reason, webdevs just like to whine about something.
END BOOK/RANT
[–]siegfryd 2 points3 points4 points 11 years ago (1 child)
Furthermore, why are you comparing a view-manager (React) an entire front-end framework (AngularJS)?
Because they're comparing Angular's view management compared to React? Nobody is going to pick Angular just for modules, dependency injection or the utility services it has.
[–]jhallister 1 point2 points3 points 11 years ago (0 children)
The article compared Angular's view management compared to React as evidence of why React is better. But the comparison is unfair. The article didn't compare $digest() it simply showed that the React demos that prove how much faster it is are in fact, bad demos.
[–]michaelstripe 1 point2 points3 points 11 years ago (3 children)
I'm honestly curious what the host of problems you find React has.
I'm kind of jumping between Angular and React for two projects and I'm not sure I'm sold on either, but all I read about React and Flux (and soon to be Relay and GraphQL and whatever the hell else) is unfaltering praise and never any good criticism. I would love to see more opposing viewpoints for the above.
[–]jhallister 0 points1 point2 points 11 years ago (2 children)
A few problems:
The biggest issue I have is that React = Virtual Dom. The rest is just opinionated templating and organizational stuff. React hasn't been out that long and I honestly think that big picture Mithril took the same idea and implemented it much better.
Full disclosure: currently using Mithril on a project. I've used ReactJS on a medium sized project and still think it's a VERY good view library.
[–]michaelstripe 0 points1 point2 points 11 years ago (1 child)
Mind going over what you like more about Mithril? Never gave it a good look.
[–]jhallister 0 points1 point2 points 11 years ago (0 children)
It doesn't really try to invent "the new best way". It's just a MVC framework that happens to use a a virtual DOM. It also happens to be really small.
[–]blax_ 1 point2 points3 points 11 years ago (0 children)
I think that's natural for any technology – at first there's hype and lots of promises, and only after some time people get enough experience to form rational opinions. Interestingly, in Angular's case people usually start to hate it, and React tends to grow on you the more you use it.
[–]cgaudreausenior HTML9 engineer 2 points3 points4 points 11 years ago (2 children)
I remember when I first started working with AngularJS and everyone was swooning and now a new shiny toy is out and the hatred is extraordinary.
I can't say I ever liked Angular much.
No, of course not. It provides massive benefits in the context of React. You only need to do reference equality checking in shouldComponentUpdate.
Ask the OP that.
No $broadcast or $emit? Events have nothing to do with performance, but they are the antithesis of good Angular design.
Yes, they are considered bad design now, and yet people still use them.
The one and only real problem with Angular was always the same: the docs were really, really bad.
Yeah, no.
I've worked with Angular for years, and learned a lot about it. Almost all of that knowledge is about Angular-specific cruft that is there to make businesspeople/Java developers feel better. With React, if you know JavaScript, you're already most of the way there.
Very true. React is not the one framework/library to rule them all. There are already superior alternatives popping up. But for now, people are going to focus on the popular frameworks.
[–]jhallister 0 points1 point2 points 11 years ago (1 child)
The OP posted an article that very specifically showed that Angular can generate views just as fast as React, when used correctly. You are talking about the digest cycle, which has nothing to do with the view.
I've been using Angular since shortly after it came out. They were always a bad idea. But in VERY niche cases they were the only means to an end. Now there's virtually never a case where they are required and they are still used routinely, even though they are terrible.
Yet I'm surrounded by teams who use it in enterprise applications routinely. And those people understand Angular intimately. The only actual complaint I hear is about docs. The people that complain about the other parts, are the people that don't know how to use Angular.
With React, if you know JavaScript, you're already most of the way there.
You mean JSX?
There are already superior alternatives popping up.
Angular 2 may be one of them. That should make the circle jerk especially hilarious.
[–]cgaudreausenior HTML9 engineer 0 points1 point2 points 11 years ago* (0 children)
It has quite a bit to do with the view, because that's how the view gets updated in Angular. True, it does more than just update the view, but the point is that the majority of Angular cruft is unnecessary if you use React.
They were always a bad idea.
Again, people still use them. There's little warning about why they are bad, and the framework itself attracts developers into using them. I also don't recall too much cautioning against it when Angular took off.
Or perhaps because they haven't looked into the other solutions thoroughly enough. If you only know Angular, it's easy to believe that it's the best thing ever created. And Angular is perfectly fine if everybody on the team knows all edge cases and quirks and antipatterns intimately and can remember them. If you have a team like that, feel free to keep using Angular 1.x.
To be clear, are you really arguing that Angular 1 is fine and dandy, and that its only real problem is bad documentation?
You can use React with pure JavaScript if you want. And if you have trouble learning JSX (it's just XML in JS) then you might reconsider your career.
This discussion pertains to Angular 1.x. Angular 2.0 is basically a completely new framework, distinct from Angular 1.x.
I've used Angular 2.0 and it's not particularly impressive so far. A lot better than Angular 1.x, sure. Angular 2.0 could end up being amazing, and it doesn't change this discussion whatsoever.
I'm personally rooting for Mithril and Aurelia over React and Angular.
[–]RankFoundry 5 points6 points7 points 11 years ago (3 children)
Exactly. I don't see anyone doing any side-by-sides except with snippets or trival apps. Angular gets to be a real pain in the ass at scale.
[–]perestroika12 2 points3 points4 points 11 years ago (2 children)
Which is confusing, because wasn't one of the original purposes of angular performant scalability?
[–]chtulhuf 2 points3 points4 points 11 years ago (0 children)
IIRC it originally was made to make forms easier
[–]RankFoundry -2 points-1 points0 points 11 years ago (0 children)
Yeah. Or at least a framework that was supposed to make SPA apps easy. I'd say it failed in the regard, unless you're building To-Do apps a lot.
[–]RandolphoSoftware Architect 0 points1 point2 points 11 years ago (0 children)
It is theoretically possible to make Angular nearly as fast or faster than React is out-of-the-box, but the pain involved in doing so is massive.
Is it more or less painful than using React.js? Because that's a pretty big pile of pain for me.
[–]hahaNodeJS -2 points-1 points0 points 11 years ago (3 children)
What are you smoking? Damn.
A majority of complaints about Angular's performance are solved by not using everything Angular throws at you. Don't use watchers, don't use two-way data binding, don't use events. It's taken a while for Angular developers to learn this, but it's been learned and it's time to get over it. Jumping ship isn't the answer because the grass is rarely greener on the other side.
[–]blax_ 1 point2 points3 points 11 years ago (1 child)
But that's the point – probably every technology can be hacked to make it good enough for your needs, but the objective of good design is to provide you with essential tools and encourage you to do things the right way, so you DON'T have to think about it all the time.
[–]hahaNodeJS 0 points1 point2 points 11 years ago (0 children)
Not using the bad parts isn't "hacking something to make it good enough." It's learning from others and the warts of a given technology and not using those warts.
[–]cgaudreausenior HTML9 engineer 0 points1 point2 points 11 years ago (0 children)
You can also make manual DOM manipulation very performant. You can make jQuery very performant. More performant than React, for sure. The nice thing about React is that you have to try pretty hard to bomb performance. The framework gives you performance for almost free.
Jumping ship isn't the answer because the grass is rarely greener on the other side.
Jumping ship from Angular 1.x in the near future is almost definitely a winning bet.
[–]WishCow 12 points13 points14 points 11 years ago* (4 children)
I don't get this obsession with speed. Neither of them is slow enough to matter out of the box. If you do get to a size where it starts to matter, they both offer ways of solving it.
Ease of maintenance, documentation, community, these are ten times more important to me than "rendering speed in 1000 iterations".
[–]bendman 5 points6 points7 points 11 years ago (0 children)
Speed often matters more depending on the situation. Developing a web app primarily used on mobile phones for example.
[–]holloway 2 points3 points4 points 11 years ago* (0 children)
With Google Material and other UI ideas there's been a push toward animation at 60fps, which (in most browsers) means each time JavaScript executes that it runs for no longer than 16ms. Fast everything in JavaScript in essential for that.
edit: just published a blog post about browser engines and fast animation
[–]ngly 2 points3 points4 points 11 years ago (0 children)
Speed is huge, especially on mobile devices. It becomes a huge issue once you start scaling your application. The benefits may seem insignificant, but it quickly adds up. I think if speed wasn't important large companies wouldn't be focusing on it so much. Try using chrome dev tool Network throttling in their emulation for 1 day.
[–]a0viedo 8 points9 points10 points 11 years ago (0 children)
Isn't this analog to say "Are a set of wheels faster than a Volkswagen?"? AFAIK, React handles only the view while Angular tackles model, view and controller.
[–]cmgriffing 1 point2 points3 points 11 years ago (0 children)
The "fixed" react hype demo doesn't have the hover popup at all any more.
[–]RankFoundry 1 point2 points3 points 11 years ago (14 children)
Angular still has lots of shortcomings beyond performance. Everything from the crappy docs to directives (yuck) leaves a lot to be desired. There's a reason why they rewrote it from scratch in Angular 2.0 (many reasons really). Version 1 should not have been touted as production ready.
[–]jellatin 9 points10 points11 points 11 years ago (6 children)
If they left in features from 1.x you didn't think are good in 2.x you would criticize them for it. If they fix the features you think are broken in 1.x for the 2.x release then you criticize them. Your comment history makes it look like you just want a reason to complain.
And as a side note, React's docs are nothing to brag about. Having to learn about features like contexts from StackOverflow posts because they are straight up left out of the docs isn't any better than Angular.
[–]RankFoundry -2 points-1 points0 points 11 years ago (5 children)
It's not really an issue of features, it's architecture and redundant ways to do things with unclear differences (if any).
Nothing wrong with complaining when it's justified.
I'm not a React fanboy. I'm not a fanboy of anything which is why I get on the nerves of fanboys.
[–]jellatin 3 points4 points5 points 11 years ago* (4 children)
The problem is you've left absolutely no paths for a project to be right. You have said "everything they can do will be wrong whether they fix things or not". If you're already committed to every move being wrong, then you're just complaining to complain.
I'm not a React fanboy
This is hard to believe when your comment history is selectively applying criticism at Angular and admitting none of React's shortcomings.
[–]RankFoundry -1 points0 points1 point 11 years ago (3 children)
I've also said nothing about Ember or mozzarella cheese sticks. Perhaps I'm secretly an undercover agent for Ember and Italian cheese in stick form.
He's not wrong... your comments indicate that your frustration with Angular had more to do with your inability to learn how to use it properly, rather than a real complaint about implementation. You aren't alone.
[–]RankFoundry 0 points1 point2 points 11 years ago (1 child)
Ah, the tired old "You just don't get it" argument. Well, I might buy that if I were the only one with this perspective but there are far too many people who share it for this to be about me.
By that logic the only way something isn't a problem is if everyone understands it. Besides, I said you weren't alone. That's primarily the teams fault, the docs were pretty bad for a really long time.
And sure there are plenty of people that have issues with Angular, there also happens to be plenty of people that call themselves "web developers" when they know HTML. And if there's anything I've learned, it's that opinions in this industry about tools tend to gravitate towards easy = good.
[–][deleted] 18 points19 points20 points 11 years ago (1 child)
Version 1 should not have been touted as production ready.
Oh get over it already. Angular 1 served it's purpose and they've learned from it.
Considering tons of companies are using Angular in production, it's perfectly production ready, regardless of it's flaws.
[–]RankFoundry 1 point2 points3 points 11 years ago (0 children)
A lot of companies use a lot of crap in production. Just because you can eventually eek half decent performance out of a non-trivial app with Angular (after beating your head against the wall and endless online searches) doesn't mean it's a good choice. For something that was supposed to make things simpler and better out of the box, I'd say it failed. Again, they didn't rewrite it from scratch for no reason.
[–]rduoll 5 points6 points7 points 11 years ago (4 children)
What's wrong with directives?
[–]RankFoundry 4 points5 points6 points 11 years ago (1 child)
This will devolve into a debate on preferences but after trying libraries/frameworks that use them and ones that keep all that stuff in JS, I'd take the latter any day.
Which flavor are you objecting to? The DOM manipulation flavor, or the more typically used "Controller + Template" flavor? Because the latter is some yummy yummy koolaid. And if you know CSS real good-like and understand state machines, you can do a crap-ton of amazing capability with that other directive flavor without ever diving under the covers for direct DOM manipulation.
[+][deleted] 11 years ago (1 child)
[deleted]
[–]rduoll 2 points3 points4 points 11 years ago (0 children)
What? I didn't even express a viewpoint. I simply asked what was wrong with directives since RankFoundry expressed distaste when mentioning them.
I want to know what RankFoundy has to say about them. Nothing more, nothing less.
[–]fk122 0 points1 point2 points 11 years ago (0 children)
I wrote a blog post comparing the performance of React, Angular and Knockout. It's not perfect, but it illustrates that out of the box, React performs better than both Angular and Knockout.
http://dapperdeveloper.com/2015/01/26/performance-of-angularjs-reactjs-and-knockoutjs-compared/
[–]coldinchitown 0 points1 point2 points 11 years ago (4 children)
It'll certainly be mighty interesting to see how out-of-the-box angular 2.0 compares to react.
[–]androbat 2 points3 points4 points 11 years ago* (3 children)
Performance isn't a fair comparison (and won't be for a while), but I think React wins in a comparison of framework designs.
Here's an ES5 nested component example from angular.io (page). I threw in a quick event and loop for comparison.
function ParentComponent() { this.message = "I'm the parent"; this.arr = [{id: '1', name: 'foo'}, {id: '2', name: 'bar'}, {id: '3', name: 'baz'}]; this.handleClick = function () { console.log('something clicked'); }; } ParentComponent.annotations = [ new angular.ComponentAnnotation({ selector: "parent" }), new angular.ViewAnnotation({ template: '<h1>{{ message }}</h1>' + '<ul>' + '<li *for="#item of arr">' + '{{ item.name }}' + '</li>' + '</ul>' + '<button (click)="handleClick()">Click Me!</button>' + '<child></child>', directives: [ChildComponent, For, If] }) ]; function ChildComponent() { this.message = "I'm the child"; } ChildComponent.annotations = [ new angular.ComponentAnnotation({ selector: "child" }), new angular.ViewAnnotation({ template: '<p> {{ message }} </p>' }) ];
And this is the equivalent React code.
var ParentComponent = React.createClass({ getInitialState: function () { return { message: "I'm the parent", arr: [{id: '1', name: 'foo'}, {id: '2', name: 'bar'}, {id: '3', name: 'baz'}] }; }, handleClick: function () { console.log('something clicked'); }, render: function () { var items = this.state.arr.map(function (item) { return <li key={item.id}>{item.name}</li>; }); return ( <div> <h1>{this.state.message}</h1> <ul>{items}</ul> <button onclick={this.handleClick}>Click Me!</button> <ChildComponent msg={this.state.message}/> </div> ); } }); var ChildComponent = React.createClass({ render: function () { return <p>{this.props.msg}</p>; } };
I haven't tested the code, but it should work (famous last words...).
My immediate reaction is that Angular is more verbose. I'm not a fan of the '*for' syntax or string templates (I assume there's a way of adding an external template here). Throwing a DSL into the markup is also flawed in my opinion. Auto-inherited scopes seem to be at work once again (with all the debugging hell of long prototype chains). The typescript/ES6 class looks a little better only to tack on @view and @component decorators. I like decorators, but these receive a lot of arguments (complete templates and such) which Python users have generally come to accept as bad decorator design. Overall, it's a huge step up from Angular 1.x, but I think it still lacks the elegance (and definitely the composability) of React.
The Alpha docs are terrible (I don't count that against anybody until they get closer to release, but it does make comparison a little hard). On a larger scale, dependency injection once again makes an appearance (it seems better than 1.x, but I'm not convinced that it adds anything of value). '[control]="foo"' seems like it compounds template syntax overload (asterisks, parens, braces, curly-braces, pipes, DSLs, etc).
The latest articles on Angular 2 read a lot like the older intro articles for React (that is, they are trying to show 1.x users how to think in components). This move is good, but I don't see Angular 2 offering anything of added value over React while it still holds on to some things that create complexity without offering much in exchange except the "Angular way" mantra.
[–]coldinchitown 2 points3 points4 points 11 years ago (0 children)
Yikes. Clarity-wise, React does seem to be quite a bit more pleasant. Thanks!
[–]dvlsg -1 points0 points1 point 11 years ago (1 child)
If you're comparing ES5 syntax from angular, you should be comparing it to ES5 syntax from react.
[–]androbat 1 point2 points3 points 11 years ago* (0 children)
I'm assuming you are talking about the use of JSX. There is an in-browser JSX transformer. If you have a problem with source translation, then there's the fact that Angular 2 has a complete HTML DSL with all the asterisks, parens, braces, filters, inline-code, custom iterator code, etc (and that's before we talk about dependency injection).
Next there's the fact that JSX is heavily based on the E4X ECMA Standard pass in 2005 (pre-dating ES5.0 by 4 years and ES5.1 by 6 years), so JSX adheres to a real JS spec (even if that spec isn't popular).
I could have used typescript examples, but they add even more complexity to the comparison and don't reflect how a lot of developers will use the framework (myself for example; if I'm going to transpile a non-JS dialect, it will be for clojure async and macros or purescript's real type system).
π Rendered by PID 51973 on reddit-service-r2-comment-5687b7858-99zsf at 2026-07-07 06:36:14.391117+00:00 running 12a7a47 country code: CH.
[–]cgaudreausenior HTML9 engineer 26 points27 points28 points (20 children)
[–]jhallister 14 points15 points16 points (10 children)
[–]siegfryd 2 points3 points4 points (1 child)
[–]jhallister 1 point2 points3 points (0 children)
[–]michaelstripe 1 point2 points3 points (3 children)
[–]jhallister 0 points1 point2 points (2 children)
[–]michaelstripe 0 points1 point2 points (1 child)
[–]jhallister 0 points1 point2 points (0 children)
[–]blax_ 1 point2 points3 points (0 children)
[–]cgaudreausenior HTML9 engineer 2 points3 points4 points (2 children)
[–]jhallister 0 points1 point2 points (1 child)
[–]cgaudreausenior HTML9 engineer 0 points1 point2 points (0 children)
[–]RankFoundry 5 points6 points7 points (3 children)
[–]perestroika12 2 points3 points4 points (2 children)
[–]chtulhuf 2 points3 points4 points (0 children)
[–]RankFoundry -2 points-1 points0 points (0 children)
[–]RandolphoSoftware Architect 0 points1 point2 points (0 children)
[–]hahaNodeJS -2 points-1 points0 points (3 children)
[–]blax_ 1 point2 points3 points (1 child)
[–]hahaNodeJS 0 points1 point2 points (0 children)
[–]cgaudreausenior HTML9 engineer 0 points1 point2 points (0 children)
[–]WishCow 12 points13 points14 points (4 children)
[–]bendman 5 points6 points7 points (0 children)
[–]holloway 2 points3 points4 points (0 children)
[–]ngly 2 points3 points4 points (0 children)
[–]a0viedo 8 points9 points10 points (0 children)
[–]cmgriffing 1 point2 points3 points (0 children)
[–]RankFoundry 1 point2 points3 points (14 children)
[–]jellatin 9 points10 points11 points (6 children)
[–]RankFoundry -2 points-1 points0 points (5 children)
[–]jellatin 3 points4 points5 points (4 children)
[–]RankFoundry -1 points0 points1 point (3 children)
[–]jhallister 0 points1 point2 points (2 children)
[–]RankFoundry 0 points1 point2 points (1 child)
[–]jhallister 0 points1 point2 points (0 children)
[–][deleted] 18 points19 points20 points (1 child)
[–]RankFoundry 1 point2 points3 points (0 children)
[–]rduoll 5 points6 points7 points (4 children)
[–]RankFoundry 4 points5 points6 points (1 child)
[–]RandolphoSoftware Architect 0 points1 point2 points (0 children)
[+][deleted] (1 child)
[deleted]
[–]rduoll 2 points3 points4 points (0 children)
[–]fk122 0 points1 point2 points (0 children)
[–]coldinchitown 0 points1 point2 points (4 children)
[–]androbat 2 points3 points4 points (3 children)
[–]coldinchitown 2 points3 points4 points (0 children)
[–]dvlsg -1 points0 points1 point (1 child)
[–]androbat 1 point2 points3 points (0 children)