前端迷思与React.js

    前端技术这几年蓬勃发展, 这是当时某几个项目需要做前端技术选型时, 相关资料整理, 部分评论引用自社区。

开始吧:

• 目前， Web 开发技术框架选型为两种的占 80% 。这种戏剧性的变化持续了近 6 年。
• 自 2013 年 5 月推出以来，ReactJS 在过去三年中已成为了 Web 开发领域的中坚力量。
  

任何组件与框架都有它的适用场景, 我们应该冷静分析与权衡, 先来看React.js

1 从功能开发角度说，React的思路很好。
2 从页面设计角度说，传统的HTML+CSS以及同样思路的模板更好。

     大家开发前端的思路早已不是当年的 Web page，而是Application。大多数公司不是Facebook，没有那么多全栈高手。团队中擅长写业务的，未必擅长页面布局；擅长页面布局的，未必擅长写业务。这样在团队中必定会有分工，其中会有些人着重实现炫酷的页面效果，而React显然对这种分工不友好。

为什么需要 React,Why？

    我们需要技术栈提供好用的模块化方式，可以是Web Component，可以是非Web Component的某种机制，不管什么库或者框架，我们需要技术赋予我们完成一个抽象，一次构建，多处复用的能力，并且这个过程不能太麻烦，不能做个很日常的抽象翻半天文档。
    我们需要数据绑定，在各种粒度上真正实现事件驱动，因为这样我们就不用自己重复手写本质上并不依赖场景的从视图到数据从数据到视图的自动更新，否则我们就得自己操作DOM，优化DOM操作，还要自己维护状态，一自己维护状态，就要陷入状态同步的漩涡，浪费大量时间和精力。
    我们需要技术栈隐藏掉平台的微妙差异，写一段代码可以真正实现跨平台，而不用我们自己纠结于那些本不该应用开发纠结的事，我们需要持续稳定的跨平台支持，最好的移植就是不用移植，这在商业上有很大的价值。
我们需要库或者框架好学，好用，从第一天起就能快速开发，而不是不得不经历几个月的学习曲线那种，因为大多数团队的程序员水平都存在梯度，我们不希望因为一个技术栈把初学水平的人挡在门外很久，理想的状态是技术本身能对招聘工作完全透明，同样的工期，同样的项目，随时找人都可以，招人的时候不用写得过于具体，只要会java script就能快速上手，我们需要概念负担尽量少的技术栈，真正理解了Simplicity的技术。
    我们希望技术栈有非常好的性能，性能的水平和垂直扩展性都很好，这样我们就不用项目写到一半回头去纠结应用开发团队很难解决的性能问题，我们需要在快速开发和基础性能之间平衡得很好的工具，而不是因为要强调某一方面而对另一方面关注太少的那些工具。
    我们需要使用的工具有专业的团队或者社区持续地跟进，最好这些团队和社区自己就把自己的东西投入生产使用的技术，这样至少对我们来说风险就有起码的控制。我们不需要那些心血来潮，永远不成熟因为永远没有专门投入的技术。
    我们需要那些普通人喜欢用，也用得好的技术。
    React满足上面的一些方面，不满足另一些方面，和其他工具一样。你需要React，是因为两点
    第一，你充分评估了你的项目，理解你要解决的问题是什么，是快速开发，性能，团队的人类工程学，多数情况下要解决的问题是多个要素的平衡
    第二，你充分评估了React这个栈，理解它是解决你的具体问题的最佳工具，你真的理解了自己的场景中非用React不可的那些事情
    如果你觉得React快所以需要，事实是React并没有那么快，尤其是大型应用，小型应用里快是不重要的，所有的框架都足够快。
    如果你觉得React开发快所以需要，事实是React并一定是最好用的，尤其是当你考虑了团队的构成。

    如果你觉得React是Facebook开发的所以需要，我的揣测是经历过一个社区adoption的高峰以后，Facebook未必能解决剩下的那1%的问题。
    如果你觉得React Native很火所以需要，这或许是一个理由，但RN也不是唯一选择，从各方面评估，NativeScript这样的栈并不比RN坏多少，也许还稍微好一点。如果是大预算的商业开发，RN甚至不应该成为首选。

    大部分人在用 React 的时候，用到的是两个特性：

    1. 虚拟 DOM

    2. 组件化

   至于其他的伪特性，我认为是有些同学「一瓶子不满，半瓶子咣当」，意淫出来的。这些伪特性包括：

    1. 跨平台。虽然 ReactNative 可以在多个平台上使用，但是 ReactNative 并没有封装不同系统的 API。从这方面来说，这货甚至连 weex 都不如。
    2. 更易于组织逻辑。这明显是 flux/redux 做的事情。而且 redux 已经明确说明了，不仅仅适用于 React，其他框架也可以用 redux。

我们真的需要上述的两个特性吗？

虚拟 DOM

虚拟 DOM 解决了频繁操作 DOM
产生的性能问题。那么下面几项事实必定会导致这一特性「没有前途」：

1. 设备的硬件性能会越来越好，性能在将来不再是问题。
2. 假如说我们要解决性能问题，相比虚拟 DOM，
下面几个解决方案会更好：
1. 浏览器实现虚拟 DOM。而且这也是虚拟 DOM 被应用的正确场景和姿势。
2. 再操作数据的地方做 diff，而不是在虚拟 DOM 的基础上做 diff。这是才是 cache/diff 的正确用法。

组件化

组件化有一个很重要的目的是为了提高开发效率。再来看一下使用 React 开发效率高吗？

民间：想加班就用 React

为了说明 React 的开发效率，不妨点开两个链接看一下代码行数。下面两个链接都实现了一个聊天应用，完全一样的功能：

· React 版本：187 行

· Riot 版本：53 行

React的不足之处

纯净、不可变性和解决问题的意识形态

    不要误解，我其实很感激React所带给我们的纯净的函数编码方式和简洁的渲染手法，在实际应用中，这些都算得上好东西。我想说的是其它方面的东西。

    如果你的公司里有千人开发团队，而刚好你决定要为PHP里的静态类型开发自己的语法，又或者你正从Haskell转向JS，那么一定程度的严格和纯净是非常有用的。不过大部分公司不会有那么大规模的开发团队，也不会有Facebook那样的宏大目标。下面我会更详细地解释这一点。

JSX糟糕透了

    我知道，它“不过是具有特殊语法的java script罢了”。我们的前端设计人员为了