我们为啥需要 React
我们需要技术栈提供好用的模块化方式，可以是Web Component，可以是非Web Component的某种机制，不管什么库或者框架，我们需要技术赋予我们完成一个抽象，一次构建，多处复用的能力，并且这个过程不能太麻烦，不能做个很日常的抽象翻半天文档。我们需要数据绑定，在各种粒度上真正实现事件驱动，因为这样我们就不用自己重复手写本质上并不依赖场景的从视图到数据从数据到视图的自动更新，否则我们就得自己操作DOM，优化DOM操作，还要自己维护状态，一自己维护状态，就要陷入状态同步的漩涡，浪费大量时间和精力。我们需要技术栈隐藏掉平台的微妙差异，写一段代码可以真正实现跨平台，而不用我们自己纠结于那些本不该应用开发纠结的事，我们需要持续稳定的跨平台支持，最好的移植就是不用移植，这在商业上有很大的价值。我们需要库或者框架好学，好用，从第一天起就能快速开发，而不是不得不经历几个月的学习曲线那种，因为大多数团队的程序员水平都存在梯度，我们不希望因为一个技术栈把初学水平的人挡在门外很久，理想的状态是技术本身能对招聘工作完全透明，同样的工期，同样的项目，随时找人都可以，招人的时候不用写得过于具体，只要会JavaScript就能快速上手，我们需要概念负担尽量少的技术栈，真正理解了Simplicity的技术。我们希望技术栈有非常好的性能，性能的水平和垂直扩展性都很好，这样我们就不用项目写到一半回头去纠结应用开发团队很难解决的性能问题，我们需要在快速开发和基础性能之间平衡得很好的工具，而不是因为要强调某一方面而对另一方面关注太少的那些工具。我们需要使用的工具有专业的团队或者社区持续地跟进，最好这些团队和社区自己就把自己的东西投入生产使用的技术，这样至少对我们来说风险就有起码的控制。我们不需要那些心血来潮，永远不成熟因为永远没有专门投入的技术。我们需要那些普通人喜欢用，也用得好的技术。React满足上面的一些方面，不满足另一些方面，和其他工具一样。你需要React，是因为两点第一，你充分评估了你的项目，理解你要解决的问题是什么，是快速开发，性能，团队的ergonomics，多数情况下要解决的问题是多个要素的平衡第二，你充分评估了React这个栈，理解它是解决你的具体问题的最佳工具，你真的理解了自己的场景中非用React不可的那些事情如果你觉得React快所以需要，事实是React并没有那么快，尤其是大型应用，小型应用里快是不重要的，所有的框架都足够快。如果你觉得React开发快所以需要，事实是React并一定是最好用的，尤其是当你考虑了团队的构成。如果你觉得React是Facebook开发的所以需要，我的揣测是经历过一个社区adoption的高峰以后，Facebook未必能解决剩下的那1%的问题。如果你觉得React Native很火所以需要，这或许是一个理由，但RN也不是唯一选择，从各方面评估，NativeScript这样的栈并不比RN坏多少，也许还稍微好一点。如果是大预算的商业开发，RN甚至不应该成为首选。
■网友
react/vue/angular2我都用过，个人感觉react很多地方还是有过人之处的。
诚然如果只是react而不是react全家桶，确实简单，但也甚至无法胜任小项目。于是乎出现了redux, react-router来救场。我个人比较喜欢react的地方就是数据决定视图，很符合函数式的思想（估计大部分react粉就是因为这个原因喜欢上react的）。react生态圈目前可以说是三大框架中最完整的（还有react native来助阵，虽然坑较多，但也快填平了），也是目前唯一经过大型应用考验的。
react一开始只是一个库，但是这两年特别火，不断有人往上面添砖加瓦，现在已经成了一个比较完整的生态圈了，就目前而言，他不像一个库，而像一个框架了。
反观angular，这个完整框架现在也拆分成各种小组件了，我到是觉得这是框架解耦，变成一个一个的库。angular数据流管理官方推荐的是Rxjs，是函数式和观察者模式的混合，和react比也不分上下。用于不用完全是个人习惯问题，技术上倒是没什么优劣之分。
推荐阅读
- 居家养花不需要太多，养这3款多肉，不仅颜值高，而且可镇宅招财
- 用泡沫箱来养多肉老桩？只要我们把细节做好，同样可以养出状态来
- 沉船■长江千吨级沉船打捞记：守护“微笑天使”我们在行动！
- 『我们』无问西东】石奶引的荷包鼓了 【小康路上
- 接待日|省生态环境厅来通开展“企业环保接待日”
- 为啥看到书柜上的藏书会有心旷神怡的感觉
- 为啥知乎上普便有一种【我在北上广深打工，所以拥有更好的视野】这样的错觉
- 为啥工商银行的用户体验如此之差
- 汽车|看了中消协4S店服务测评调查结果，终于知道法系车为啥卖不好了
- 旅行|需要准备哪些物品？全面冬季出游清单，建议收藏带宝宝出门旅行