同事邀我写一篇前端技术发展史，用于新员工培训。
在查资料写正式文档之前，我要先写下自己的所知所感，以免到时分不清 什么东西是自己的、什么东西是别人的。
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 兼容性问题了。
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 编译，转成浏览器支持的代码。
我们说框架提高了开发效率，其实有两层含义：
我再从 限制开发自由度 这个角度说说框架的变化。
早些年前端流行 mvc 框架。
从代码职责层面，什么文件干什么活 确实很清楚。
但 mvc 使用事件驱动，事件太灵活。
茴香豆的“茴”有四种写法：
view 派发一个事件，可能性有千万种：
controller 在监听，这么大的灵活性，你敢预判别人的代码思路吗？
这时候单步调试成了最稳妥、最“高效”的方法。
近些年 react 等框架限制就严格得多：
数据流单项传递，只能父到子。
一些场景下 代码实现比事件驱动麻烦，但好处是 大家的代码长得更像了。
如对本文有疑问， 点击进行留言回复！！
javascript从入门到跑路-----小文的js学习笔记（19）------- js的垃圾回收机制
Agora 开源 | 一个 Demo，帮你快速实现社交直播四大场景
网友评论