前端迷思与React.js

时间 2019-11-10

标签前端迷思 react.js react 栏目 React 繁體版

原文原文链接

前端迷思与React.jsjavascript

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

开始吧:html

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

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

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

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

为何须要 React,Why？

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

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

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

1. 虚拟 DOMwebpack

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糟糕透了

我知道，它“不过是具备特殊语法的javascript罢了”。咱们的前端设计人员为了作出漂亮的表单，把表单元素放置在div里面，他们根本不关心什么纯净或ES6。设计React组件仍然须要耗费大量的时间，由于JSX的可读性太差。还有一个很差的地方，就是你没法在HTML代码里使用普通的IF语句。React的忠实用户会告诉你说，有了三元运算，就不须要再使用条件判断了。不过我向大家保证，当你再次阅读或编辑这些代码时，你会发现它们仍然是HTML和JS的混合体，尽管它们能够被编译成纯粹的JS。

<ul>

       {items.map(item =>

         <li key={item.id}>{item.name}</li>

)}

</ul>

不少开发者认为这种严格的限制能够帮助咱们写出更加模块化的代码，由于咱们必须把代码块放到工具函数里，并在render()方法里调用，就像这我的建议的那样：
http://stackoverflow.com/a/38231866/1132016。

JSX甚至让咱们不得不把15行的HTML代码分红3个组件，每一个组件里包含5行代码。

不要认为这种作法会让你成为更好的开发人员，你只是不得不这么作而已。

而事实实际上是这样的：

若是你正在开发一个相对复杂的组件，而你并不打算明天就把它发布到GitHub上，那么上述的方式只会拖你的后腿，特别是在你要解决真实的业务问题时。不过不要误会，我并非说拆分红小组件就必定很差。

你固然清楚经过拆分能够提高代码的可管理性和可重用性。但前提是，只有当业务逻辑实体能够被放到一个单独的组件里时才要这么作，而不是每写一个三元操做代码就要进行拆分！每次在建立新组件时都会让你和你的意识流付出必定的代价，由于你须要从业务思惟（在你记住当前组件状态时，须要增长一些HTML代码让它运行起来）转换到“管理思惟”——你须要为这个组件建立单独的文件，考虑如何给新组件添加属性，并把它们跟组件状态映射起来，还要考虑如何把回调函数传递进去，等等。

你被迫使用这种过分且不成熟的组件模块化方式来编写代码，从而下降了编码速度，而从中获得的模块化可能并不是你所须要的。在我看来，不成熟的模块化跟不成熟的优化没有什么两样。

对于我来讲，代码的可读性是很是重要的，不过是否可以从编码中得到乐趣也很重要。为了实现一个简单的计算器控件而去建立六个组件，这样的事情一点也不有趣。大多数状况下，这样作也不利于维护、修改或控件检修，由于你要在不少文件和函数间跳来跳去，逐个检查每个HTML小代码块。再次强调，我并非在建议使用单体，我只是建议在平常开发当中使用组件来替代微组件。这是常识性问题。

在React里使用表单和Redux会让你忙得停不下来

还记得吗，React的设计在于它的纯净以及干净的单向数据流。这就是为何LinkedStateMixin不受待见，你须要为10个输入建立10个函数，而80%这样的函数只包含了一行this.setState()代码，或者一次redux调用（或许你还须要为每一个输入建立一个常量）。若是只要在脑子里想一想就能自动生成这些代码的话，或许仍是能够接受的，但如今尚未哪一个IDE能够提供这样的功能。

为何要敲这么多的代码呢？由于双向绑定被认为是不安全的，特别是在大型应用里。我能够确定地说，双向数据流的代码可读性确实不是很好，而Angular 1的双向绑定更是糟糕透顶。不过，这些还算不上大问题。

