为何Facebook选用React而非性能更优的原生JavaScript？

Paul Lewis在2015年7月发布的《React + Performance = ?》一文里，分享了一个值得所有前端人关注的性能测试案例：在Flickr图片无限列表的场景下，React的性能表现居然落后于手写的原生JavaScript，尤其是在移动端设备上，这个差距更为显著。

这个案例最核心的启示就是：没有任何一个框架能在所有场景下都保持最优性能，我们必须针对自己的特定业务用例、目标平台以及用户使用的设备，去做针对性的性能测试和优化，不能盲目迷信框架的“万能性”。

说到这儿，我也忍不住琢磨：Facebook作为React的缔造者和重度使用者，为什么会选择用React来处理这类看似“性能不占优”的场景呢？其实仔细想通了就会明白，框架的价值从来都不是只看单一场景的性能数值——React带来的组件化开发模式、跨平台适配能力、成熟的生态工具链，还有团队协作效率的大幅提升，这些都是它不可替代的核心优势。

很多时候，业务开发的效率、代码的可维护性，在团队协作的场景下，优先级可能会高于单一的性能指标。当然，这也不意味着我们要忽略性能问题，像无限列表这类常见的性能瓶颈，社区早就有了成熟的解决方案，比如虚拟滚动组件，就能很好地平衡开发效率和性能表现，让我们既能享受React带来的开发便利，又能解决特定场景下的性能问题。

内容的提问来源于stack exchange，提问作者luiswill