4 ms·
I couldn't figure out from the blog post why you switched from backbone to react. Could you talk a bit about the reasons?
by Joeri 10y ago
I couldn't figure out from the blog post why you switched from backbone to react. Could you talk a bit about the reasons?
- thejameskyle 10y agoI left them out because many others have blogged about the same reasons. But this is the biggest reason: We have a lot of complexity in our view/component layer where we trying to bring simple workflows to very complicated technical features. Backbone (even with Marionette) doesn't have a strong view composition story, essentially avoiding setting up any patterns. React's composition pattern is so strong that its hard not to abstract things. The complexity is still there but its easy to follow and extremely simple to test (especially with redux). There are more reasons, but I have to go now. Hopefully that suffices
- bzalasky 10y agoWith 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.