Redux看起来更像是啰嗦的代名词。开发人员抱怨Mobx把React变成了Angular，就由于它使用了双向绑定——能够参见以前讲到的第一点。彷佛不少聪明人只是让他们的代码看起来更纯净，可是并无完成更多的事情（不过若是你没有截止期限或许问题不大）。

过分的工具绑定

React有点乱糟糟的。若是离开了一大堆npm包和ES5编译器，要作出React应用简直是步履维艰。基于React官方基础包开发的一个简单应用在node_modules目录下包含了大约75MB的JS代码。

这不算什么大问题，它更像是JS世界的事情，不过使用React仍然只会增长咱们的挫折感。

当前状态

v15.5.4 April 11, 2017

Facebook正在以流行的JavaScript框架React为基础开发一个全新的架构。这个名为React Fiber的全新设计改变了检测变动的方法和时机，借此可改进浏览器端和其余渲染设备的响应速度。这一全新架构最初已于2016年7月公开发布，其中蕴含着过去多年来Facebook不断改进的工做成果。该架构可向后兼容，完全重写了React的协调（Reconciliation）算法。该过程可用于肯定出现变动的具体时间，并将变动传递给渲染器。

AngularJS

在富应用开发中，跟Angular彻底没得比，在同等熟练条件下，Angular开发效率＝五倍React＝三倍backbone＝十倍jquery，然而虚拟dom并无什么乱用，二十一世纪，效率为王，Angular万岁，它表明了前端最早进的生产力，表明了前端先进文化的前进方向，表明了最广大前端的根本利益，然而一切抄袭angular造轮子的技术都将被历史的车轮碾压，粉身碎骨。

Angular很清晰的劣势

- Angular的Dependency Injection很丑，为了minify还要用array写两遍变量名

- Angular的module和es6 module兼容性很很差

- Scope chain只能让人越用越糊涂。Controller as也没改善太多

- Provider, Factory, Service实际上是同样的东西

- 目前的最佳实践是页面上全部东西都用Directive,强制组件化(那为啥不直接用React?)

- 侵入性太强，须要学不少Angular特有的语法，track by, transclude, $开头的全部变量，scope, promise. http 都必须使用它提供的

动态

Angular 团队宣布发布 4.0.0 版本，该版本可以向后兼容绝大部分 2.x.x 应用。在 4.0.0 中，带来的主要改变包括应用更小而且速度更快、更新了视图引擎，减小了将近 60% 的生成代码、而且引入了动画库做为预置的核心库的一部分等。更多参考:
https://angular.cn/blog/angular-400-now-available.html
https://hackernoon.com/top-8-resources-to-explore-angular-4-ff2c1b42020a?gi=151b442f3045#.3fgnc8ibr

Angular 2搭配React Native

Angular 2能够经过Angular Electron运行在桌面上，或者在微软的UWP上在移动设备端，Angular 2提供了一些选择项好比Ionic 2，NativeScript或者React Native。对于最后一个，有个库使得用React Native渲染Angular 2应用变得有可能。开发者能够调用全部React Native提供的API和polyfill来使用iOS和Android的原生功能，而后回调能够按需在Angular Zone中执行

React和Angular 2有不少共同点，他们在处理应用框架和数据上使用了类似的原理。另外一方面，每一个功能的实现都使用了不一样的方式（组件调用的生命周期仍是彻底一致的）。这些不一样点并不意味着应用开发时的难度，每种方案都提供了足够完善的工具来开发一个大型、严谨、灵活的应用核心。

固然React更小而且只涵盖view/component的操做–这是我这里要对比的。缺乏向html的扩展机制无疑是React惟一不足的地方。

Angular2则更加稳定、可扩展和更加完善。可是它仍然在beta阶段–而且相对对手具备优点由于不管相比angular1仍是React的经从来看它具备更加优秀的合并思想。

Vue.js

Vue.js是2016年发展最快的JS框架之一，并且我认为它的崛起并非由于粉丝的过分追捧，也不是由于某个大公司的权威推进。

