闲扯前端

[yleo77]

概述

今天，前端的重要性是不容置疑的。但是这个职位的重要性，在十多年前，却并不如今天这般肩负产品成败的使命，甚至不存在这样的分工。这篇文章简要回顾了这十多年的前端变迁，以及今天的web开发前端为什么愈来愈重要。此外，也会当前非常流行的四大前端框架做一简单对比，帮助我们更好得针对未来项目做出更合适的技术选型。

前端演进

谈到前端的发展及重要性的，不可脱离三大因素：

• 互联网对人们生活影响力的不断深入。
• 硬件性能的提升，接入设备的改变。
• 浏览器厂商的日益俱进。

二和三可能做技术的人们都会有所了解，为什么第一点互联网对人们生活影响力的不断深入 也会影响前端 的发展？这里谈谈我的理解，互联网在不断入侵及深入普通人的生活所带来的情况是，从技术的角度来看这个问题是，用户体验的地位在不断被强调，产品的易用性愈来愈重要（尤其是在同类型产品的竞争中），界面的简洁，美观，交互是否能够对用户产生持续性吸引，再具体一些，产品性能表现如何，页面在用户交互的感官体验中是否良好，能够带给用户轻松愉悦的使用感受，等等，这些都交叉性得指向了一个技术岗位： 前端。

被忽视的时代

大约在90年代至2000年初的时间轴里，可以称为早期的web开发，是不分前后端的，HTML 片段大多由 Server 端生成，直接渲染到浏览中，甚至包括了表现，就是 table 满天飞的那个年代。Javascript 在其中也只是充当了玩具的角色，充其量做个表单校验，“这个脚本语言还能干点什么呢？估计也就这点用途吧”。这是那个时代开发者对 Javascript 的印象。整个 web 开发可能也没有应用起 MVC 的模式来。

这样的好处是什么呢？试想在那个年代，浏览器所呈现的页面绝大多数是一个简单的页面，文本/图片可能是呈现最多的媒介，也不存在太过复杂的页面交互，在这样的项目背景下，后端自然也是可以充当一定的前端开发任务。少量的大型 web 项目，前端也并没有太多的开发量。

坏处呢，当新的时代来临，项目日益复杂的情况下，项目难以维护，甚至难以正常开发出来。

团队成员的配置上，也没有前端后端的分工，因为不需要。

这是互联网 web 初期的一个缩影。

逐渐被独立出来的年代

当我们谈论用户体验的时候，我们在讲什么。这是绕不过去的一个点：前端。

当 Amazon 绞尽脑汁想如何提高网站交易量的时候，他们发现网站每慢100ms，将导致收入下降1%。

...

当 Google 的 Gmail 上线的时候，人们惊呆了，Javascript 原来可以这么酷。

回头看国内，淘宝的崛起，始终有一个团队功不可没，UED。

前端渐渐浮出水面，于此同时伴随着的是，前后端分离的开发理念，web开发中的MVC最佳实践。后端掌控着 Mmodel，Controller。前端在 View 的领域里深耕，代码的可维护性明显得到了质的提升。后端只需要处理好 逻辑 相关就可以了，再也不用管美观，易用等产品可用，易用性方面的问题了。而这些恰恰是一个合格的前端应该具备的素养，大的方面来看：

• 产品：交互，心理学。
• 编程思维：javascript 编程
• 美学： CSS 样式

（不止于此，我想的肯定没有概括全。）

有时候我讲，前端还应该至少是半个产品（保证和产品的沟通，和产品协商如何让产品更好用），半个后端（知道哪些东西后端做合理，哪些应该放在前端），还有对美，对细节的追求（更是必不可少，否则还是去做后端吧）。

这个时代的前端开发人员，大多是备受摧残的一代，虽然 IE6 已经有了数年的历史，但依然稳坐浏览器份额的半壁江山，尤其是在国内，面对无数个 IE 系的坑，前端开发人员是有苦也得硬撑着，也开始了一些工程化方面的积累。

HTML5，CSS3，ES2015还没有到来，前端在隐忍着，有的时候，前端也会自我调侃，“我们是页面仔。”

肩负重任的时代

当 Ryan Dahl 创造出独门武功 Node.js 然后隐退江湖的时候，不知道他是否能想到今天 Node.js 的发展。

