前端的发展

[lixiangwei]

前端起步比客户端软件和后端要晚，但是随着浏览器，HTML，JavaScript，css的不断发展和加速更新，也在不断推陈出新。大的方向是不断提高前端的生产效率，也就是提高代码的复用和降低代码的变更成本，在这里记录一下自己的理解。

刀耕火种时期：

最早期的时候，基本上前端负责拆图，做好静态页面之后，让后端脚本来填充数据，比方说jsp，asp等等，然后输出到客户端。受限于浏览器功能，网速慢等，前端的地位和能做的事情其实挺少的，给页面加点小弹窗之类的。江湖人称拆图仔。

刚来到这家公司的时候类似这样，老的页面代码有jsp和asp，脚本样式有许多是和后台模板混写在一起，直接写在jsp页面上，有许多重复的代码，变更成本高，可读性不太好。

jQuery时代：

jQuery出来以后，他使用css去选择DOM，链式操作的方式，解决了当时让人头痛的浏览器兼容性问题，用起来也简单，就火了。基本上许多也是是由jQuery带着一堆插件跑起来，这个时候前端的交互也开始丰富了一些，毕竟浏览器也在升级。

后来我在公司逐步去分离模板，样式，脚本。按照页面或者类似的业务功能分类。例如登陆注册脚本集中到一起。报表的样式集中到一个CSS文件中。但是我想如果随着公司业务不断发展，页面增长，前端数据和交互也更多更复杂的时候，css和js的文件数量也越来越多。会出现相应的问题：

• 一进页面就要加载好多的插件，有许多功能用户可能至始至终都没用上
• 代码冗余。例如需要用到某个函数，这个函数在某个js文件中，那么久需要加载整个文件进来，css样式也有同样的情况
• 资源依赖关系问题。html，css，js，图片数量还少的时候，对应关系维护起来还行，但数量上去之后就容易出错了。例如改一个地方导致其他地方也跟着报错。这个时候有文档记录这些以来关系，但毕竟还是用人力去维护
• 多人协作，代码冲突问题

随着JavaScript原生选择器的升级，现代浏览器兼容性问题改善，jQuery渐渐退出舞台

模块化：

JS/CSS模块化开发(AMD/CMD/CommonJS; LESS/SASS)的出现，意味着前端可以向更大规模的开发走进了一步。

这个时候有调研过JS/CSS模块化开发(AMD/CMD/CommonJS; LESS/SASS)，将一个大文件切割成若干小模块，分开来开发维护。有点像从中央集权走向分治的意思。requirejs也解决了一进页面就加载一堆资源的问题，实现异步加载同时管理好依赖关系。但同样会问题，随着一个应用的不断发展，那么需要用到模块就会越来越多，那么调用的模块队列就越长，当后面需要在模块引用队列插入新的模块，或者需要对现有模块进行修改的时候，就容易出问题了。而且还有图片，字体之类的资源没有模块化进去。不同类型的资源之间的依赖问题也没有很好解决

我有写过一个简单的脚本在公司用，功能是在需要的时候动态的生成脚本和css标签，加载对应资源，灵感是在看了seajs源码之后得到的，好处是不用去重写现有脚本。
https://github.com/lixiangwei/include

随着JavaScript新的模块标准出来，SeaJS和RequireJS渐渐退出舞台

前端框架时代来临

随着浏览器不断更新换代，前端复杂度不断提高，并且对于一些大厂来说，要提高前端的生产效率，协调那么多人共同开发。需要向后端客户端借鉴经验，例如应用结构MVC分层，所以backbone前端框架走上历史舞台。前面提到的应用的结构我的理解是首先要分层，例如视图层，业务逻辑层，数据交互层，然后每一个层面里面再细分不同的独立组件。就像电脑的文件夹我喜欢分门别类的存放文件

另外也出现像underscore这样的库，我的理解是补JavaScript的API，因为他自身API少，更新也慢。

我记得以前看淘宝的console招聘，要求熟练使用backbone和underscore，说明大型复杂的前端，是需要框架才行了，跟后端客户端发展好像挺类似的

随着JavaScript更新，Array和Object上面一些新特性的出现，underscore和lodash的作用渐渐减弱

SPA单页应用：

再后来人们开始追求在web上也能拥有软件般的极致体验，做成单页应用，也涌现出许多代表例如angular，react，Vue等等。和传统的页面不同，单页给我的感觉是js主导控制的。前端在这个时候有了更高的控制权。Angularjs击败Backbone和Knockout的原因，也是因为它的开发效率。无论是Backbone，还是Knockout，他们的数据模型都需要层层包裹，更新数据不能使用原生方法，而是必须使用包装过的方法。

这里考虑的是SPA组件化开发。把一个页面按照不同的功能划分为组件，例如导航栏划为一个组件，开发的时候把对应的html模板，脚本，样式放在一起，当页面需要用的时候，再把这个组将装到页面上去。对于复杂单页应用，有复杂的数据，业务逻辑和交互，使用组件化是好的，但传统展示型页面，就没必要了

组件化值得注意的地方：

• 页面和组件之间的通信，组件之间的通信使用生命周期事件来进行(WebComponents、React的选择)。也就是组件的每个时期，触发相应的事件。例如组件初始化的时候，触发初始化事件，让开发者知道。
• 前面经历了html-css-javscript分离的环节，这里又混回去了，所以在angular,React里面能看"很丑"的代码。但这种合一的做法已经没有了上面的各种问题。
• 通过webpack可以把js，css，png(base64)，html 所有资源都能合成一个JS文件，需要用到这个组件的时候，require这个组件的一个脚本进去就行了，他的打包功能很大程度解决了资源依赖的问题。webpack的模块化不仅仅局限于脚本，还包括样式图片字体等等所有资源，而且grunt之类的自动化工具在webpack上也有对应的插件，所以许多新的项目package.json里面script写满了命令行。

其他趋势

• 一些专注于做shim或者polyfill的库反倒会比较流行，因为它们的定位非常明确，就是辅助一程，将来浏览器支持就撤了
• 专注特定领域的，比如数据可视化，echart这种

参考资料
fouber/blog#10