Vue.js的优点

Vue.js在可读性、可维护性和趣味性之间作到了很好的平衡。Vue.js处在React和Angular 1之间，并且若是你有仔细看Vue的指南，就会发现Vue.js从其它框架借鉴了不少设计理念。Vue.js从React那里借鉴了组件化、prop、单向数据流、性能、虚拟渲染，并意识到状态管理的重要性。Vue.js从Angular那里借鉴了模板，并赋予了更好的语法，以及双向数据绑定（在单个组件里）。从咱们团队使用Vue.js的状况来看，Vue.js使用起来很简单。它不强制使用某种编译器，因此你彻底能够在遗留代码里使用Vue，并对以前乱糟糟的jQuery代码进行改造。

Vue.js能够很好地与HTML和JS一块儿协做。你能够开发出很是复杂的模板，而不会影响你对业务的专一，并且这些模板通常都具备很好的可读性。当模板膨胀到很大的时候，说明你在业务实现方面已经取得进展，这个时候你或许想把模板拆分红更小的组件。相比项目启动之初，此时你对应用的总体“映像”会有更好的把握。

这个跟在React里不太同样：Vue.js帮我节省了不少时间。在React里，在一开始就要把组件拆分红微组件和微函数，不然你会很容易迷失在乱糟糟的代码里。在React里，你须要花不少时间在一次又一次的整理prop和重构微组件（这些组件可能永远都不会被重用）上面，由于若是不这么作，在修改应用逻辑时就看不清方向。

在Vue里面使用表单是件垂手可得的事情。这个时候双向绑定就会派上用场。就算是在复杂的场景里也不会出现问题，不过watcher乍一看会让人想起Angular 1。在你拆分组件的时候，会常常用到单向数据流和回调传递。

若是你须要用到编译器的一些特性、lint、PostCSS和ES6，你会如愿以偿。在Vue.js 2里，Vue的扩展特性将会成为开发公共组件的默认方式。顺便提一下，开箱即用的组件CSS看起来是个好东西，它们能够减小对CSS层级命名和BEM的依赖。

Vue.js的核心具备简单有效的状态和prop管理机制，它的data()和props()方法在实际当中能够有效地工做。经过Vuex能够实现更好的关注点分离（它跟React里的Mobx有点相似，都包含了部分可变状态）。

大部分Vue.js场景都不须要Vuex提供的状态管理，不过多一个选择总不是坏事。

Vue.js的不足

1. 最大的一个问题：模板的运行时错误描述不够直观，这个跟Angular 1有点相似。Vue.js为JS代码提供了不少有用的警告信息，例如当你试图改变prop或不恰当地使用data()方法时，它会给出警告。这也是从React借鉴过来的比较好的方面。但对模板的运行时错误处理仍然是Vue的一个弱项，它的异常堆栈信息老是指向Vue.js的内部方法，不够直观。

2. 这个框架还很年轻，尚未稳定的社区组件。大部分组件是为Vue.js 1建立的，对于新手来讲有时候难以区分它们的版本。不过你能够在不使用其它第三方库的前提下在Vue里面完成不少事情，你可能须要一些ajax库（若是你不关心同构应用，能够考虑vue-resource）或者vue-router，这在必定程度上平衡了Vue在组件方面存在的不足。

3. 社区软件包里的代码有不少中文注释，这一点也不奇怪，由于Vue.js在中国很流行（它的做者就是个中国人）。

4. Vue.js是由一我的维护的项目，这个也算不上大问题，不过仍是要考虑其它一些因素。尤雨溪是Vue的做者，他曾经在Google和Meteor工做，在那以后他建立了Vue。Laravel也曾经是一个单人项目，不事后来也很成功，但谁知道呢……

比较

5 BEST JAVASCRIPT FRAMEWORKS IN 2017

