| I worked on a Backbone app for several years (and still do, technically - we're about to do a final push to finish migrating it to React). I also liked the fact that you could step into Backbone code, and back out to app code on the other side. Backbone's source is small, and you can see exactly what it's doing. However... React is simply a fundamentally superior programming model, for a wide variety of reasons. I can treat React as a black box, knowing that if there's a problem in my UI, it's because of either the logic in my components, or the data those components are using for display. (Then there's things like being able to arbitrarily compose child components together and pass them props, vs randomly trying to attach subviews or something via umpteen different plugins.) I'll agree that seeing a stack trace with React library code isn't typically helpful. But, the error messages are usually sufficient to tell me what kind of an issue is going on, and point me to the right component or part of the tree to start debugging the real issue. Somewhat related to this, I put together an extensive post earlier this year called "A (Mostly) Complete Guide to React Rendering Behavior" [0] that digs into detail on how React's rendering actually works, as I've found that a lot of people seemed to be missing how some of the pieces of rendering fit together: [0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-... |