当HTML5，CSS3，ECMA2015 被支持越来越好，越来越好的时候。

当 V8 的开发团队为了挑战 Javascript 引擎执行效率而剑走偏锋跳过了字节码生成直接从抽象语法树生成本地代码的时候，Safari 也在不断为 squirrelFish 注入多层优化机制来提升 Javascript 的时候。

当移动端开发大潮来临的时候。

当 Javascript 被应用在硬件开发的时代来临的时候。

等等。

前端工程师觉得他们的舞台，越来越大了。这个时候的前端工程师，也应该是面临着自身技术栈的转型阶段，从之前的需要懂点jQuery，CSS 各种 Hack，浏览器兼容性，YUI，Extjs，文件combo，代码压缩混淆，无模式过渡到 ES5，Backbone，Knockout，LESS，SASS，Spine，Grunt，Gulp，RequireJS，AMD，依赖管理到现在的 React，Angular，Vue，响应式，数据可视化，自动化测试，新的调试方式，SPA，离线， Postcss，cssnext， JSX， Flow等。围绕着 Javascript/前端 的技术发展愈演愈烈，发展愈来愈快。举个栗子，Grunt 的兴起，到新贵 Gulp 的出现，再到 Browserify 进入人们的视野，今天的 webpack 俨然成为了新的宠儿，可能也就是一年一换代而已，他们都代表着在新的时间里，解决问题的更先进的生产力。

图示： 今年常见库/框架/工具

当然了，今天的前端需要了解的远远不止这些，从这一阶段初始的大前端到 Node.js 带来的全栈开发，业界一些团队也在跃跃欲试。React Native 的开源也让前端插足本应该是 Native 的领域。MVVM 的模式重新刷新了前端开发人员的思维模式，还有 Flux 架构。Webpack 团队甚至还在考虑着将 HMR 投入到生产阶段。

前端已经不是一个小小的领域，越来越多的开发需要工程化方面的思考。项目也从最初的 web page 过渡到了 web app，前端承担的职责也越来越多，势必对架构提出了新的挑战。组件化，组件之间的通讯，全局事件模型，ES2015中的模块系统，不可变数据结构， JSX，数据在 app 中的流向，函数响应式编程在前端的应用。

有人说，前端社区的活跃是因为目前还比较混乱，都还在尝试摸索着最佳实践，试图寻找最适合前端这一特殊领域的开发，这让部分普通的开发者会觉得追这些技术很痛苦，或者质疑学习他们的收益。我倒不这么认为，前端社区的活跃加之Javascript语言的活跃也正是它吸引人的原因，这也是它本身复杂，独有魅力的地方，这也是多方面决定，其次变化同时也意味着可能性，意味着这个行业在成长，身处其中，环境也会促人成长，当然了，如果在这趟知识的漩涡中只停留在了皮毛，也没多大意义。

当下流行的四个框架对比

Angular

Angular 是 MV* 的，Google 推出的前端框架，核心是依赖注入，借助于该特性，可以非常自由得声明组件，在想使用的地方就像写 HTML 标签一样使用组件，正如官网给出的 slogon 一般： HTML enhanced for web apps!，从这一点来说，增强了 HTML 的自描述能力。举个栗子来说明这一特性。

<slider items="items"></slider>

That's it. 它在号称专注于未来 web app 开发的同时，也带来了大量新的概念思想，比如 Services，Directive，Scope，Model等，这些设计如同一把双刃剑，在吸引来部分开发者的同时，也让更多传统的前端开发者久久不能转变至此。

前不久，Google 也推出了 Angular 2 的 beta 版本，这一次，他们向其他几个框架库以及 web components 靠拢了一些，但依然保持了非常激进的血脉。强调了组件化这一大的趋势，同时在大幅度提升了 Angular 1 中被开发者抱怨多次的脏检查的性能问题。

React

这篇文章我意在提及四个具有代表性的框架，而 React 是我主观最喜欢的，我甚至一度认为究其原因，想来应该是 React 背后团队对 React 的野心所向：当 React 在 0.14 版本中将 react-dom API 从核心库中剥离开来的时候，便似乎看到了这个团队的高瞻远瞩，他们想要统一界面编程。换句话说，只要涉及 UI 的编程实践，都可以通过 React 来实现，比如常见的 web，以及深入到移动端 iOS，Android的实现，这可不是简单的 Webview，而是让前端开发者借助于 React 来开发 Native 应用，想想这是多么兴奋且有挑战的一件事，从商业的角度来看，如果在 React 这条技术栈能够胜任产品需求的情况下，如果公司能够拥有一个精通 React 的团队，那这个团队便是可以同时胜任 Web + iOS + Android 端的 开发任务， 很棒，是吧。