https://www.dunebook.com/5-best-javascript-frameworks-to-learn-in-2017/
https://da-14.com/blog/5-best-javascript-frameworks-2017

React vs Angular 2: Comparison Guide for Beginners

https://www.codementor.io/codementorteam/react-vs-angular-2-comparison-beginners-guide-lvz5710ha

Vue.js官方与其它框架的比较

http://cn.vuejs.org/v2/guide/comparison.html

· React： React与Angular & Ember 的不一样之处在于其有限的应用范围和空间占用。Angular & Ember的定位是框架，而React主要是做为应用程序“视图”。React不包含依赖注入或“服务”支持，不须要“jq-lite”，也不依赖于jQuery。开发人员能够直接使用JSX编写标记，而无需Ember Handlebars 。React会维护一个“虚拟DOM”，并经过它更新真正的DOM，避免了没必要要的重排与重绘。总之，他很是喜欢React这种用途相对专注的特性。并且，React让他能够将复杂的应用程序切分红更小的组件。

· Falcor：这是一个由Netflix开源的、很是新的库。不一样于传统REST API，它只提供惟一的一个端点。有了它，开发者再也不须要向不一样的服务器端点请求不一样的数据，而是向同一个端点请求不一样的模型数据。服务器端能够识别请求参数，并由Falcor Router 调用恰当的router函数。也就是说，Falcor提供了一个更加直观的API，就是开发者的数据模型。这能够确保服务器永远不会返回没必要要的模型数据，节省了带宽。Falcor客户端还能够使用缓存数据为连续的请求提供服务，减小服务器响应时间。要了解更多关于Falcor的信息，能够查看Jafar Husain的视频。

· Webpack：做为一个模块绑定器，webpack能够为React组件模块化提供进一步的支持。它使开发者能够轻松压缩和链接CSS及JavaScript，并经过生成source map大大地简化调试工做。配置完成后，webpack会监控代码，每次代码发生变化，它就会生成新的bundles。客户端无需再导入大量的CSS或JS文件，而只须要导入bundles，减小了页面加载时的HTTP请求数。此外，webpack还提供了大量的插件，例如，使用jsx-loader 能够将JSX转换成JavaScript，使用babel-loader 能够将ES6代码转换成兼容ES5的代码。

· ES6： ECMAScript 2016，是JavaScript的最新规范，定义了若干重要的新特性，好比胖箭头函数、类、字符串插值、块做用域等。更多信息，请查看Mozilla Developer Network上的ECMAScript 6参考指南。

WEB开发不该该这么复杂

系统的设计团队受其生产系统的约束，而生产系统又是根据设计团队的沟通结构决定的。

----康威定律

康威定律说，软件产品的结构就是其创造团队的组织结构的镜像。

咱们正在使用的客户端渲染框架，来自于 Google 和 Facebook ，这两家公司有数千开发者，这些开发者隶属于数十个团队，组织结构就像这样 :

你的团队面临的问题，极可能跟 Google 和 Facebook 所面临的不同。使用那些客户端框架时，咱们是为了追逐性能，咱们作的每一个决定都是对的，可是放在一块儿看看结果，咱们得到了微小的性能提高，却在工程方面花费了惨重的代价。若是继续深刻这条路，这条路就会变得越窄。

开发WebSite

要说如今用React作网站设置繁琐吗？固然繁琐，要设置eslint，babel，webpack，用boilerplate最终仍是要了解各个不一样的东西是干吗的，不过把这些归罪React也不是太恰当，毕竟是整个前端生态圈都进化了。用Angular 2或者Ember你仍是得用到这些。React的繁琐基本都在redux上，得creatStore还得加入middleware还得用connect()链接到store，而带来的高阶组建的概念很差懂也不容易用。
React有它本身的缺点，毕竟咱们上哪找完美的东西呢？Boilerplate过多，setState是异步的，context api很坑爹，server side render各类坑(设置hmr，哪些call在服务器作，哪些只能在浏览器运行等等)，animation到如今都没什么太好的方案。

