作者 | 刘麒麟（京东金融移动研发部）
对于框架、工具、方法，每个人都有不同的选择。作者简述了他的选择，那么你选择什么？理由又是什么呢？ 契 子昨天参加学习部门一同学的 React 分享会，会上有很多后端的同学参加，大家都对前端有一定的知识积累。于是会上陆陆续续都抛出了同一个共性的问题。“我用传统的开发方式一样能写出来的东西，为何要用 React，Redux 等一些复杂的东西表达出来”。
接触 React 也有快两年的时间了。RJ、RN 都开发过大大小小的项目。借此机会反思起来，突然发现当初感觉是用来装 X 和有些鸡肋的东西竟有些割舍不开而且散发着深刻的魅力。
众 说一说到为什么选择 React，用过的或者网上介绍的一般都是这些优点：
1.View 层框架。• 数据试图分离，数据规模大的项目开发便捷。
• 虚拟 dom，diff 渲染，性能高效。
2. 组件化• 标签化的组件表达方式，清晰。
3. 三端• 这也许是 React 最吸引人的地方了。一套代码，三端生产。
独 白上面基本是大家耳熟能详的 React 的优点，下面更想换个角度，宏观点看看 React+...
分工 —— 碎片化的追求项目工作工作中常遇见有个棘手的问题 - 一个超级大项目但是时间又很急给 3 人做如何分工？
• 传统的分工：按页面拆分
这个分工看似合理，但是这个“合理”也仅仅站在研发的角度。但是一个完整的项目设计到的角色很多，PM，UI，甚至还有 BD 一类的。这么一看，问题就来了。这个分工每个研发角色都需要和其他各个角色打交道呀。大公司 + 打交道，你懂的。so，酸爽。那怎么办呢？这个可不碎片化哦。那 React 能解决吗？
• 引入 React ： 按组件拆分
这个分工让张三和李四逃出了 PM 和 BD 的魔爪，让王五一个痛苦去吧。但是呢，来自 UI 的压力也基本被张三和李四分担了。这个已经很合理了吧，还有优化空间？咱们仔细看一下。 王五是比较累的，因为张三和李四分担了他的不同的功能组件。他在整合业务会和这两人同时打交道。那再来个 Redux？
• 引入 Redux ： 数据流管理，组件再拆分动静态
这下好了，王五负责和 PM，BD 交涉。李四负责做王五和张三的桥梁。张三不管业务，一门心思和 ui 同学搞组件。
这就是 React+Redux 的强大，他能让你在分工的时候追求碎片化到极致。虽然看似代码的行数可能没有精简，但是无形中把人员的关系解耦了。
规范 —— 自律让我自由看到上面，有的朋友会质疑了。“你这个东西是强拉着和 React 有关系。说白了就是个项目架构和职责的化分问题。我就是用原生的开发也可以这么划分呀。”
理论上是这样没错。但是所谓框架，就是架构设计的选型承载。它已经为你的这种设计提供了很好的功能 api 和工程规划。
React 提供的这些组件的表达方式，Redux 提供的组件和数据之间的绑定方式。虽然看上去表复杂，但正像小标题说的那样。因为这些看似复杂的状态对象，生命周期，动作函数。才使得你在组件内部无论什么样的风格，也不会让组件和组件之间（其实也就是开发者与开发者之间）的逻辑传递有任何阻碍。在这套框架下，看似自律了，其实是“自由”了。
生态 —— 路见不平一声吼就算结合了上面两点，但是还让你觉得。“无非就是个框架的事儿，不一定非要用 React 呀。” 那接下来我只有弱弱的澄清一下。
确实不一定非要用 React，囧。
据不完全统计，React 有比其他类似框架更庞大的周边生态。开发者都明白，真正能让项目开发过程享受便利的一定是好的框架 + 丰富的库。而这一点，也是 React 对标竞品的优势所在。
谢 幕最后的最后，说一个笔者自认为比较中肯的悖论。
框架是选型的产物，针对不同的业务产品选择最适合的框架一定是更高的境界。但是，一年中天天都有 NBA 比赛，全明星能有几场呢？
本文首发于公众号前端工坊，已获转载授权，原文地址：
https://mp.weixin.qq.com/s/zLwMt790iW9kNSRi3XEw9A
投稿到前端之巅请发邮件到 luna.han@infoq.com 。
今日荐文
点击下方图片即可阅读
前端每周清单第 15 期：Node.js v8.0 发布；从 React 迁移到 Vue；前端开发的未来
视野拓展
InfoQ 主办的移动和前端开发领域的精品大会【GMTC 2017】将于 6 月 9～10 日在北京举行，作为首届以“大前端”为主题的大会，GMTC 涉及移动、前端、跨平台、AI 应用等多个技术领域，帮助你方方面面提高技术水平。扫描下图二维码，前往官网了解详细信息！
「前端之巅」是 InfoQ 旗下关注前端技术的垂直社群，加入前端之巅学习群请关注「前端之巅」公众号后回复“加群”。推荐分享或投稿请发邮件到 editors@cn.infoq.com，注明“前端之巅投稿”。
