Angular vs. React – the tie breaker(airpair.com)
airpair.com
Angular vs. React – the tie breaker
https://www.airpair.com/angularjs/posts/angular-vs-react-the-tie-breaker
80 comments
> The author thinks that React is amazing at everything, but detests JSX. Conversely, he hates Angular but loves Angular's directives.
The hilarious part about this statement is that React is the equivalent of the Directive component in Angular...so if you like Angular Directives, there's basically no reason to use React. I'm seriously wondering why this post got so many upvotes.
The hilarious part about this statement is that React is the equivalent of the Directive component in Angular...so if you like Angular Directives, there's basically no reason to use React. I'm seriously wondering why this post got so many upvotes.
It has the words React AND Angular in the title. Instant upvote for folks I suppose.
I'm stuck on an older version of angular, but have directives become more composable in the last couple of versions? I had real problems composing them as element directives, which is the only way i'd be able to swallow the equivalence argument.
Yes they have, everything is gearing towards component-based architecture in the more recent versions of Angular, and 2.0 is going to be all about components. This is a good read - http://teropa.info/blog/2014/10/24/how-ive-improved-my-angul...
Which is funny because Google is also sponsoring Web Components (via Polymer), so I wouldn't be surprised if Angular is one grand experiment to see if the world will adopt data-bound web components as the next step in the evolution of the web.
Sorry can you elaborate? How have they become more composable? I don't recall a point at least post 1.X where they were more or less useful for composition than they are now.
Sure, there are a lot of subtle things which have been improved in later Angular versions.
First of all, you don't need $scope anymore in controllers, you can still use it for functions like $watch, but you don't need to inject it in just to add properties to your controller, you can just use `this.foo = 'bar';`
You also have the controllerAs syntax which I don't think is present in earlier Angular versions, which provides a shorthand for your controller, and bindToController for directives, which allows you to bind attribute values directly to the directives controller without extra syntax.
If I remember other things I will update this comment.
First of all, you don't need $scope anymore in controllers, you can still use it for functions like $watch, but you don't need to inject it in just to add properties to your controller, you can just use `this.foo = 'bar';`
You also have the controllerAs syntax which I don't think is present in earlier Angular versions, which provides a shorthand for your controller, and bindToController for directives, which allows you to bind attribute values directly to the directives controller without extra syntax.
If I remember other things I will update this comment.
> Sadly, the actual writing and argumentation is poor
Hard for me to tell, since you seem to have devoted your entire comment to insulting the author without actually elaborating on why he's wrong.
From my POV, this looks like a better way of letting HTML people focus on HTML while I focus on the JS - which is something that's been valuable in angular for me.
Any chance you could explain why you believe that's wrong rather than just trying to invent teabagging over IP?
Hard for me to tell, since you seem to have devoted your entire comment to insulting the author without actually elaborating on why he's wrong.
From my POV, this looks like a better way of letting HTML people focus on HTML while I focus on the JS - which is something that's been valuable in angular for me.
Any chance you could explain why you believe that's wrong rather than just trying to invent teabagging over IP?
You have HTML people? This raises a question I've had for a while about the "full stack" term. I come from the asp.net world, where I have never dealt with the concept of "full stack", simply because there has never been an alternative. From day one in the 90s I've been expected to do everything from html to sql. Is "full stack" primarily a non-Microsoft matter? If not, what proportion of Ms devs have HTML people, js people, etc. vs "full stack"?
Well ... I usually bang out HTML3-like markup that matches the initial wireframes, then hand it to somebody who's good at CSS to make it look decent. I also do a fair chunk of refactoring JS stuff that was thrown together to test a UI idea into something that's actually maintainable.
Plus on the rare occasions I try and do something involving prettiness, being able to ignore the JS and focus on HTML+CSS is nice for me, too.
Plus on the rare occasions I try and do something involving prettiness, being able to ignore the JS and focus on HTML+CSS is nice for me, too.
> Hard for me to tell, since you seem to have devoted your entire comment to insulting the author without actually elaborating on why he's wrong.
Most of the article doesn't make any concrete arguments, so there's nothing to dispute. Most of the article boils down to "React is magical and better at Angular at everything", which...I dunno, where do you even start? The point about learning curves is just a bald "you can be an expert at React in a week; you have to read the Angular source to even use it!", which is just blatantly and obviously wrong. Or the abstraction point; apparently Angular is bad because you need to know about its internals to make anything work, but React is good because you just need to know about its internals to make everything work.
There's nothing really to engage with there. If you think React is super easy to master, and Angular is super hard, then you'll nod in agreement. If you don't think that—and I don't, for all that I love React and dislike Angular—there's nothing to dispute. No studies, no anecdotes, no surveys.
> this looks like a better way of letting HTML people focus on HTML while I focus on the JS
My experience has been that any designer technical enough to write HTML using Angular directives is technical enough to write JSX; the complexity difference is minimal.
But your mileage will vary; perhaps you—or the designers you work with—are fine with Angular directives but not JSX. Adoptions of tools like React-templates suggests this is not widespread, however. :)
Most of the article doesn't make any concrete arguments, so there's nothing to dispute. Most of the article boils down to "React is magical and better at Angular at everything", which...I dunno, where do you even start? The point about learning curves is just a bald "you can be an expert at React in a week; you have to read the Angular source to even use it!", which is just blatantly and obviously wrong. Or the abstraction point; apparently Angular is bad because you need to know about its internals to make anything work, but React is good because you just need to know about its internals to make everything work.
There's nothing really to engage with there. If you think React is super easy to master, and Angular is super hard, then you'll nod in agreement. If you don't think that—and I don't, for all that I love React and dislike Angular—there's nothing to dispute. No studies, no anecdotes, no surveys.
> this looks like a better way of letting HTML people focus on HTML while I focus on the JS
My experience has been that any designer technical enough to write HTML using Angular directives is technical enough to write JSX; the complexity difference is minimal.
But your mileage will vary; perhaps you—or the designers you work with—are fine with Angular directives but not JSX. Adoptions of tools like React-templates suggests this is not widespread, however. :)
I read the entire source of angular and enjoyed doing so. If I work with a react-based stack I'll probably do the same and enjoy that too.
But: My attempts to figure out a complete react stack resulted in me discovering that the react tutorial example is awful, then realising that's because the way I think demands a fluxish thing, then finding redux made sense but assumed I already knew flux, then discovering the billion other fluxish things and developing a headache.
So I clearly don't know what I'm talking about with react yet. If you have any suggestions for how to resolve the above headache I still want to try - hence my request for details, I wanted to understand why you liked React.
But: My attempts to figure out a complete react stack resulted in me discovering that the react tutorial example is awful, then realising that's because the way I think demands a fluxish thing, then finding redux made sense but assumed I already knew flux, then discovering the billion other fluxish things and developing a headache.
So I clearly don't know what I'm talking about with react yet. If you have any suggestions for how to resolve the above headache I still want to try - hence my request for details, I wanted to understand why you liked React.
Well...
React is just a view layer; it's a way of turning data into DOM nodes. It works fine, and it's a pretty good way of doing so, although it's fairly weak for, say, making a bunch of basic CRUD forms, but very good for making little widgets. Bonus: It's very very composable. And you can make cool things—even those CRUD forms that otherwise seem daunting—by composing components and wrapping it up into a simple <Widget data={data} conf={conf}/> tag.
Strengths of React: declarative, kind of functional-ish, works well with immutable data. If you do it right, your React code is basically just a bunch of pure functions which accept data and turn it into DOM nodes; that makes it easy to reason about, easy to test, east to compose. If you ever look at your app and it looks wrong, troubleshooting it is easy. Put a console.log statement at the top of your render function to print out your props. If it's not run, your render function isn't being called. If it's run with the wrong arguments, a parent is passing in the wrong props. If it's being run with the right props but still looks wrong, you have an error in your render code, fix that.
Even a very, very complex React app boils down to the same reductive approach; start at the top of the tree and follow the data down until you hit the error. Debugging a complex Backbone app, in contrast, can be much more exciting in my experience.
But again, just a view layer. Comparing it to Angular is a bit like comparing Angular to Handlebars. :) You need a lot more to write a real app. Now you can try and hook it up to a Backbone router and Backbone models, but eww, don't do that. Or you can go the Om/Omniscient route with cursors and such. Or, yes, flux.
Flux is a really good pattern too. Redux is probably my choice for top two favourite flux implementations right now, but it's changing fast, still pretty beta, very poorly documented, and definitely aimed at people who already know flux.
I'd actually recommend you look at Marty or Alt. I think Alt might be slightly the better library, but Marty probably has the edge on documentation. Both are very similar and, as a bonus, are in the process of merging. Either would probably be a better choice than Redux if you're new to Flux in general. (I'm using Marty in a project at the moment, and found the documentation pretty helpful.)
I'd also recommend this blog post: http://www.toptal.com/react/navigating-the-react-ecosystem
The Reactiflux community on Slack is also really helpful.
React is just a view layer; it's a way of turning data into DOM nodes. It works fine, and it's a pretty good way of doing so, although it's fairly weak for, say, making a bunch of basic CRUD forms, but very good for making little widgets. Bonus: It's very very composable. And you can make cool things—even those CRUD forms that otherwise seem daunting—by composing components and wrapping it up into a simple <Widget data={data} conf={conf}/> tag.
Strengths of React: declarative, kind of functional-ish, works well with immutable data. If you do it right, your React code is basically just a bunch of pure functions which accept data and turn it into DOM nodes; that makes it easy to reason about, easy to test, east to compose. If you ever look at your app and it looks wrong, troubleshooting it is easy. Put a console.log statement at the top of your render function to print out your props. If it's not run, your render function isn't being called. If it's run with the wrong arguments, a parent is passing in the wrong props. If it's being run with the right props but still looks wrong, you have an error in your render code, fix that.
Even a very, very complex React app boils down to the same reductive approach; start at the top of the tree and follow the data down until you hit the error. Debugging a complex Backbone app, in contrast, can be much more exciting in my experience.
But again, just a view layer. Comparing it to Angular is a bit like comparing Angular to Handlebars. :) You need a lot more to write a real app. Now you can try and hook it up to a Backbone router and Backbone models, but eww, don't do that. Or you can go the Om/Omniscient route with cursors and such. Or, yes, flux.
Flux is a really good pattern too. Redux is probably my choice for top two favourite flux implementations right now, but it's changing fast, still pretty beta, very poorly documented, and definitely aimed at people who already know flux.
I'd actually recommend you look at Marty or Alt. I think Alt might be slightly the better library, but Marty probably has the edge on documentation. Both are very similar and, as a bonus, are in the process of merging. Either would probably be a better choice than Redux if you're new to Flux in general. (I'm using Marty in a project at the moment, and found the documentation pretty helpful.)
I'd also recommend this blog post: http://www.toptal.com/react/navigating-the-react-ecosystem
The Reactiflux community on Slack is also really helpful.
Redux makes a lot of sense to me actually; I'll dig into it again when they've finished the great 1.0 renaming.
Thanks for the reply, much appreciated.
Thanks for the reply, much appreciated.
This comment really lowers the level of conversation compared to the article. Shame on you.
I would disagree. I don't think the "level of conversion" presented in the article is anything to praise. There are very few real arguments presented that are worth discussion.
Here we go again. This article is so obviously biased it's laughable. Right from the "Everybody knows about the bumpy road to mastering Angular" to the cherry picking about templates: "Yeah angular wins, but with this third party component React ties again!".
Here are some other golden nuggets:
"React makes it simple to control the performance. If you implement shouldComponentUpdate, you can choose which comparison you prefer - model or presentation." (Oh, "performance" have never been simpler.)
"React gives you the freedom to choose, without the performance penalty. The outcome really depends on whether you're a good coder or a bad coder." (So Angular is slow regardless of you are a "good" or "bad" coder, but React performance depends on you "goodness" - check)
"When something doesn't work in Angular directives, one option is to re-write the code in a different way because there's so much magic going on." (Or you could - like try to find out why something in your directive doesn't work?)
Here are some other golden nuggets:
"React makes it simple to control the performance. If you implement shouldComponentUpdate, you can choose which comparison you prefer - model or presentation." (Oh, "performance" have never been simpler.)
"React gives you the freedom to choose, without the performance penalty. The outcome really depends on whether you're a good coder or a bad coder." (So Angular is slow regardless of you are a "good" or "bad" coder, but React performance depends on you "goodness" - check)
"When something doesn't work in Angular directives, one option is to re-write the code in a different way because there's so much magic going on." (Or you could - like try to find out why something in your directive doesn't work?)
I guess I'm not clear on why the statement Everybody knows about the bumpy road to mastering Angular shows a bias. I've never met a dev who found Angular easy to pick up. In fact, the rest of the original sentence describes exactly how learning Angular goes for everyone I've spoken about it with: it's quick to get started, then it improves and deteriorates as you go along. Emphasis on the "deteriorates".
EDIT: Moreover, your quotation about performance is from the section on "model complexity", where the original authors were far too generous to Angular. The model of an Angular app is tightly coupled to the Angular system, whereas a React app model is just a POJO.
EDIT: Moreover, your quotation about performance is from the section on "model complexity", where the original authors were far too generous to Angular. The model of an Angular app is tightly coupled to the Angular system, whereas a React app model is just a POJO.
Angular has been one of the easiest to pick up javascript frameworks I've worked with.
Easy to start, sure, but try building a complete non-trivial application from scratch.
[deleted]
What would you conclude to be the single most important issue/hurdle/constraint about Angular when moving from simple app to a non-trivial application? (Genuine question)
Inertia. The best practice for many reasons is to structure your app as lots of little components, and doing that in Angular is too hard, mostly because every component is at least three files, likely spread out in different places in the folder structure. The overhead of refactoring a component into smaller pieces is huge, since you have to independently split the template, the scope, and the dependencies.
All of the things that seem useful about Angular become a burden at scale. ng-repeat is my favorite example: try repeating more than a few hundred non-trivial components and you'll quickly choke the browser. You end up having to spend most of the application development time figuring out how to do things in a way that doesn't make Angular too upset.
All of the things that seem useful about Angular become a burden at scale. ng-repeat is my favorite example: try repeating more than a few hundred non-trivial components and you'll quickly choke the browser. You end up having to spend most of the application development time figuring out how to do things in a way that doesn't make Angular too upset.
Going from a simple single-controller to multiple controllers, services, and the rest was a hurdle I never managed to cross. I understand the principles involved, but actually going from "Here's my complete data model, handled by this controller" to "Here's an angular application with a number of controllers and services" isn't something I've managed to do. (Although this is also not something I've had to do professionally so it's not been a focus for me.)
I like Angular a lot, and didn't find it too difficult to pick up.
I had spent a couple of years prior working with WPF which is MVVM based, so I was already familiar with that way of thinking, which maybe helped me out.
I think Angular 2 is going to catch a lot of people by surprise, if they haven't been keeping up though. It's all component based so I've been restructuring my apps so that everything is a component, which means that an upgrade shouldn't be too painful!
I've seen a number of Angular apps though where directives aren't even used, and those people are going to find upgrading to 2.0 pretty much impossible without an entire rewrite I think! Maybe I'm wrong!
I had spent a couple of years prior working with WPF which is MVVM based, so I was already familiar with that way of thinking, which maybe helped me out.
I think Angular 2 is going to catch a lot of people by surprise, if they haven't been keeping up though. It's all component based so I've been restructuring my apps so that everything is a component, which means that an upgrade shouldn't be too painful!
I've seen a number of Angular apps though where directives aren't even used, and those people are going to find upgrading to 2.0 pretty much impossible without an entire rewrite I think! Maybe I'm wrong!
I couldn't agree more. It was my first JS framework, and after 10-12 hours of tutorials I was already building a rather large application with it.
The process was also easy for my coworkers, granted they had someone to ask questions from.
I honestly cannot understand this criticism of the framework being hard.
The process was also easy for my coworkers, granted they had someone to ask questions from.
I honestly cannot understand this criticism of the framework being hard.
It's one of angular's chief strengths that it's easy to pick up. That's my perception anyways. I think that statement about difficulty to master applies more to Ember.js than anything.
I don't think it's trying to be unbiased. The article is about how they came to their conclusion to use React, so of course it's biased! It's just their opinion. Could you write such a comparison and have it actually be useful without including your opinions?
It's obviously anecdotal and not a rigourous breakdown.
I have no experience with React but what little experience I have with Angular makes me think I would come to the same biased conclusion... Angular was just a massive pain to work with if it's basic functionality didn't match your use case. Of course, I was probably "doing it wrong" but that only speaks to the "bumpy road to mastering Angular" the author speaks of.
That and didn't Angular basically get overhauled recently, or is slated to?
foreach(Feature f in AngularJS.Features) { RIP(f); }
I have no experience with React but what little experience I have with Angular makes me think I would come to the same biased conclusion... Angular was just a massive pain to work with if it's basic functionality didn't match your use case. Of course, I was probably "doing it wrong" but that only speaks to the "bumpy road to mastering Angular" the author speaks of.
That and didn't Angular basically get overhauled recently, or is slated to?
foreach(Feature f in AngularJS.Features) { RIP(f); }
If you think you need something like this, I highly recommend that you take a few steps back and rethink how you are doing things.
One of the nicest things about designing a React app is that React makes it so easy to divide your app up into tiny little components that compose and reuse well, and are really easy to understand. Where an angular app might have 5 different controllers and accompanying templates, a similar React app might have 50 different components.
One of the reasons that it's so easy to split off a new React component is because JSX is inline. Putting that into a separate file increases the impedance and maintenance burden substantially.
In other words your
One of the nicest things about designing a React app is that React makes it so easy to divide your app up into tiny little components that compose and reuse well, and are really easy to understand. Where an angular app might have 5 different controllers and accompanying templates, a similar React app might have 50 different components.
One of the reasons that it's so easy to split off a new React component is because JSX is inline. Putting that into a separate file increases the impedance and maintenance burden substantially.
In other words your
var createItem = function(itemText) {
return <li>{itemText}</li>;
};
return <ul>{this.props.items.map(createItem)}</ul>;
return <MyList items={items} />;
When writing React code I'm always accidentally fighting to make things more complicated than the system wants, naively opting for the former version, and only after some refactoring settle on the latter, simpler (but more numerous) representation.
When writing Angular code I'm always fighting to make things simpler than the system wants, trying to break my code up into more distinct components, and only after refactoring or hitting my head against the wall settle on the more complicated (but fewer in number) representation.
That is, I think, why the comparison between the two is valuable: not because they are libraries that fill the same niche, but because they encourage distinct development styles.
When writing Angular code I'm always fighting to make things simpler than the system wants, trying to break my code up into more distinct components, and only after refactoring or hitting my head against the wall settle on the more complicated (but fewer in number) representation.
That is, I think, why the comparison between the two is valuable: not because they are libraries that fill the same niche, but because they encourage distinct development styles.
I think the major achievement of React is the API design: minimal, easy to grasp, composable and make it hard to do stupid things (overly complicated code).
I started out in React by putting all my actual render functions in separate files and linking them to the component in a similar way to this templating setup. It's a pretty natural reaction everyone has when first using JSX... but silly as it sounds, the annoyance of having long render functions in your components actually encourages you to split them up and end up with better code.
That said I never got over wanting nicer if/looping in JSX - if anyone else wants that compromise you can use the library I made to do it: https://github.com/valtech-au/jsx-control-statements.
That said I never got over wanting nicer if/looping in JSX - if anyone else wants that compromise you can use the library I made to do it: https://github.com/valtech-au/jsx-control-statements.
Why do people keep comparing Angular, a complete framework with React, which tackles only a subset of Angular? Also, the supposed architectural "benefit" of using React over Angular is absolute bullshit. You can have the same exact approach using Angular — the one with 50 different components — by building 50 different Angular Directives. I absolutely abhor when people make absolute statements about things to which they are completely ignorant about.
You could split into that many components, but I've never seen anybody do so. Why not? Is it cultural?
Was going to write a similar comment. The other benefit is that everything is just a component.
I hate calling this stuff out, but this is stupid. React and Angular are two totally different things. React isn't even a framework. It's like all that awful "nodejs vs. Rails" stuff from 1-2 years ago.
Though I understand the complaints about this not being the most apples-to-apples comparison, I do think there is value in this article. For instance,
The best feature we found with React is that never, even once, did we have to read its code.
Developing Angular applications is a lesson in learning how Angular works, which means you're not learning how the software should work. You need to know far too much about the internals of Angular to successfully build applications with it, which means it's failed as a framework.
The best feature we found with React is that never, even once, did we have to read its code.
Developing Angular applications is a lesson in learning how Angular works, which means you're not learning how the software should work. You need to know far too much about the internals of Angular to successfully build applications with it, which means it's failed as a framework.
The simple presence of "link" and "compile" thingies in 90% of the directives is a testament that Angular does spill its guts and is not really simple and intuitive. It annoys me to no end because in the end 95% of developers will end up copy-pasta'ing stuff from the (horrible) docs or StackOverflow without really getting it. And the thing is, they're right, they should never have to care about post-link and compile and whatnot.
I mean don't get me wrong Angular is a great framework that opened a lot of possibilities for a lot of people and I'm glad it exists but it's a strange mix of "dead simple" and "oh my god kill me now" levels of sophistication.
I mean don't get me wrong Angular is a great framework that opened a lot of possibilities for a lot of people and I'm glad it exists but it's a strange mix of "dead simple" and "oh my god kill me now" levels of sophistication.
My full-time job involves Angular, and I have to agree. I tried React briefly, and it was much easier because I didn't have to deal with understanding how the internals worked.
ugh, I down voted you but meant to up vote. will try to see how it can be fixed, sorry, fingers too big.
To quote every HN comment thread ever, "I wish there was a way to add some space between those buttons."
I think the documentation has been the biggest sore spot. With React there's a certain lifecycle and within a few minutes I understood what's happening. With AngularJS it feels like the lifecycle's explanation is spread out everywhere and the usefulness of some components isn't clearly explained.
This is why Rails and Django succeeded; amazing docs that walk your through step by step but also amazing reference docs in case you forget anything.
The Angular team's choice to use a custom doc framework shot themselves in their feet.
This is why Rails and Django succeeded; amazing docs that walk your through step by step but also amazing reference docs in case you forget anything.
The Angular team's choice to use a custom doc framework shot themselves in their feet.
A custom doc framework could have been a boon, if they had put as much effort into it as is really needed. The problem is that they have a custom solution AND that custom solution doesn't meet their needs.
One criteria I now use to evaluate framework choice is: will using this framework make me a better developer or a better user of the framework?
There are many other dimensions to it, but having to learn internals of a framework to use it well is an immediate signal to be cautious.
There are many other dimensions to it, but having to learn internals of a framework to use it well is an immediate signal to be cautious.
Ignoring the bias of this article, this comparison makes no sense. AngularJS is a giant framework with all sorts of tools and stuff. ReactJS is a view/two way binding library.
If you are going to compare something, why not do it correctly, and compare it against like a Flux or something.
If you are going to compare something, why not do it correctly, and compare it against like a Flux or something.
This is such a step back, it's a completely wrong approach trying to mimick it in React:
[0] https://github.com/jsdf/coffee-react
<ul>
<li ng-repeat="item in items">{{item}}</li>
</ul>
return <ul>
{this.props.items.map(item => <li>{item}</li>)}
</ul>;
<ul>
{<li>{item}</li> for item in @props.items}
</ul>
[0] https://github.com/jsdf/coffee-react
Fun read, though it seems that either React is almost always the better choice over Angular 1.*, or this author just prefers React over Angular.
I'm thinking the latter is the more likely of the two, but consider my interest piqued. I am a full time Angular developer, but for some time now I have felt obligated to try out React.
Side question: does anyone have any real experience with integrating Firebase with React a la ReactFire? I am currently working on an early-stage app using AngularFire, but it's still early enough to change if given a compelling reason to do so.
I'm thinking the latter is the more likely of the two, but consider my interest piqued. I am a full time Angular developer, but for some time now I have felt obligated to try out React.
Side question: does anyone have any real experience with integrating Firebase with React a la ReactFire? I am currently working on an early-stage app using AngularFire, but it's still early enough to change if given a compelling reason to do so.
I'm going to be a little blunt and say this.
You're a full time Angular developer, you obviously know more about Angular then you do React. So why would you switch to using React? At the end of the day both can do the job just as well.
You're a full time Angular developer, you obviously know more about Angular then you do React. So why would you switch to using React? At the end of the day both can do the job just as well.
Haha... I don't think you're being too blunt.
Why does anyone ever do something new? Curiosity? Maybe I just feel like there can be something gained by learning a slightly different way of doing the same thing?
Why does anyone ever do something new? Curiosity? Maybe I just feel like there can be something gained by learning a slightly different way of doing the same thing?
You need to keep yourself marketable. There are plenty of interviewers who expect most good JS devs to have React knowledge. It's the hot framework right now.
Angular 2.0 takes a lot of the good stuff from React so I think it's much more pragmatic for the average Angular dev to wait for that and learn that first. If Angular 2.0 fizzles, then learn React.
What if they were a full time jquery developer?
I've always thought that flow-control in XML / templates is very messy. That's one of the things that I really like about JSX. It's a very simple, easy to understand transformation to function calls to make HTML generating code look more like HTML, but it's just JS. You don't need to invent flow control attributes on HTML that are really JS, because you are just using JS.
This completely removes that. I'm glad it works for you though and happy hacking!
This completely removes that. I'm glad it works for you though and happy hacking!
I don't see the point of templates in react, it is just another DSL to remember and to easily forget, javascript is better, allow you to build all the most complex things that templates can't. Also template have a price, another element in the hierarchy, it means allocation, vdom diffing, when an if or a forEach in javascript is simpler and less heavy. Not having template is a win.
I see the points why React may be a good choice. Having only worked with Angular so far I really like it's dependency injection and the possibility to make use of services and directives.
However from what I understand React does not implement these features so what additional libraries could be used to keep these mechanisms?
Edit: I'm working in Research so my projects typically have a limited scope and user base.
However from what I understand React does not implement these features so what additional libraries could be used to keep these mechanisms?
Edit: I'm working in Research so my projects typically have a limited scope and user base.
Directives are replaced by React components. I would argue, IMO, that directives are actually a half-assed implementation of components.
In terms of services, I would recommend using Flux to perform actions / store your state. This is what a lot of developers are leaning towards these days. There was a great talk at React Conf about Reflux, I've never used it, but the presentation has convinced me to try it out on my next project: https://www.youtube.com/watch?v=xsSnOQynTHs
When you build with React, imagine building an application in Angular using only Directives. It isn't that simple, but that is sort of the idea with React components.
I started with Angular (and still work day to day with it at work) but if someone asked me how I would architect an application tomorrow, I would go with Flux + React + ES6, no questions asked. Also, Angular2 is heavily influenced by React, so learning React now will allow you to have a better understanding of Angular2.
In terms of services, I would recommend using Flux to perform actions / store your state. This is what a lot of developers are leaning towards these days. There was a great talk at React Conf about Reflux, I've never used it, but the presentation has convinced me to try it out on my next project: https://www.youtube.com/watch?v=xsSnOQynTHs
When you build with React, imagine building an application in Angular using only Directives. It isn't that simple, but that is sort of the idea with React components.
I started with Angular (and still work day to day with it at work) but if someone asked me how I would architect an application tomorrow, I would go with Flux + React + ES6, no questions asked. Also, Angular2 is heavily influenced by React, so learning React now will allow you to have a better understanding of Angular2.
Just to point out that Dan Abramov's talk is about Redux, his implementation of Flux (not Reflux)
https://github.com/gaearon/redux
https://github.com/gaearon/redux
Awesome. Thanks for the help and the pointers :)
The great thing with research-prototypes and their short term lifecycles is that you can explore a lot of different options and strategies (sometimes parallel in different projects).
The disadvantage is that you need to make sure that the prototype stays a prototype and is not "expanded" into something different. (That will fail for obvious reasons)
The great thing with research-prototypes and their short term lifecycles is that you can explore a lot of different options and strategies (sometimes parallel in different projects).
The disadvantage is that you need to make sure that the prototype stays a prototype and is not "expanded" into something different. (That will fail for obvious reasons)
[deleted]
One benefit of React that I haven't seen discussed: Learning it made me feel like I was improving as a programmer. The best way to improve React applications is to learn more about the concepts behind function reactive programming, which is a skill that transfers far beyond the world of frontend development.
Did anyone make it to the end?
The punchline is critical - the article is really about this: http://wix.github.io/react-templates/
which I must admit is intriguing
The punchline is critical - the article is really about this: http://wix.github.io/react-templates/
which I must admit is intriguing
Nope, I did not make it to the end haha. Titling your blog post "Angular vs. React" is a sure way to get clicks, but also a sure way to make the large bulk of the discussion around it be about the rivalry and not about the actual content of the post.
[deleted]
It's an interesting comparison but not something I would put much weight into when it comes to making a decision for my next project. Both React and AngularJS can be introduced progressively so as a 20% time project introducing either of them into existing projects wouldn't be too bad and you can make your own informed opinion then.
to @asanagi who's shadowbanned: [this comment of yours](https://news.ycombinator.com/item?id=9428765) was flagged, I suppose by users, and you've been out ever since.
You may want to appeal to [email protected], your comment wasn't egregious IMO, but the snark made it look trollish.
Looking at your comment history, I see other comments that would probably have gotten you (shadow)banned as well.
https://news.ycombinator.com/item?id=9850480
https://news.ycombinator.com/item?id=9766989
You may want to tone down the aggressiveness in some of your posts.
Edit: addressing your concern about gender, since I feel to some extent sympathetic to what you feel, but not to your reactions.
People who systematically graft a men (agressors) vs women (victims) on topics like domestic violence or prostitution do grind my gears, since it's only part of the narrative and they tend to be blind to the rest of it.
That being said we've been through a heavily misogynistic period (see the women's right movement in the 20th century or this story about raganwald's mother: http://braythwayt.com/posterous/2012/03/29/a-womans-story.ht...), and, due to networks effects, it requires sustained action to correct (see http://ncase.me/polygons/), removing the old biases is not enough.
Still, invoking imaginary hard core feminists in that thread about positive discrimination towards women in academia was a bad idea. Without more context, I would have flagged it if I had seen it back then.
You may want to appeal to [email protected], your comment wasn't egregious IMO, but the snark made it look trollish.
Looking at your comment history, I see other comments that would probably have gotten you (shadow)banned as well.
https://news.ycombinator.com/item?id=9850480
https://news.ycombinator.com/item?id=9766989
You may want to tone down the aggressiveness in some of your posts.
Edit: addressing your concern about gender, since I feel to some extent sympathetic to what you feel, but not to your reactions.
People who systematically graft a men (agressors) vs women (victims) on topics like domestic violence or prostitution do grind my gears, since it's only part of the narrative and they tend to be blind to the rest of it.
That being said we've been through a heavily misogynistic period (see the women's right movement in the 20th century or this story about raganwald's mother: http://braythwayt.com/posterous/2012/03/29/a-womans-story.ht...), and, due to networks effects, it requires sustained action to correct (see http://ncase.me/polygons/), removing the old biases is not enough.
Still, invoking imaginary hard core feminists in that thread about positive discrimination towards women in academia was a bad idea. Without more context, I would have flagged it if I had seen it back then.
Oh god, I didn't think it would be possible to dislike react, but you went and threw a hideous renovating language on top of it. This makes it seem like you don't understand how components work. Why even use react in the first place then?
Yet another Angular VS React comparison that misses the blatantly obvious - the two are not the same. React is a UI component, Angular is a complete framework. Please stop.
There is no best. There is just a best for you/your style.
Angular vs Ember perhaps would be more appropriate.
Ember choices didn't make sense to me until I learn Rails.
I love Rails,I just learned it recently[1] but Javascript is no Ruby. Ember is SPA oriented.
Angular is much more lightweight. It has good integration with legacy jquery plugins and can be used as a widget in a page as well as in a single page application. Angular 1 doesn't rely on a compiler or an complex asset pipeline which makes it way more simple than Ember,React and co.
[1]: After hearing for years that Rails was bad, which it isn't at all, on the contrary, I would definitely write a large web app like a SHOP or a complex CRM with it. On the other hand on the client side, I prefer widgets to SPA since SEO is a core requirement.
I love Rails,I just learned it recently[1] but Javascript is no Ruby. Ember is SPA oriented.
Angular is much more lightweight. It has good integration with legacy jquery plugins and can be used as a widget in a page as well as in a single page application. Angular 1 doesn't rely on a compiler or an complex asset pipeline which makes it way more simple than Ember,React and co.
[1]: After hearing for years that Rails was bad, which it isn't at all, on the contrary, I would definitely write a large web app like a SHOP or a complex CRM with it. On the other hand on the client side, I prefer widgets to SPA since SEO is a core requirement.
NOTE: This article seems to be a couple of MONTHS old. Look at the age in the comments section.
Real Question: Why would you use these instead of something like Knockout.js?
Because it's from Microsoft and they are EVIL!
Seriously though, I've worked on projects with Angular and Backbone and have messed around with React, but every project both big and small that I have started has ended up using KnockoutJS.
It is easy to learn, performs amazingly well even with tens of thousands of records, has extremely powerful custom bindings to extend its functionality and even has excellent templating to boot!
Of course in the end people (including myself) just go with what they know and/or want to learn - so which JS framework is "the best" is just a matter of opinion. Having said that, I'd love to hear from someone that has years of Knockout experience explain why they think it is inferior to any other library OR framework.
Seriously though, I've worked on projects with Angular and Backbone and have messed around with React, but every project both big and small that I have started has ended up using KnockoutJS.
It is easy to learn, performs amazingly well even with tens of thousands of records, has extremely powerful custom bindings to extend its functionality and even has excellent templating to boot!
Of course in the end people (including myself) just go with what they know and/or want to learn - so which JS framework is "the best" is just a matter of opinion. Having said that, I'd love to hear from someone that has years of Knockout experience explain why they think it is inferior to any other library OR framework.
I wish there were something here about testing. Last I looked, Angular has a better testing story than React. This is one thing I like about Angular a lot, the importance the authors put towards making testable JS code.
James Shore (of Let’s Code: Test-Driven JavaScript) has Testability as part of the criteria for his An Unconventional Review of... series of posts.
An Unconventional Review of Angular JS: http://www.letscodejavascript.com/v3/blog/2015/01/angular_re...
An Unconventional Review of React: http://www.letscodejavascript.com/v3/blog/2014/09/react_revi...
An Unconventional Review of Angular JS: http://www.letscodejavascript.com/v3/blog/2015/01/angular_re...
An Unconventional Review of React: http://www.letscodejavascript.com/v3/blog/2014/09/react_revi...
This is a very bad article. I'm not sure I really have more to say about it. Shocked to see this at the top of HN.
What do you expect, HN is a bit of a "fashion magazine" for coder. "Angular? it's so 2013" /s
If you are one of the handful of people who love React, hate JSX, love Angula's directives, but hate Angular...then you will find this article very agreeable. Everyone else will react with a mixture of laughter and confusion.
Sadly, the actual writing and argumentation is poor; if you don't already agree with the author's rather unique point of view, this article certainly won't convince you. It's basically just a puff piece so he can link to his directives-in-React library; eg, important debates about two-way versus one-way binding are dismissed with a quick "React has a mixin for that", which rather misses the point. (Of course, to really discuss this, you'd need to mention Flux, which is studiously ignores, probably because it would distract from his obsession with templates.)
In short: I don't think the author understands React, and I doubt they understand Angular either.