早在2009年当我开始读博的时侯，我告诉导师，我想选择优化动态编程语言的方向。我的论文很大的一部分将涉及一些动态JIT语言编译器的实现，最后我们的讨论集中在应该选择哪种语言。最后，我们最终选择了JavaScript。这是一个很好的方案：被广泛使用的“现实世界”中的编程语言，还有一点，这种语言足够轻量，一个人就可以实现编译器。 ECMAScript 5的规范大概250页长，我把它从头读到尾，然后开始设计Higg。
从那以后，我觉得我一直在看着JavaScript慢慢变成C++，它成为了“kitchen sink”式的语言（注*来自二战时期的成语"everything but the kitchen sink", 指除了洗碗槽外各式各样的炮弹齐发，现在指有太多的东西）。因此，许多新的功能被添到ES6的新规范上。从字面上统计这个规范已经是ES5规范长度的两倍。更糟糕的是，在ES6规范完成之前，已经有人预定了一箩筐的新功能要集成到ES7。他们都还没有完成ES6，就已经开始计划ES7了。有一些JavaScript语义不一致的地方需要修复，但新加入的ES6和ES7的新特性无助于解决这些问题，他们仅仅是增加了新功能（或者说：复杂性）到这个语言。
就个人而言，我比较崇尚简单和极简主义编程。我认为，较小的语言比较容易实现、优化、学习、调试和理解。你的语言越大越复杂，更多的语义不一致性就会在更多的虚拟机之间跳出来。如果JavaScript真的是“Web界的汇编语言” ，那么它为什么非得要实现这些高层次的功能特性？合乎逻辑的做法是应该尽可能多的固化JS的底层语义，并专注于改善和优化支持JS的编译器。我相信JS的复杂性一直在持续增长的原因是出于它是由学院派设计驱动的。
我当然有偏见。实际上我实现了自己的JavaScript JIT编译器，我太忙了，而且跟不上这增加这些新功能。在我看来，在当今的网络世界里，没有人会暂停片刻，呼吸和思考一下。案例分析： Mozilla 做了一个很大的噪音asm.js，编译标准的本地代码到JS，而且据称比谷歌的Native Client 更好。我觉得asm.js仍然是比较新的，还没有足够多的开发商采用和通过它，它只有在技术演示中使用过，但Mozilla和谷歌已经开始着手WebAssembly ，它独立于asm.js，二者没有什么关系。第二：asm.js仍然是很新的（2013年开始，它只有两岁），有没有足够多的采纳的情况下，它的影响微乎其微。
从本质上讲Brendan Eich告诉我们的WebAssembly，是希望将所有的编译器设立一个中立的编辑目标，我们真的不希望或需要为Web创建一种新的字节码格式或编译器实现，在我看来，这是一个有点不幸的妥协。
说的像你很懂C++似的
@文上右 #0
我想他的意思是js正在变得更复杂
你并没有看到新标准的好处，想想怎么处理金字塔回调吧，Promise、Co、Async/await
@Leo #2
将Promise和Async这些模式引入JavaScript核心是不合适的，他们太过高层次，已经非常偏向应用实现层了，其实有很多很三方库都可以实现。任何设计模板、设计思想都有过时和不流行的时侯，不应加入枯层的语言核心。
路过，O(∩_∩)O哈哈~
@施厅广 #3
赞同！