DOM API、MVC、MVP、MVVM、Virtual DOM、MNV* 逐步解决开发效率、设计模式、DOM交互性能问题

Web Component、Service Worker、IndexDB、WebAssembly、WebRTC、EcmaScript 6+(Promise/Generator/Class/Module

工程化时 Module & Module Loader


jQuery/Prototype/Dojo 互相吸收优点

chrome V8

nodejs,web标准向h5、ECMAScript 5靠拢


ExtJS/Dojo > 企业级框架 组件化概念

IE 9

Safari 支持众多 HTML5 内容:Canvas/Video/Audio/Geolocation/Storage/Application Cache/Web SQL Database 等


h5游戏


移动端框架,如 Sencha Touch/Zepto.js/JQ Mobile

多终端适配,多分辨率适配,远程调试

Twitter Bootstrap

CoffeeScript/TypeScript

前端工程化上,派系相互争斗,AMD、CMD、UMD 等规范,衍生SeaJS、RequireJS 等模块化工具。很有跳跃感


Web Components WebDriver ECMAScript 6 草案落地

Chrome 支持 SPDY,Blink 取代 webkit,DevTools 体验大幅度提升

LESS、SASS 、Stylus 等 CSS 预处理语言开始走俏,Web 开发变得更加紧凑

各大公司 Native 方向的研究,出现了 Hybrid 和 PhoneGap 的繁荣

Node.js 出现 Express、Meteor

PhantomJS 开始取代 Selenium,出现众多远程调试方案和工具


ES6 Module/Class 等特性语言具备了开发大型应用的能力

Mobile 要求极致体验,MV* 库铺卷而来, vue/angular/knockout 等


React Native

用 React 抽象操作系统原生的 UI 组件,代替 DOM 元素来渲染等

淘宝 Weex 吸收了 vue.js 编程精华,编程风格更加简约

构建从grunt 和 browserify 后,gulp 顺势而至,尔后又出现了 webpack、jspm 等

包管理经历了 components、bower、spm 后,npm 开始主导整个市场

Web 规范和标准

最开始JavaScript 还只是一个简单的脚本语言,配合着 AJAX,在网页上翻腾了好几个年头

互联网业复杂度不断增加,如Gmail,交互复杂,体验优良

复杂业务经常一层层回调嵌套可读性很差,多个异步并行处理很难

为改变这种编程范式,使用事件监听,各种手段拉直回调,平坦地调用

被认可、广泛重复定义的东西,都被纳入了标准

prototype对语言本身的拓展,对 js各种类型做拓展,并且提供了一套拓展任何对象的功能集

jQuery主要做浏览器兼容,让开发者不再把精力放到浏览器的差异上

ES6 普及前,不需要加入 jQuery/prototype 这些「不纯粹」的东西,而是添加两个 shim 和 polyfill(es5-shim,html5shiv等)。待到山花烂漫时,再轻松删掉这些补丁程序

nodejs ,面对巨量的异步,忍气吞声写了无数的回调地狱,尽管使用了很多 Promise 相关的操作,程序结构依然松散难以阅读,于是规范中也开始出现了 async/await 等对 Generator 的上层封装

只要规范出来了,后续市面上就会根据规范来实现一套 shiv,提供同样的 API,同样的编程体验

浏览器自我进化完成之后,这些 shiv 也将成为历史,被开发者遗弃在代码的注释之中

规范和标准的魅力,它的存在,让开发者把精力投入业务,编程和范式的工作交给它

一个东西在社区中被暴力追捧的时候,会有很多衍生的产品出来,衍生物根深蒂固时,可能又会出现一个更加原生更加符合开发习惯的东西出来

jQuery,我们为它编写的插件不计其数,而在工程化的需求冲击下,它却显得那么的弱不禁风,因为它关注的点和当前的发展态势不太吻合,仅此而已

面对庞大的移动用户,我们的技术是否做好了充足的准备 PC 上那一套经验不是直接搬到移动端就可以使用了,在移动端还需要解决更多的问题:

  • 多分辨率问题,涉及响应式设计和技术
  • 不同网络环境的网页加载优化问题,2g/3g/4g/wifi
  • 手指交互带来的一系列体验问题
  • 为了提升用户体验,将 Web Native 化 —— 类 React 技术带来的一系列问题
  • 远程调试问题
  • 移动安全问题等等

端的融合

不同分辨率的手机,不同物理尺寸的终端 通过前端技术重塑屏幕,重新定义像素尺寸,使用流式布局,通过百分比来响应不同的终端尺寸

栈的融合

「全栈」,Web 技术栈往小里说,包含了从前端设计、交互、前端实现、网络数据传输、后端实现、后端运维和数据库等几个方面,能短时间内从无到有实现这么一套系统,并且能够抗得住一定流量冲击的人,可以称之为全栈工程师

能够有架构有条理地实现这套系统,并且抗得住大流量、有集成测试、有监控的,可以称之为资深全栈工程师。现在不乏这种人才,也不乏自吹为这种人

栈的融合得益于 Node.js,作为前后端分离的桥梁,拉近前后端工程师的距离,有的人在这座桥梁上卖力行走,渐渐的也从前端走进了后端,甚至走进了后端的运维。至此,前端也拥有了部署和发布整个应用的能力,这是一个质的突破

NodeJS 几行便能实现 web 服务器、搭建一个多人聊天的网页,便捷性可见一斑

NPM 社区的发展,沉淀了成千上万的组件包,一行命令即可获取,组件拼凑式的开发,任何功能的实现都不会显得太复杂,而这里的「不复杂」也蕴含了无数的坑坑洼洼,在这一层的融合上也会遇上不少阻碍

  • 冗余的庞大的包内容,为了使用一个小功能,从网络上拉取下来一个巨大的包,而且这里的「巨大」对很多人来说都是无感知的,很少会有人进入 node_modules 去查看依赖的第三方包是如何实现的,实际情况可能会相当震撼,第三方包还引用了一堆第三方包,都会在 Node.js 执行的时候被收纳进去,放在内存中
  • 猛烈的迭代,Node.js > io.js 分分合合。虽说上层 API 几乎没有变化,但是底层却被翻了一个天
  • 偶尔的巨大漏洞,每隔一端时间就会暴露 Node.js 存在漏洞,这些漏洞的补救措施就是立即升级版本号,比较让人担心受怕
  • 后端意识不强烈,前端占领了中间层的开发,有的时候还干这后端的活儿,然而却没有后端沉淀多年固有的意识,测试和监控做的相当潦草

Js 从客户端的脚本语言纵身跃进进入了后端行列,而今也开始深入到移动端 Native 领域,确实是无孔不入,这可能就是语言的特性,也可能是技术本身就在寻求融合点,把有差异的地方全部躺平,然后用统一的方式去关注业务,关注用户。端和栈也在融合

后端服务化,云数据,云安全

用户体验变得越来越重要,响应式技术的发展也是后续网页应用的一大特点,端和端之间的差异只是在表现上,数据这一层差异不是特别大,很多应用 PC 和 Mobile 共用一套接口,或者 Mobile 的接口在 PC 接口的基础上做了一层包装,对接口字段做了些许删减

后端为了响应各个端之间的数据需求,也需要关注数据的可利用性,接口包装的拓展性等,这是后端服务化的一个表现

移动端的开发上,前后端间隙十分明显,越来越多移动端应用的发布已经脱离了后端,前端完全通过异步方式获取数据

业务变化很快很快快,今天这个产品被并购,明天那个业务被砍掉,每个人负责的业务线可能冷不丁地就变了。很多大公司的决策是由上往下的,上面微动,下面可能就是大动,可能某个部门就不存在了,也可能被划分成几个产品部门。「大后台,小前台」的趋势必然形成

前端灵活,多变,可快速重组

后台为响应前台的变化,需要提供更细粒化的 API,将数据打散,打得更加零碎,易于重组,考验后端的架构能力

如今,很多前端也都是半栈工程师,盘踞在前后端中间层上,然而如何迎接这种后端服务化的模式,似乎这个准备还是不够充足的

GraphQL 的出现场景跟 React 类似,React 是前端应对不同场景的一种强有力手段,而 GraphQL 则是后端应对不同需求场景的一次尝试,Web APIs 将会成为 Web App 和 Mobile App 的一个中心点,前端基于后端的 RESTful 服务构建应用,这里面存在太多未知的问题需要探索,这是一个大数据下探索的新起点,也给前端开发者创造了无数的可能

各类网盘,云服务商都在抢占市场,提供图片储存、CDN、大文件储存,也有卖数据库服务的。种类繁多,归根到底都是你付钱给我,我提供储存和安全,还提供方便的 SDK 让你获取自己的数据

云服务卖的是一套服务,它是把所有人的数据风险集于一身,用强硬的技术做安全防御。云,赋予了我们无穷的想象空间

三辆马车,我们还差一辆

程序开发三板斧:功能、测试和监控

开发功能对很多人来说是轻松活儿,基本的前端语言加些复杂的特效,实现成本不会很高;即便是搭建一个网站,使用 Node.js 社区中的框架也能够轻松实现。然后极少人会去关注每个功能点的测试,一个项目下来基本看不到测试用例,更不用说会去做监控相关的事情。结果就是,踏过了无数的坑洼之后终于上线了,而后续加功能的时候发现,加了东西就跑不通,新内容影响了之前的逻辑,只好去修复之前的逻辑,修好之后发现更早之前的逻辑又不通了,整个修复过程就像玩多米诺骨牌。

github 上可以看到很多程序都加入了持续集成,意味着程序也越来越健壮,至少贡献给世人使用的程序是健壮的。很多程序的代码覆盖率也达到了 90%+,这些数据都是重视测试的证据

最后一辆依然没有开动起来。很多公司都会有自己的 log 平台,每个用户访问页面中的任何一个链接都会将用户信息和访问信息收集到 log 平台上,通过监控平台或者离线分析的方式,获取业务数据或者技术数据,进行分析和二次开发

而这方面的东西在前端,尤其是使用 Node.js 做程序开发的前端身上,看到的并不多

最后

很多人已经被新技术冲击得有些找不着方向了,同一类东西,前者还没学完,后者就开始火爆了,紧接着又是一阵技术的凋零和新技术的出现,这样搞久了也会有一丝的疲倦

更多的会关注,如何更好地服务多端,如何更大幅度地提升开发体验和用户体验,很多技术都会往性能、往极致这个方向上钻研


过时,并不是指它现在就不能用了,而是说出现了明显更加先进的理念或者标准,导致未来它的使用场景大为减少,整体趋势已经步入衰落

随着Web相关标准的推进,很多框架(库)都过时了:

JavaScript新的模块标准 > SeaJS和RequireJS 过时

原生选择器的良好支持, > jQuery 不再那么依赖

Array和Object 新特性 > underscore和lodash 作用减弱

一些专注于做shim或者polyfill的库反倒会比较时髦,定位非常明确:扶上马,送一程

一代人做一代人的事情。上一代前端框架/库都已经基本完成使命了,让我们默默记住并怀念它们

过时、衰落,都代表着下降趋势,而不是说你现在就不能用了,仍然会有合适的场景,比如要支持ie6之类,在你的场景没有与时俱进之前,技术选型也是不能与时俱进的

RequireJS ,Sea.js,CommonJS、AMD 、CMD 在当年的产生和流行,都不是为了推框架,目的都是为了模块化开发

ES6 规范出,JS 模块已经得到标准化,早先的模块化方案的没落,和 webpack 与 babel 等转换工具的火爆,都是大势所趋