同事邀我写一篇前端技术发展史，用于新员工培训。
在查资料写正式文档之前，我想先写下自己的经历和感悟，以免到时分不清 什么东西是自己的、什么东西是别人的。
1995 年，网景公司希望给网页加一些交互性，花两周时间创造了 javascript，用来控制网页中的元素。
两周时间创造的语言一定精致不到哪去。
但巧妙的是，这门语言非常得开放灵活，开发者可以自己定制它。
例如：
给
String添加个首字母大写的方法：String.prototype.capitalize = function() { return ( this.charAt(0).toUpperCase() + this.slice(1) ); }; "hello".capitalize(); // Hello修改
Date toString方法：Date.prototype.toString = function() { return ( this.getFullYear() + "/" + (this.getMonth() + 1) + "/" + this.getDate() ); }; new Date().toString(); // 2019/12/21
因为这种开放性，javascript 吸收了大量开发者的智慧，变得越来越好。
这种策略对我很有启发。
一件事我自己搞不定，那可以把他变成大家的事，让集体智慧发挥作用。
道理简单，但难在放低姿态，保持开放的心态，能真正听进去意见。
吸收了开发者集体智慧后，javascript 标准【准确点是 ECMAScript 标准】发展得很快。
但碰到了一个问题：标准跑到了半山腰，浏览器们还在山脚下。
毕竟程序跑在浏览器上，标准再好，浏览器不支持 开发者也没法用。
甚至众多浏览器对标准的支持情况也不一样，不仅是 javascript，html 和 css 也一样。
一度招聘要求里都有一条“能解决浏览器兼容性问题”。
浏览器兼容性问题让开发者很头疼。“帮开发者解决浏览器兼容性问题”成了各框架的重点任务。
其中玩得比较过的是 ExtJS。
html、css、javascript 兼容性问题它全包了。
思路是这样的：
html、css：开发者不要写了，所以开发者不用关心这类兼容性问题了。
html、css 写法
<style> .submitBtn { font-size: 2em; padding: 10px; } </style> <button class="submitBtn">提交</button>ExtJS 写法
{ xtype: 'button', scale: 'large', padding: 10 }
javascript：开发者使用 ExtJS 的 api，而不用 ECMAScript 标准的 api。
例如拷贝 b 对象的属性到 a 对象上:ECMAScript 标准
Object.assign(a, b);ExtJS
Ext.apply(a, b);
ExtJS 彻底让开发者不用考虑浏览器兼容性问题，大幅提升了开发效率。
但代价是：
开发者和 html、css、javascript 标准被隔离开，
开发者像是在用一门新语言编程，被绑架在这个框架上。
再后来 babel 出现了，开发者终于可以拥抱最新 ECMAScript 标准了。
babel 的思路是这样：
开发者用最新 ECMAScript 标准去写代码，然后通过 babel 编译，转成浏览器支持的代码。
前面说了框架可以提升开发效率，其实框架还有一个更重要的作用：限制开发的自由度。
从 A 处到达 B 处，
如果不限制交通工具，那么每个人采用的方式就可能不一致，有人走，有人开车，有人坐飞机……
对应到开发：
- 框架自由度大，你就等着惊叹人类的创造力吧。
- 框架自由度小，你搞懂别人代码会更容易。
早些年前端流行 MVC 框架。
从代码职责层面，什么文件干什么活 确实很清楚。
但因为 MVC 使用事件驱动，事件太灵活。数据流到底怎么走，你预判不了，得看开发者当时的心情。
View 派发一个事件，可能是 Controller 在监听、可能是父元素在监听、还可能是兄弟元素在监听、还可能是多个地方同时在监听，甚至还和监听的顺序紧密相关。
多人协同开发，这种灵活性将是一个噩梦。
近些年 React 等框架限制就严格得多：数据流单项传递，只能父到子。
一些场景下 代码实现比事件驱动麻烦，但好处是 大家的代码长得更像了。
