JS
在国内当前的环境下，日常业务开发预计不会有太大变动或影响。从理解上看，这次调整的目标似乎是希望放缓标准推进的速度。近年来，ECMAScript（即262标准）中的新特性层出不穷，不仅涉及语言层面的语法改进，还包括浏览器端不断丰富的API功能。这样的快速更新确实给标准的实现带来了一定的压力。在相关文档中提到，开发方向逐渐向用户端倾斜，给出的例子多与当前引擎中存在的漏洞有关。将后续的标准推进拆分为
JS0 +
JSSuger这一模式，在实际开发中对我们的影响可能并不明显。这实际上是通过放慢标准从各个阶段（STAGE）完成的速度来实现的：一部分经过深思熟虑且被广泛认可的特性会被优先纳入标准，并由各引擎负责实现；而其余特性则交由编译工具处理，经过一段时间观察后再逐步推进到
JS0核心部分。实际上，目前我们已经在这样做，例如为了兼容生产环境，通常会通过polyfill或shim等方式，将ES6代码编译为ES5，甚至提前使用一些仍处于草案阶段的功能，像装饰器（decorator）就是这样一种情况。然而，这种划分方式也可能引发一些潜在问题。首先，
JSSuger内的提案可能会出现失控的情况。切分后，这部分相当于新增了一个测试环境，可能导致大量内容涌入，这对社区的跟进速度以及各类工具能否及时实现对应的语法编译提出了更高要求。其次，如何处理废弃提案也是一个难题。如果某些提案进入了
JSSuger，社区也积极跟进，但之后又被移除，开发者就会陷入被动局面，类似于现在那些无法轻易移除的历史遗留API。此外，相应的语法提示和代码提示也需要同步完善，否则会给开发工作带来不便。随着
JSSuger中提案数量的增长，开发人员需要掌握的语法种类也会增多，这无疑增加了学习成本。当然，上述隐患的前提是
JSSuger确实会吸引大量提案进入。若能妥善管理，这种模式或许能够更好地平衡创新与稳定性之间的关系。
