But we should also learn from where Angular succeeded and where it failed. Making XML declarative is fraught with difficulties. Things like ng-repeat are but a thin declarative veneer over the fundamentally imperative nature of constructing views. The biggest difference between most existing templating frameworks and React is in this world view: is the view constructed imperatively, or is it declared?
The other question of contention is how much implicit magic should the framework supply vs how much explicitness the user should bring into the code. Angular's design decision is to make bindings work magically, while React identifies explicitness as a virtue.
Having used both, I'm liking the imperative+explict camp.
My 2 cents: I actually prefer the declarative approach. My attempts at imperative view generation resulted in far more shooting-on-the-foot. Naturally, this is the very specific conclusions of me and my team, not the entire human race. I always think you should try both!
Also, I'm a huge fan of Polymer, which is also very much declarative. Going to use Angular instead of Polymer simply because of better project structure and browser support.
I'd be interested to know how many of your large team were not experienced web developers before starting with Angular given that is one of the big criticisms in the article.
I can't stand how some articles simply s&*t on years of software architecture principles and the work of very talented engineers and simply dismisses them like it's nothing.
If you disagree with a framework's perspective, AT LEAST be respectful.
BTW, I also have used Angular for 2 years and, given the pros and cons and existing alternatives, I will choose it again for my next big project. The structure is simply too solid. This is invaluable when you have a large team that must work together.