React's API is fairly stable, and has been for a long time. Redux has almost become the de-facto standard for new projects, but again, it is just a library arou

React's API is fairly stable, and has been for a long time. Redux has almost become the de-facto standard for new projects, but again, it is just a library around a good idea: do all state transitions inside a pure function - get an input, return a new output, and the entire view gets re-rendered with it. You can use React's immutability helpers inside it, or or performance in large state trees, use ImmutableJS that gives persistent immutable data-structures. This comes at the cost of having to use its own methods like map and filter, instead of normal JS everywhere. But that is pretty much it. There are a few more other concerns that'll necessitate the use of redux-thunk, (which at its core is a few lines long), but you don't need to worry about any of this upfront. The thing with React is that unless you make costly architectural decisions upfront, you can always learn as you build, and figure out the right way to structure your project. Once you've built a fairly large project, you'll form your own set of opinions on which way you like to think about front-end code, and that'll inform you on your next project. There is a learning curve, but with React, you are always thinking about fundamental things like encapsulation and message-passing than trying to learn non-transferable knowledge about a particular framework's quirks and conventions.