With regard to adopting React, coming from Backbone in the past. I've found that it simplifies the view layer, particularly when it comes to extracting shared functionality. It's not to say that you can't do this in a Backbone application, far from it. However, it's less work in a React application because of how React enables composition.
There were two primary drivers the led me to adopt Redux.
1) When working with multiple services to build a single view, Backbone models are the wrong abstraction. Redux allows you to work with arbitrary data structures without the need to deal with hooking up events between nested models/collections. It also prevents overfetching or having to resort to nested models when a single endpoint serves multiple views.
2) Managing complex asynchronous flows becomes easier when there's a single source of truth.
The backends for frontends pattern that Netflix and Thoughtworks have written about is another approach to dealing with the multiple services issue, but in reality, it's not an option for every project.
There were two primary drivers the led me to adopt Redux.
1) When working with multiple services to build a single view, Backbone models are the wrong abstraction. Redux allows you to work with arbitrary data structures without the need to deal with hooking up events between nested models/collections. It also prevents overfetching or having to resort to nested models when a single endpoint serves multiple views.
2) Managing complex asynchronous flows becomes easier when there's a single source of truth.
The backends for frontends pattern that Netflix and Thoughtworks have written about is another approach to dealing with the multiple services issue, but in reality, it's not an option for every project.