复杂的业务中会经常看到一层又一层的回调处理，回调的嵌套让代码的可读性变的很差，而且很难将多个异步并行处理。为了改变这种编程范式，我们做了很多的思考，使用事件监听，使用各种手段拉直回调，平坦地调用。
慢慢的，如果你在关注 W3C 小组的动向，会发现，那些被认可的，并且被广泛重复定义的东西，都被纳入了标准。最开始的 jQuery/prototype，前者主要是对浏览器做兼容处理，让开发者不再把精力放到浏览器的差异上；后者是对语言本身的拓展，对 JavaScript 各种类型做拓展，并且提供了一套拓展任何对象的功能集。而现在的开发，我们很大程度上不再依托这些类库。规范和标准已经把这些差异都统一了，String 中自带了 includes/startsWith/endsWith/repeat/padStart/padEnd 等函数，Array 自带了 from/forEach/of/keys/values/find/findIndex 函数…
规范的标准是为了让开发者得到更好的编程体验，编程不是目标，目标是将编程生产力转化成实际效益，越少的阻碍对开发者越有利。各浏览器厂商当然也认识到了这一点，他们不断地提升自己产品的体验，将标准中的新特性都融合进去，比如 ES6 中的 Promise/Generator/Class/Module 等等。在这些内容普及之前，我们不需要加入 jQuery/prototype 这些「不纯粹」的东西，而是添加两个 shim 和 polyfill，如 es5-shim，html5shiv 等等。待到山花烂漫时，再轻松删掉这些补丁程序。
这两年工程化很热，W3C 小组也看到了，这就是市场的需求，为了完成一个大型应用的编程，就必须模块化、组件化，于是在规范中也出现了 Module & Module Loader；Node.js 的到来，让很多前端工程师开始接触数据库操作，面对巨量的异步，我们忍气吞声写了无数的回调地狱，尽管使用了很多 Promise 相关的操作，程序结构依然松散难以阅读，于是规范中也开始出现了 async/await 等对 Generator 的上层封装。文字已经不能满足当代人的沟通需求，音视频等富媒体传输走进了我们的生活，于是规范中也出来了 WebRTC/WebAudio 等规范。
只要规范出来了，后续市面上就会根据规范来实现一套 shiv，这些 shiv 提供了同样的 API，提供了同样的编程体验。当浏览器自我进化完成之后，这些 shiv 也将成为历史，被开发者遗弃在代码的注释之中。这些都是规范和标准的魅力，它的存在，就是让开发者把精力投入到自己的业务之中，编程和范式的工作交给它。
在这里可以看到，W3C 各个小组最近都在干啥。标准不能囊括一切。
