我们为啥需要 React( 六 )
■网友
React 或许不方便书写，但一定方便测试。React 组件渲染是个函数，state 是其内部状态，props 是其参数。然后通过输入输出就能测试组件的渲染，通过 simulate 触发事件，就能测试组件的内部状态变化，从而全面的测试某个组件。市面上还有各种基于 React 的测试框架可以帮助我们很方便的实现这些测试。在这之前，测试 UI 是很麻烦的。另外，Redux 也方便测试，都是函数，通过输入输出就能测试其中大部分逻辑。在一个需要长期维护的的大型的项目里，这些测试用例就可以降低出现问题的可能，同时节约发现问题和解决问题的成本，还可以降低重构的风险。而现实中的大多数项目，都是要求快速出货，怎么快怎么来，死了这个就弄下一个，出现线上 Bug 就直接扣工资，用 React 还写测试的，不能按时出货就统统加班去吧。所以，我们根本不需要 React。(手动斜眼)
■网友
我给别人推销React的时候从来不提“性能”二字。因为React的魅力真正在于组件化开发中各种引领前端潮流的思想，以及在此思想之上带来的大型应用中组件可维护性的提升。说他繁琐不假，这只是一道门槛，过了这道坎，你更多的感受是自然。再来说说关于基于模板语言的框架。模板语言是前端技术发展的中间产物，表现能力差，可维护性和扩展性都不够好，早晚有一天被淘汰。至于未来是不是一定就是React，不一定。不过目前来说React做的比基于模板语言的框架都好。14年刚接触Ractive（和早期的Vue很像的一个MVVM框架）的时候，确实爽的飞起（那个时候Vue才刚刚起步）。早期业务模型和组件交互很简单，也没有产品经理的吹毛求疵，完全开发者自己主导。虽然Ractive的生态基本为0，但大部分功能自己实现起来开发效率确实杠杠滴。一年过后，一些常见的组件比如日历控件、表格分页、排序、各种图表面板都开发的差不多了，日常的需求基本上也能很快迭代完成。不过这个时候创业公司也慢慢变大了、走向正轨了，开始有了产品经理和设计师的强势介入。随之而来的是各种UI和交互的“精心设计”，组件也越来越复杂了。最开始我觉得问题不大，我们有业界先进的MVVM，难不倒的。但是随着产品经理和设计师脑洞进一步扩大，我发现我真的过于乐观了。就拿Ractive来说，各种双向绑定的BUG，很多时候不得不各种hack（国外有人说双向绑定带来的复杂性远大于便利性我真的是深表赞同）；其次就是组件开发能力太渣，由于近半年React用的太爽以致于我已经忘掉它为什么渣了（大概就是扩展性，维护，调试）。为什么我觉得基于模板语言的框架没有未来？主要原因是一旦你使用了模板，必然与JS割裂开来，为什么割裂？因为模板语言的设计者就是这么干的，如果你质疑他们，他们有很多理由来反驳你。虽然模板语言在有些情况确实能提供一些便利性（最常见的比如列表输出），但是它的局限性更大。比如使用纯粹的JS你坐享各种变量和作用域，使用起来再自然不过，到了模板语言那里却是各种蛋疼（因为模板语言的设计者认为你压根就不应该在这里做）。但是又有很多用户需求点却又不得不妥协，导致模板语言开发者不得不扩展模板功能，随之而来引入更多稀奇古怪的语法，增大模板的学习成本和BUG出现的频率。这种局限性是非常致命的，导致模板根本无法方便扩展提供更多功能，也注定了在模板语言这个层面，框架很难有大的突破和创新。
■网友
因为React之前前端生态都是逗比。
所以叫它浏览器里的JVM也不为过，简单、稳定、生态丰富。
React之后真正建立起了前端的生态系统：
企业级开发喊了好多年的CQRS / ES都没几个人敢用，Flex / Redux作为类似的架构已经满大街都是。
Node让异步编程，基于事件编程成为主流，React让更难普及的函数式编程，响应式编程成为主流，React是打破OO统治地位历史的重要一环。
Steve Yegge这些大牛喊了好多年JavaScript不是玩具，Douglas Crockford说JavaScript很像Lisp，根本没人信。React之后前端开发逼格完爆其他主流开发领域。
推荐阅读
- 居家养花不需要太多，养这3款多肉，不仅颜值高，而且可镇宅招财
- 用泡沫箱来养多肉老桩？只要我们把细节做好，同样可以养出状态来
- 沉船■长江千吨级沉船打捞记：守护“微笑天使”我们在行动！
- 『我们』无问西东】石奶引的荷包鼓了 【小康路上
- 接待日|省生态环境厅来通开展“企业环保接待日”
- 为啥看到书柜上的藏书会有心旷神怡的感觉
- 为啥知乎上普便有一种【我在北上广深打工，所以拥有更好的视野】这样的错觉
- 为啥工商银行的用户体验如此之差
- 汽车|看了中消协4S店服务测评调查结果，终于知道法系车为啥卖不好了
- 旅行|需要准备哪些物品？全面冬季出游清单，建议收藏带宝宝出门旅行