图示： React 和 Flux 模式架构图。

此外，React 还有一些别的更被业界所熟知的特点：

1. 虚拟 dom
2. 组件化
3. 函数式编程实践
4. Immutable data

还有常常与它结伴出现的 Webpack 工具，给开发者带来了创新性的调试特性：HMR。

如果对其中两点以上都感兴趣，那一定得亲自尝试下 React 为开发者带来的魅力，我坚信选择一条好的酷的技术栈能够增加开发者 coding 的愉悦感，肯定是这样。

Vue

Vue 是国人开发的一个非常具有国际范的开发框架，非常出色。单纯的性能对比，Vue 比 React 快10倍，React 比 Angular 快 10 倍（备注：10是一个概数，和场景有关，但借助于底层的实现方式，Vue 确实表现得足够让人爱不释手）。

图示：vue 和 vuex 数据流。

Vue 给我的感觉是又可爱又可口的感觉，不知道有没有别人注意到，Vue 的 API 设计非常非常得简约，能用单个单词表现的，决不用多个单词去表现，在 API 层面也保证了框架给人的整体印象，小巧可爱简约。可能很多人觉得这是无足轻重的事情，但我不这么认为，这恰恰是我喜欢 Vue 的一个原因，一个不可忽视的重要原因。想想很多年之前的 jQuery，它的 API 不也是这样的风格吗，在议论着YUI太过于理想国教条化的实现同时也在赞美着 jQuery 的精巧，使用简单，上手容易。

在最初，Vue 的设计是借鉴了 Angular 的一些 MVVM 的特点，比如双向绑定，但又没有 Angular 那么陡峭的学习曲线。可以说，扫一遍 Api 和官方文档，就可以开始开发了。

这次冰箱项目，本来是想使用 React + Redux 的技术栈的，但因为硬件 pad 性能表现实在太差的原因，所以最终采用了 Vue。我想如果没有外界原因，这一决定将会一直持续下去。

Ember

在提到了学习曲线，脑里突然蹦出了 Ember 这个怪兽，因为它的学习曲线算得是更陡峭，官方的开发团队甚至调侃称之为 Learning cliff 而不是 learning curve。之前在 ThoughtWorks 时有过一段短暂的使用 Ember 的经历，还谈不上自己充分掌握了 Ember ，只是觉得这是个巨无霸，迫不得已的情况下，我不会在自己和自己团队中的项目中主动青睐它，毕竟一个原因是核心文件动辄压缩后也几百K再加一个必须使用的 Ember-data也是几百 K 的大小；其次它比 Angular 还不稳定（现在稳定下来没还不太清楚）。

Ember 团队是这样宣称的，它为开发者做了更全面的事情，只要按照 Ember 框架的那一套哲学来，写出来的项目是可以做到应用结构清晰，易于维护，保证项目质量，正如用 Java 语言开发项目一般，一个良莠不一的开发团队也可以做出漂亮的项目。如果说之前是个 Rails 程序员的话，上手 Ember 估计会很快，因为它从 Rails 项目借鉴了一些优秀的理念。

择其所用

项目所需要权衡因素

为项目选择一个框架/库/工具永远不会是一个公平的事情，这里面涉及了方方面面的因素权衡：

• 项目角度
  • 项目开发周期，是否有 Buffer 时间。
  • 项目特点，SNS 型，单页型，一次访问型
  • 项目运行平台，PC？移动端？
  • 特定环境下还需要考虑项目运行的硬件，比如在极端恶劣的环境下。
  • 项目的预期 PV。超高的 PV 意味着流量，意味着框架的体积将会是一个重要因素。
  • 需要支持低版本 IE 浏览器嘛？呵呵哒。
• 框架角度（前提是满足需求）
  • 框架性能表现，往往权重不大，特殊情况下必须考虑。
  • 文档是否健全，文档不健全，通过看代码的方式使用框架？基本不现实。
  • API是否稳定，经常变的 API 谁受得了。
  • 是否一直处于完善，更新状态，长期维护版本更新意味着框架是鲜活的。
  • 社区是否活跃，风向标。
  • 框架的设计理念是否代表趋势
