Modifying the DOM is usually the bottleneck in web apps. To get a fast app (extreme simplification), you need to only apply the minimum set of mutations. It tur

Modifying the DOM is usually the bottleneck in web apps. To get a fast app (extreme simplification), you need to only apply the minimum set of mutations. It turns out that in a large codebase this is extremely hard to do. React asks the developer for a virtual representation and computes the diff between the previous one. In most situations, the time it takes to compute the set of mutations is negligible compared to the cost of the unneeded dom mutations it removed. But, if you need extremely high performance and your problem is small (eg: the text editor part of atom), you can write specialized code that will compute the minimum set of mutations yourself and don't pay the cost of React. That's also why you see so many small benchmarks beating React but those wins don't translate in real applications. Now, it doesn't mean yet that you should drop React. The great thing is that you can make a React component <TextEditor> that itself uses manual dom operations to be super fast. And the rest if your app uses React for its wins. In Atom case, they also want to support people writing plugins. Now it's not only technical but becomes political. Do you want to force people to use React for writing plugins? What if they want to use jquery or ember or angular? You also get into dependency issues. React requirement today is that there can only be one version loaded at the same time, otherwise everything breaks. If you update React in Atom core, you run the risk of breaking all the plugins that were written for a different version of React. Given those, it makes sense to remove React as a dependency from the core. Fortunately, it's still totally possible to write atom plugins using React