【问答】为什么会允许babel这种解析工具的存在?
2019年3月28日
本文来自知乎问题为什么会允许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的转译是万能的,既然在工具链中已经无法缺少了,顺手让它也帮帮忙也无可厚非。
以上。均是个人理解,如有错漏,欢迎评论指正。