不过React值得用吗？固然值得，它给你组件化页面，入门函数式，清晰的单向数据流(dispatch(action)->reducer->render)，深刻了还有高阶组件的compensability，能发现selector和reducer其实也是compostable的，顺带着各个工具的使用(eslint, babel, webpack)，不当心还能入Elm和Clojurescript的坑。
还有一个常常被提起的好处是React redux作的网站，重构很是方便，在需求永远不固定的世界里也是一大优点。

关于React的问题，有几点要说：
一、React确实存在组件嵌套的性能问题，可是能够经过Redux去解耦以达到目的
二、对于引入immutable / reselect 对于大部分并非必需品，组件粒度越细，state使用得越少，须要引入shouldComponentUpdate的状况越少，其实在项目中真正有用到它们的有多少呢？
三、React的中大型项目上的应用并非太大的问题，国内有Ant.design已经在大量的蚂蚁金融平台和或各种内部平台上使用，尽管Vue也有，但只是实验版本，也并无再去升级。在国外：faceBook算大型应用吗？它自己已经就应用了React 16 Alpha 版本，以身试坑，这样算得上 React 在大型应用上有问题吗？
四、React是有门槛的，确实没有Mv**那么快让人容易接受，须要有必定的JS基础和开发经验。

先后端分离

咱们不适合先后端分离, 为何？由于

1. 又增长了一个中间层（固然程序员经过增长中间层来解决问题），好处是有，职责明确；可是也有坏处：人为地拉长了战线。对比图一和图三你就会发现，结构变复杂了，一我的能作的事情变成须要两我的作了。

2. 并无实质变化。之前的后端结构也是存在调用 Service 逻辑的，如今只不过换成让前端用 Node.js 作。除了把原本就吃紧的前端人力耗费在他不擅长的领域，我没看到什么提高。这里惟一的好处就是前端是势力范围扩大了。

认同的是「全栈工程师」。一个业务的先后为何要分给两我的写？以表单提交为例，后端要对数据作校验，前端也要作。为何要让两我的都写一次？前端说可让后端也写 Node.js ，这样就能够服用代码了呀。后端写了三年的 Java 你如今告诉他要所有重来？后端确定不肯意啊。矛盾就出在，分『后端』和『前端』两个职位上。大公司细分后端和前端，也是能够理解的。

说先后端分离的缺点：

1. 大部分站点，不该该分先后端。除非你的前端，很是很是很是复杂。可是大部分站点的前端，根本没有那么复杂！
2. 分了先后端很容易出现各自为政的状况。推诿、邀功、互相鄙视，不一一列举了。
3. 有人问一我的怎么又学后端又学前端？个人建议是把前端作薄，若是没有必要，不要搞什么 Angular 、 React 。用原生 JS 或者 jQuery 能知足大部分网站。同时后端向 Rails 学习。局部交互复杂的地方，采用动态加载来作交互。
4. 有人说你是前端的叛徒，你这么作前端还有什么前途。

其实真正主题是：先后端分离是前端不得志的必然结局。

难道先后端分离没有好处吗？
只有一个好处：好招聘。毕竟你要招一个优秀的全栈工程师是极其困难的。

思路

1. 保持前端简单，复杂了就用原生的方式封装，具体来讲就是用自定义标签来封装复杂组件。这样一来，后端同事仍是能够开发页面，由于只是多了一个自定义标签而已，本质仍是 HTML
2. 尽可能不要在开发状态加 watcher ，目的也是让后端能够直接上手，不须要了解那么多工具。转译放到 Web 框架的开发者模式里面作，看到 less 请求加转义成 CSS 不是什么难事也不复杂。
3. 前端只是辅助（这里说的是大可能是网站，不包括重型 Web 应用），前端要作好服务化：健全的文档、友好的接口。
4. 前端也要学后端知识，别在那自嗨。
5. 小公司别搞先后端分离，徒增复杂度！

