I should mention that it is still rough at the moment. There is a major problem with component API design currently with the lack of a good mechanism to flow changes from the child components to the parent and vice versa for interoperability, but the Angular team is aware of this and working on a solution. I would highly recommend against using Angular 2 for production code currently - it is alpha after all, and it comes with all of the pains of breaking changes, and flawed APIs.
Testing is not as straightforward to figure out either - I believe we on the ng-bootstrap team are the only third party library to actually be testing in Angular 2 currently, so if you want to see how tests work in Angular 2 & how to implement the infrastructure, I would recommend checking out the repository here: https://github.com/ng-bootstrap/core .
React is less full-featured than Angular is less full-featured than ExtJS and so on.
You're not going to use a single tool to build your project. You're almost guaranteed to using different tools to build your frontend and backend (even if some of the tools may be the same or some of the code may be shared). You're extremely likely to use more than one tool for either of them.
Nothing will "provide all [you] need". If it did, it wouldn't be a library or framework, it would already be the finished product you're trying to build.
React does one specific thing and it does it incredibly well. If that thing is what you need: great, you can use React as one of the tools to build your product. If it's not what you need: don't use it. You shouldn't worry about whether something provides everything you need, you should worry about whether what it provides is actually what you need or not.
Angular does a lot more things than React does. Logically that means it's less likely to be a perfect fit for your project. You're more likely to find out that it does something in a way that doesn't work for you, simply because there are more things it does. But it may also do enough things in just the way you need them to be done to be worth the few places where it doesn't fit your project perfectly.
It's always a compromise. Unless you have unlimited time and can develop the perfect tools yourself, you're going to have to make a few sacrifices along the way.
I think there's a list somewhere of patterns that are difficult / non-ideal for React but I don't have it in front of me. For 99% of use cases React really isn't going to be a detrimental choice as long as you choose a good pattern to surround it with.
2 months into the project I'm confident we chose the best tools for the job, there's been absolutely no regrets from the team members.
With React, you have components, which are just things (classes or functions) that convert a set of properties to a subtree of more components (ideally mostly ones that directly represent DOM elements) and do so deterministically and reproducibly.
With Redux you just have objects ("actions") representing changes to your application state and functions ("reducers") that convert an action and the current state into the future state. There are also functions ("action creators") that help you create the former and functions ("middleware") that affect how Redux processes them.
With Angular1 you have templates and directives and components and models and scopes and controllers and filters and injectors and services. And services can be constructors or factories or providers or values or constants or decorators. And scopes can be isolate or nested and there is the digest cycle and there are watch functions and if you do anything async outside of Angular you need to make sure to trigger the digest cycle (but not if you're already in the digest cycle) and I haven't even talked about interpolation yet.
Angular2 is slightly better but the docs are pretty sparse and many people's brains will still shut off as soon as they hear "dependency injection" and have you fucking seen what they have done to HTML to maintain their false illusion of "it's just HTML and JavaScript, designers can understand this"?
React doesn't need you to think. Initially the API made you define components by using a magical function, then they extended it to allow just using ES2015 classes, now you can even define simple components as plain old functions. The surface has shifted from minimal to nearly non-existent.
Redux has more conceptual overhead than React ("Wait, reducers can't have side-effects? Where does my AJAX go?") but most of the learning time is spent un-learning concepts you take for granted (e.g. you shouldn't mutate state, your components should ideally not have any state at all and it's perfectly fine to normalize your state because you only need to derive it when it actually changes). The number of actual concepts Redux brings to the table is fairly low.
Angular is a battleship. React+Redux is an attack submarine.
https://facebook.github.io/react/docs/why-react.html
And once you understand React you can dive straight into the Redux docs:
http://redux.js.org/index.html
I found it useful to actually read the Redux docs page-by-page (at least the introduction and basics) but it also links to some tutorials.
I actually had to read the basics and advanced sections several times before it fully clicked. It helps if you don't expect Redux to be super complex -- like React it does just one thing: manage your state by responding to actions. If React is the V in your MVC, Redux is the M.
> The value of the battleship has been questioned, even during the period of their prominence.... battleships were increasingly vulnerable to much smaller, cheaper weapons...[11] https://en.wikipedia.org/wiki/Battleship
I'm not sure if your metaphor was intentional, that Angular is like a flashy, seemingly powerful but ultimately archaic, dead-on-arrival platform, but I appreciate it nonetheless.
I'm not denying it was...
But if one can store the component state in React setState, why one should look for "Redux" or any Flux libs?
It's still at a very early stage though (alpha), but I think it has great promise. More details in the recent 2.3 beta changelog:
http://emberjs.com/blog/2015/11/16/ember-2-2-released.html#t...
(Not saying you made the wrong choice, it sounds very reasonable -- Ember's solution isn't ready for use just yet. But thought I'd note this here in case others have the same thought)
I'm really excited at the rate of pace of change on the front-ends. My last project was in Backbone and React & Redux feel a gigantic leap forward. I'd love to experiment with Elm and Cycle.
I would make a couple of changes and if one of them broke something, I was not able to quickly identify what I had done that was a problem. I'd recommend that you go step by step a build a small app from the ground with tutorials.
The best way is to follow a tutorial and build a small project from the ground up. Stay away from prefabricated solutions until you understand what's going on.
See, but all of that is highly non-trivial and everyone has different opinions.
It does help to have a good awareness of what libraries are being released and are becoming popular before you start needing them however, so you can realise when you are facing a problem that has already been solved - it helps if you read the React-related stuff that appears on HN and follow a few of the "key players" on Twitter.
The big starter projects are a great resource for code examples of how pieces fit together and for pointing you in the direction of other interesting libraries, but are just too overwhelming to work with if you aren't already familiar with the core components of the stack.
One thing I am enjoying a lot about the React world (compared to the Angular world, in my case) is that each library/component tends to be pretty simple (for example, the APIs are pretty small) and you can reason about what it is doing in your head; but the way they fit together can make solving complicated problems feel really easy once you get your head around the React/Redux (or whatever) approach to breaking things down. I feel like I have a much better understanding of what is going on under the hood with the application than I did with Angular, and this makes solving hard problems much easier, even if it means more setup and lines of code initially.
http://www.angular-meteor.com/tutorials/socially/angular2/bo...
I enjoyed the meteor angular 1 version and plan on doing the angular 2 version soon.