嗯，我知道我们需要Transpilers＆Pollyfills以保持向后兼容（按顺序）为scale的
一种语法更新的编程语言
或
为pl添加新功能！
但是这提出了一个问题，为什么在保持向后兼容性的解决方案与那些旨在优化浏览器性能的解决方案之间没有一个可以接受的折衷；换句话说，大多数解决方案都集中在支持老版本的浏览器上，而这需要付出转移和编译开销的代价，而不是公开Web浏览器标准化来推荐老版本的浏览器以支持较新的版本
Most代码几乎不会影响在用户浏览器上运行的代码的性能。对于任何给定的昂贵操作，通常都有几段代码的明显瓶颈，脚本编写者可以根据需要尝试进行优化。一些人认为，性能优化通常是可能的，并且性能瓶颈[[通常与浏览器不兼容问题无关，尽管它们occasionally do。 （异步编译所需的RegeneratorRuntime有点重量级。）
需要进行权衡，但是除了RegeneratorRuntime之外，这种差异几乎总不值得担心，我认为-如果有以下情况，通常代码中还有其他地方可以集中精力来加快慢速脚本的速度：这是您担心的问题。转移和编译开销的成本
这笔费用是在脚本被转译时支付的，并且不是禁止性的，因此（很多人会认为）这是值得的，以换取能够以最新，最出色的版本编写语言，同时继续允许过时的浏览器理解您的代码。
而不是公开网络浏览器标准化来推荐较旧的浏览器以支持较新的版本
大多数运行足够过时的浏览器的人要么没有选择（在某些企业环境中），要么根本不了解计算机（否则他们将进行升级）。让他们进行更改是[[真的很难。