单元测试

先后端分离后,意味着更多的业务逻辑将融入到前端程序中, 对应的咱们须要前端工程师须要完成对应业务逻辑的单元测试, 以确保前端质量不会逐渐沦陷.

基于 JavaScript 的单元测试被证实是一种高效的测试方法，其中 71％的组织执行了 JavaScript 单元测试，而 84％的组织则相信它是有益的！
Jasmine 和 Mocha 是最流行的 JavaScript 单元测试框架，Jasmine 主要配合 AngularJS 进行单元测试，而 Mocha 则与 ReactJS 配合使用。

目前前端自动化单元测试社区状况:

Jasmine & Protractor (72.4%),

Jasmine & Karma (67.7%),

Jasmine & Jest (58.3%),

Karma & Protractor (58.6%).

服务端

组件化是咱们基础设施之一, 服务端(.net, java)也想作更多通用组件.但每每项目或产品研发周期紧, 在一些组织没有足够时间研发通用组件.

权衡

咱们更多的时候，更应该思考的是平衡和最优组合：

什么状况下应该后台渲染，什么状况下应该前台渲染。
什么状况下应该用html+css控制页面，什么状况下应该用js控制页面。

React.js里所谓的“页面组件”，并非指一个checkbox，或一个input这样细粒度的组件，能够理解为对一个“功能单一的一个页面区域”的封装，粒度更大。虽然checkbox等也须要封装住成组件，但那是粒度更细Controls，和React.js的组件概念不是一个级别。单纯使用react而不搭配其余类库是做死真的还不如用jquery。

工程化的需求也比前些年提升的无数倍，去年我用grunt，后来用gulp，而后browserify来了，2016年用webpack，babel，工具的更换意味着开发体验也是愈来愈好。另外JSX不是HTML，JSX不是HTML，JSX不是HTML。

React知足上面的一些方面，不知足另外一些方面，和其余工具同样。你须要React，是由于两点

第一，你充分评估了你的项目，理解你要解决的问题是什么，是快速开发，性能，团队的ergonomics，多数状况下要解决的问题是多个要素的平衡

第二，你充分评估了React这个栈，理解它是解决你的具体问题的最佳工具，你真的理解了本身的场景中非用React不可的那些事情
只是一个营销类的推广页面，仅仅只有轮播、几个文本框的表单的极浅交互，我仍是推荐大伙使用原生 / zepto / jQuery之流。假如您很在乎体积，计较网络环境（2G/3G）等，能够使用服务器端渲染或者无阻塞UI（即添加占位符），使用带有GZIP的CDN，React各种库绝对可以在100K之内，假如超过，建议您使用按需加载。我相信您的服务器应该会添加有304/ETAG之类的缓存。

对于中大型项目，React确实是优良之选，固然也能够尝试Vue去迭代中小型项目。flux/reflux/redux 不只仅只能用在React，也能用在Vue/Angular等等框架，仅仅只是一个数据流思想，您选择性地使用。

对于大型项目，推荐 Webpack 来构建业务代码， Rollup 来打包你的小轮子。使用Rx优化你的数据流。Typescript强健你的代码，提高你的开发效率（头一周可能会有些痛苦）。但在此以后的收益是很是高的。对于中小型项目，推荐React/Redux/React-Router来构建你的代码

总结

   由于没有完美的框架，只有适合的应用场景，选择咱们本身更适合的。
      框架都只是为了开发效率和良好地组织项目代码，并不彻底是为性能而生。注意IT时代在变, 任何技术都会演进, 凡是存在的, 都是合理的。
       服务端研发工程师也少有全栈工程师。React.js适合长期, 用户体验高的交互多的项目或信息系统产品。

------------------------------------------------------------------------------------------------------------

原文做者：Petter Liu

原文出处：http://www.cnblogs.com/wintersun/