【问答】为什么会允许babel这种解析工具的存在？

本文来自知乎问题为什么会允许babel这种解析工具的存在？

希望提问者真的没有在调侃……因为在我看来，这有点像“何不食肉糜”的提问了。

ES6又名ES2015，也就是在2015年定稿的，在定稿之前其实大家已经讨论了很久了。但是光讨论有什么用呢？没有任何一个环境是支持ES6运行的。所以就讨论讨论再讨论，然后大家一拍桌子，好，定稿？

事实上在ES2015之前，ES5可能就是这么定下来的，ES4可能也是这么废弃的。

这时候，就有个神奇的东西，叫6to5出现了，它的第一次提交出现在2012年9月。Initial import · babel/babel@aedcd4e 它的作用就是把ES6的代码编译成ES5的代码，它的神奇之处就在于，虽然一个能支持ES6的环境都没有，但是我们仍然可以使用ES6来编写代码。这是一种前所未有的模式，甚至在其它语言中都没有出现过这种模式。（希望不是孤陋寡闻，至少py3 -> py2是没有见到类似工具的。）

于是，我们可以在规范还没有定稿的时候就先用用看，用着觉得不爽了再回去修改规范。这样是不是比拍桌子要科学得多？事实上现在的ES规范制定过程就是这么干的，定了stage 0到stage 4等几个级别，而且规定了需要在多少个环境中先验证，验证完之后才可以定稿发布。基本上可以毫不客气地说，这个东东就是由6to5开创的新局面。

当然，在规范发展过程中，浏览器、Node.js等环境也在不断实现ES6规范的特性，6to5的作者自然也清楚，等环境都支持ES6了，可能就没我什么事了。（像题主这样，认为大家都支持就好，不需要编译了。）所以这个作者又开了个脑洞，首先将6to5做了个改名，以便让它的适应范围更广，要不然以后ES 7/8/9出来的时候玩得名不正言不顺的嘛。然后，将所有的转译过程全部插件化，你可以自由选择某个ES6/7/8特性是否要做转换。这样作为一个转译插件，它就可以更好、更长久地生存下去，也能持续为JS社区带来价值。不得不说，作者真是个天才。（据说写6to5的时候还是个高中生……）

这个神奇的6to5后来改的名字，就叫babel。可以说，没有babel就没有JS社区今天在语言规范上的高度繁荣。也就没有提主提问的前提存在了。

（当然，也要承认，在6to5同期也有其它的转译插件，例如来自Google的traceur，但babel一开始在转译后的代码可读性上就有优势，后期改名和插件化又是神来之笔，因此很快胜出。）

再来说今天仍然使用babel的重要性。

首先一个很重要的点，用户用什么鬼玩意你是无法决定的。虽然现在主流浏览器对ES6的支持都能到99%以上，但是如果用户用的safari 8呢？用的IE9呢？用的Android 4.0呢？这一点很多答主都已经解释得很清楚了，不再多说。

第二个点其实在看完上面一大段后也容易理解了，babel != ES6，并不是只有ES6才可以用babel呀。事实上你用的ESM模块化规范import/export，并不属于ES6规范，你用的async/await也不属于ES6规范，你用的666的解构，也有一部分不属于ES6规范……但是非常幸运的是，babel并不苛求你知道它属不属于ES6，而是默默都帮你处理了。因此，后ES6时代，babel仍然可能长期存在。（这也再次印证作者眼光很毒！）

第三个点，babel除了做ES规范的转译以外，也可以做做别的转译，比如JSX/TS。但这个在我看来不属于babel的主业，而是人们发现babel的转译是万能的，既然在工具链中已经无法缺少了，顺手让它也帮帮忙也无可厚非。

以上。均是个人理解，如有错漏，欢迎评论指正。