• 团队
  • 团队人员人数。
  • 各个成员接受新技术能力
• 其他
  • 用了该框架是否能比不用该框架对项目/成员有好的促进作用
• 决定者
  • 个人主观意愿

上面看起来因素很多，但每个因素可能都有一定的权重，或者在某些场景下权重会变更高。但在正常情况下，坦白得来讲，这其中个人主观应该是会占据了相对很大的比重，当然个人主观也可以理解为，决策者一定是是先行结合了以上各个因素，然后看似用主观的方式表达出自己的思考结果“咱们就用这个吧”，突然想起了《程序员的思维修炼》一书中关于对专家分析问题的内容。

对比四个框架

暂且不论项目方面的考虑，只谈论这些框架的异同。

正如 OSX，Windows和 Linux 之间，Android 和 iOS 之间他们在长期的演进过程中，不断提升自身优势，也不断得在吸取对方的优势，拿来己用，求同存异。

React 的虚拟 DOM 因为另辟蹊径解决了困扰前端界多年的渲染性能的难题，而赢得了超越了其他几个框架的好评，但之后 Ember 也借鉴了此引入了 Glimmer 模板渲染引擎，再到最近的 Vue 2.0 的版本更新，也宣布了引入一个轻量级类似的 Virtual-DOM 的实现，从这个角度来看，Facebook 团队也算是为前端界贡献了一个非常漂亮的 idea，Virtual-DOM 借此风生水起。

从另一个角度编程范式上来说，大家可能会感受到近几年来函数式编程的热度有所升温，原因是众多方面的，但我觉得这其中应该是有这些框架的推波助澜。React 将函数式编程带入到 UI 编程的世界里来，在它的设计哲学中，一个组件就是一个状态机，改变了组件的输入就可以得到不同的输出，这是相对应的，这不正是函数式编程的根本要领吗，想想又像大学时所学的电子电路。如果厌倦了命令式编程，对声明式抱有好感时，那很可能会因此对 Angular 的关注度有所上升，借助依赖注入，将复杂的逻辑隐藏起来，专注于干什么，让 HTML 更具有语义化。

那么 Vue 呢，最初它从 Angular 处获得一些灵感，但因为厌倦它的庞大而诞生，所以 Vue 一开始注定是一个小巧的框架，也还是可以从 Vue 中看到一些 Angular 的影子，比如 directive，filter 等。最大的不同在于 Vue 从一开始就倡导组件化的，Component-oriented，视图是一棵组件树，页面应该像搭积木一般通过搭建组件而构成，恩，这是它和 React 非常相似的地方，也是 web components 的设计趋势。

因为底层的实现迥异，响应式编程在 Vue 也和和 React 中也是完全不同的实现原理，前者中，需要一个对象/数组是 mutable 的，当改变一个对象的属性时，只需要简单得给该属性赋值就可以通过对应的getter/setter触发与之相关联的 watchers，性能在这里基本不会有任何的损失。而 React 采用的是 immutable data的形式，当需要改变对象属性的时候，必须将该对象重新设置， 这样在之后重绘时只需要简单比较两次前后两个数据对象是否一致就可以了 this.props.data !== this.nextProps.data，而如果在 React 中采用 mutable 的 data，那必然会丢掉 React 高性能的一大优势。Angular 的 dirty checking 就不提起了。

Ember这个怪兽，还没有提及，其实他们都还有一些特性，比如计算属性，比如对 DOM 操作的批量异步更新，Vue 如此，React 中也有同类似的策略实现，在batchingStrategy 中。（这一点 Angular 中是否有实现，我目前还没有了解到。）

结语

前端以它独有的特性（混合了GUI编程及逻辑编程，同时编写三门语言）和 Javascript at everywhere （浏览器端，服务器端，还有目前正处于前期的硬件编程）都吸引了大批开发者，这是一个非常cool的岗位，我有幸经历了其中的第二阶段的末期到第三阶段。这篇文章是我对此的一个简要回顾及当前阶段几个框架的一个简要对比。其中每一个技术点都值得再花费大量的时间调研深入探索研究。

参考资料

• 解读2015之前端篇：工业时代 野蛮发展
• Web 研发模式演变