Honestly? I would start with React. The way Angular 2 has been going, they are adopting a lot of new ideas from React.
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.
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.