我了解的前端史

同事邀我写一篇前端技术发展史，用于新员工培训。

在查资料写正式文档以前，我要先写下本身的所知所感，以避免到时分不清 什么东西是本身的、什么东西是别人的。

---

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 兼容性问题它全包了。

思路是这样的：

1. 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
     }

2. 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 编译，转成浏览器支持的代码。

---

咱们说框架提升了开发效率，其实有两层含义：

1. 框架提供了成熟的解决方案，如 组件、路由……少许代码就能完成复杂的功能。
2. 框架限制了开发的自由度，让往后维护和开发新功能变得容易。

我再从 限制开发自由度 这个角度说说框架的变化。

早些年前端流行 MVC 框架。

从代码职责层面，什么文件干什么活 确实很清楚。
但 MVC 使用事件驱动，事件太灵活。

茴香豆的“茴”有四种写法：

View 派发一个事件，可能性有千万种：

• 可能 Controller 在监听，
• 可能父元素在监听，
• 可能兄弟元素在监听，
• 可能多个地方同时在监听，而且监听器执行顺序还有讲究，
• ……

这么大的灵活性，你敢预判别人的代码思路吗？
这时候单步调试成了最稳妥、最“高效”的方法。

近些年 React 等框架限制就严格得多：
数据流单项传递，只能父到子。

一些场景下 代码实现比事件驱动麻烦，但好处是 你们的代码长得更像了。