1) if I understood correctly, the design of Angular has some inherent, and rather large, performance hits.
2) Google isn't dogfooding Angular save for one project. Facebook seem pretty serious about doing all new developement in React.
3) the specific kind of developement they're doing is similar to the one I have to do right now, viz. taking an established mostly static page and adding bits of highly interactive and dynamic behavior here and there. Google used Angular to reimplement the app from scratch. I can't afford that.
4) Angular, at what will probably the top of its popularity right now, just broke all interfaces and syntax and everything during the passage to 2.0, for reasons that were never fully explained (to me at least). Facebook won't be able to do that without breaking the proportionally large investment they had so far with React.js and incurring significant costs, which is nice and stable and comfortable. If the benefit/cost ratio of React 2.0 (or 1.0, I guess) is acceptable for Facebook, then it will probably be acceptable for me, too.
5) React interacts nicely with their Flow typechecker, which I think is, uh, the safest vector, right now, to foster the adoption of algebraic typing in the mainstream of programming. I won't typecheck my JS before the summer, probably, but still, this is philosophically fun.
I've made applications using both React and Angular. Qualitatively, Angular is way easier to get started, but React "feels nicer" (it's hard to explain, but because you have to handle a lot of the eventing and message passing yourself, you feel like you understand your own app a lot better. Angular is a framework, with inversion of control -- React is just a library).
IMO, you should use Angular, unless you:
1. Need good performance with over 1000 data bindings
2. Are making a literal SPA (i.e. don't really need URL routing or multiple controllers)
3. Plan to build a long-term rock-solid application (like a backbone for an enterprise)
4. Want to understand exactly what is happening in your app.
This reads like satire, because who the hell would not want to build something solid or understand what's happening in their app?
Also, the most common complaint about Angular is that it's very hard to understand, very opaque, and lacking in documentation, so your only "pro" for Angular is a pretty unusual one.
I don't think you always need to know exactly what's going on. Angular is a lot like Rails in my mind -- there is "magic", but it makes things easier.
Personally, I never thought Angular was very hard to understand. The main problem is that the documentation is sometimes outdated. If you are familiar with server-side MVC, I think Angular will come naturally to you.
But, if my post sounds biased towards React, it's because I prefer it. I would use Angular for things you want to do in four days and never touch again, but that's about it.
Yeah, it totally sucks. That is one of the reasons that, in projects that I expect to be maintaining for a long time, I shy away from frameworks with inversion of control, like Angular or Rails. I prefer the wiring to be exposed, so to speak, because it makes it easier for everyone to know what's going on. It also makes it easier to drop or upgrade your 3rd party dependencies without rewriting everything.
Plenty of projects just need to be built to test. My apps would never be built and then rev'd if they were built to be "rock solid" in their first iteration. It's important to have frameworks that get apps off the ground quicker.
Personally, when I switched to React, I never turned back. Angular gives you more out of the box but I personally hated that box. I really jive with the React way of doing things and mixins allow you to easily add more functionality like routing, etc.
that's dependent on the problem at hand. Are you building a site that has a lot of moving parts on the same page, that needs to communicate nuanced state changes across components? If so, react/flux is a godsend, since the system will be easier to maintain and customize.
Is your site made up of many different views that don't change much once loaded? Then angular would be a fine tool for the problem. You would likely move much faster initially, since Angular handles a lot of problems with data binding and routing for you.
And finally, are you sure you need either of these frameworks? If you want your front end to consume JSON but it isn't particularly dynamic, something like backbone will probably be good enough. Hell, server-rendered templates do the job in a lot of cases. No reason to solve a problem that doesn't exist.
1) if I understood correctly, the design of Angular has some inherent, and rather large, performance hits.
2) Google isn't dogfooding Angular save for one project. Facebook seem pretty serious about doing all new developement in React.
3) the specific kind of developement they're doing is similar to the one I have to do right now, viz. taking an established mostly static page and adding bits of highly interactive and dynamic behavior here and there. Google used Angular to reimplement the app from scratch. I can't afford that.
4) Angular, at what will probably the top of its popularity right now, just broke all interfaces and syntax and everything during the passage to 2.0, for reasons that were never fully explained (to me at least). Facebook won't be able to do that without breaking the proportionally large investment they had so far with React.js and incurring significant costs, which is nice and stable and comfortable. If the benefit/cost ratio of React 2.0 (or 1.0, I guess) is acceptable for Facebook, then it will probably be acceptable for me, too.
5) React interacts nicely with their Flow typechecker, which I think is, uh, the safest vector, right now, to foster the adoption of algebraic typing in the mainstream of programming. I won't typecheck my JS before the summer, probably, but still, this is philosophically fun.