文 大漠穷秋 2015-11-06
0x0000 第一大坑：浏览器兼容性
第一次浏览器大战
桌面端浏览器大战的硝烟尚未散尽，移动端纷争又起。大厂神仙打架，码农苦不堪言。各种CSS、JS不兼容，坑得码农尽白头。在兼容性这个问题上，M$的IE浏览器最是臭名昭著。
在各路神仙妖怪的持续吐槽之下，微软终于脸上挂不住了，最近宣布在Windows10上彻底抛弃IE这个品牌，强势推广全新的“斯巴达”浏览器。
http://www.expreview.com/39604.html
早期出现的各种“JS库”，例如远古的prototype、中古的mootools，到近代的jQuery，再到大规模、紧封装的YUI、Extjs，很大的一个目标就是为了填“兼容性”这个大坑。
0x0001 第二大坑：没有完善的开发、调试、测试、部署工具链
各种后端语言都有自己完善的IDE支持，有的还不止一种IDE，以Java开发为例，市面上常见的就有来自IBM的Eclipse、开源免费的NetBeans、以及来自JetBrains的IntelliJ这些。整个的开发、调试、测试全部在IDE环境里面完成，撸码过程还是相当酸爽的。
Eclipse的调试界面
相比之下，对于前端开发来说，在FireBug、chrome出现之前，前端调试基本上都是靠alert来支持。
还记得只能用alert来进行调试的那段岁月吗？
更加坑的是，整个前端的代码压缩、自动化测试、线上部署等等，根本没有神马特别好的工具支持。直到2009年，终于出现了NodeJS这个神器。
终于等到冤大头来填第二个巨坑了，好欣慰啊！
围绕着NodeJS，出现了大量的前端开发脚手架，例如用来编译CSS的LESS和SASS，用来压缩和混淆的grunt、gulp、webpack，用来把ES6编译成ES5的Babel等等。
grunt编译界面
因此，从3大坑的角度看，NodeJS的出现，标志着前端开发正式进入工业化时代，刀耕火种的日子一去不复返了！
你司是不是还在这么玩儿？
资本主义国家已经这么玩儿了
0x0002 第三大坑：JavaScript缺乏语言级的模块化和组件化机制
类之间的依赖关系以Java为例，各个类之间的依赖关系最终会形成以上这个“图”数据结构（有向有环）。
对于前端开发来说，各个业务模块之间的依赖关系同样会形成这样一副“图”。然而很可惜的是，JS这门语言本身并没有对模块化提供有力的支持。JS（ECMA5之前）并没有import机制，对于大规模的application来说，处理模块之间的依赖关系绝对无比蛋疼。直到出现了CMD和AMD这样的理论和思想，这种动态依赖加载的问题才有了比较好的解决方案。
RequireJS:用来填没有动态import机制的坑
目前市面上比较成熟一点的前端框架，都会实现自己的“模块化”机制。
RequireJS的模块化写起来是这样一种风格：
PS：这里不详细解释RequireJS的用法，如果你很感兴趣，请仔细阅读阮老师的系列文章《Javascript模块化编程》。
ExtJS的模块化是这样用的：
AngularJS的模块化是这样用的：
这里也不详细解释AngularJS的各种概念，对AngularJS有兴趣的，请仔细看我在慕课网发布的免费视频教程《AngularJS实战》。
无论是哪一个框架，模块化最底层的机制都是一样的：用JS脚本动态创建script标签，从而诱使浏览器动态加载一段内容（动态加载的内容可以是JS脚本，也可以是普通的字符串，也可以是CSS）。这种机制的核心代码示意如下：
以上代码摘自RequireJS
- 用JS脚本动态创建一个script节点；
- 绑定事件回调函数；
- 设置script节点的url属性并插入到head中，从而诱使浏览器加载指定url的内容；
在以上核心机制的基础上，可以附加一些更加高级的功能，比如RequireJS加上了缓存机制（以完整的url为key），避免多次加载相同的内容，同时还加上了依赖检测等功能。
0x0003 单独说说组件化
先来看两种典型的前端界面：
电商或者门户型的前端界面
后台管理型或者叫ERP衍生型的界面
对于门户和管理后台这两种截然不同的场景，对前端组件的潜在需求是不同的。
对于门户型界面来说，组件的数量会比较多，组件的外观比较灵活，但是每个组件的功能都比较简单。因此，腾讯的张鑫旭提出“半封装组件”的概念，比较适合用在门户、互联网这种业务场景下。
对于管理后台型的界面来说，情况恰好相反，组件的数量不多，整体布局和外观相对比较固定，但是每个组件的功能都非常复杂。因为管理后台型的系统实际上是一种变型的C/S结构，它更靠近application（应用）这种概念，而不是page（页面）。
有一些专门做管理系统（或者叫运营支撑系统）的企业，里面的设计师居然也出来炒作“半封装”的概念，很明显对公司的业务场景缺乏认识，对前端开发的大背景也缺乏感知。
典型的管理后台型系统会出现（或者说客户会要求）Tree、Grid这样的重量级组件：
后台管理型系统里面常见的Tree组件
后台管理系统里面常见的Grid组件这种重量组件的功能非常复杂，例如表格的列头需要能拖动，表格内部的单元格需要能动态编辑。因此，这种组件的代码量非常庞大，以大家最常用的一个基于jQuery的FlexGrid控件为例，光JS代码有两万多行。
再看几个典型的后台管理型的组件库：
KendoUI---大约60个组件
国产的MiniUI（基于jQuery）
ExtJS4.1，大约200个组件
ExtJS6.0，整体代码量已达23万行JS！
我司自研的某框架，整体代码量也已达5.5万行之多（不包含CSS）以上这些用来开发管理后台的组件库，组件的功能基本类似，整体数量都在200个左右。
由于门户和管理后台这两种场景对组件的功能和外观的要求完全不同，加上SEO、页面静态化、后端渲染等众多因素的影响，因此在做技术选型时要仔细考虑。比如，拿ExtJS或者Flex去做一个门户网站，或者拿AngularJS去做管理后台，都是典型的不理智行为。
用ExtJS开发门户网站就是这种效果
这些你都认识吗？它们基本上都是用来填第三个坑的总结：组件化只是整个前端开发过程中需要考虑的一部分，而不是全部。有一些人沉迷于“组件化”的思维无法自拔，忘记了3大坑的存在。对于管理后台型的系统，更多要考虑模块化、大规模团队协作等工程问题！
0x0004 这是乱入的一个小节：JS并不是一门面向对象的语言
大家都知道，“面向对象”的三大特征是：封装、继承和多态。而JS在语言层面上并没有提供有力的支持，因此，从这个角度说，JS并不是一门“面向对象”的语言。说到这儿，来看一下JS之父是怎么评价这门语言的，其中一段最经典的话是这么说的：
"与其说我爱Javascript，不如说我恨它。它是C语言和Self语言一夜情的产物。十八世纪英国文学家约翰逊博士说得好：'它的优秀之处并非原创，它的原创之处并不优秀。'（the part that is good is not original, and the part that is original is not good.）"
JavaScript之父：Brendan Eich关于JavaScript的更多趣闻轶事，请参见阮老师的博文《Javascript诞生记》。
JS（ECMA5之前）并没有语言级的class/extends/import机制。这对前端的“组件化”、MVC来说造成了巨大的障碍。因此，才出现了大量的库和框架来填这个坑。
由于没有语言级的class和extends，开发者不得不使用蛋疼无比的“原型继承”机制。最简化的一段实现代码看起来是这样的：
原型继承示意代码
以上是最简单的一种实现，没有考虑“静态方法”、“多级继承”等问题，各种框架在模拟实现extends机制上各有千秋，其中以ExtJS的实现最经典，基本上完全模拟出了类似Java里面extends的全部行为模式。
最近的一个好消息是，ECMA在2015年9月已经发布了ES6标准，其中已经加上了大家期待已久的class/extends/import这些机制，代码写起来是这么一种尿性：
关于ES6的完整特性介绍，请看阮老师的系列文章：《ECMAScript 6入门》
0xFFFFFF 终章
3大坑对前端开发的影响示意图（使用百度echarts制作）
解释几个关键的时间点：
- 2003年：以淘宝为首的电子商务企业开始出现，前端代码规模开始大膨胀，此时浏览器的兼容性是最大的问题；
- 2005年前后：Ajax兴起，WebApplication、WEB2.0等概念开始被疯狂炒作，前端代码规模进一步膨胀，继续完善的开发工具链，但是浏览器兼容性问题造成的影响开始降低；
- 2009年：NodeJS兴起，各种前端开发工具大爆发，由于ExtJS、Flex等框架的兴起，以及对WEBOS这个概念的炒作，前端组件化的呼声日益高涨；
总结：市面上绝大多数前端框架都是在填这3大坑，牛逼一点的同时填几个坑，例如ExtJS（大规模封装，提供各种开发工具）；规模小一点的只填其中一个坑，例如AngularJS（不管浏览器兼容性）、React（只做View层）。因此，站在3大坑的角度，你就获得了一个广阔的视角，无论出现什么新框架，都是在填坑而已！
网友评论