我不是要在这里比较浏览器-看到时间变化有多快，这是浪费时间。 我想表明的是，当涉及到浏览器中对ES6的支持时，它们之间存在很多差异。 这使功能测试不方便，因为只有在测试所有要使用的东西时，它才是安全的。 如果仅测试一个，则假定对其他功能的支持是滑坡。

如果您一直坚持到底，并想对要使用的每个功能进行测试，则代码不会中断。 但是，它很容易变成过度杀伤力。 对于许多开发人员而言，ES6的重点不是使用零碎的功能，而是从一开始就将整个应用程序编写在ES6中。

没什么新鲜的。 当HTML5和CSS3只是一个炒作而我们迫不及待地使用它时，我们得到了很多“这个很酷的东西仅在Safari中有效”或“您需要使用Chrome浏览器才能看到此站点”的很多信息。功能仍在不断变化。 这些产品仍在网络上，基本上不需要维护，浏览器需要在代码库中包含很多内容，以免破坏网络。 我们想要太多，太快了，之后我们没有清理。

为了使开发人员能够使用Modernizr自动检测所有内容，我们付出了很多努力。 对于旧版浏览器支持，这仍然是一个很好的主意，但是在定义更明确的环境中，开发人员发现这是不必要的开销。 取而代之的是，我们开始设置支持基准，并且仅向实现这一目标的那些浏览器提供脚本功能和高级样式。 英国广播公司（BBC）的开发者在三年前称其为“ 切芥末 ”，他们的基准是以下几项检查：

if ('querySelector' in document &&'localStorage' in window &&'addEventListener' in window) {// bootstrap the javascript application
}

也许这也是我们在ES6工作中可以想到的东西？ 定义一些可以检查并从那里继续前进的网闸功能？

如果您不希望依赖浏览器支持，而只想使用ES6，那么您将需要使用一些可转换代码的工具。 这可能是自己的语言，如TypeScript或所谓的Transpiler（因为它将ES6转换并编译为JavaScript）。

转为救援？

如今，关于JavaScript的好处是它摆脱了浏览器的限制，并且可以在服务器端使用。 node.js使用Chrome的V8引擎作为独立的二进制文件，现在还可以使用Microsoft的Chakra JS引擎 。 这使我们能够使用任何JavaScript转换工具来获取ES6代码，并将其转换为可在任何浏览器中运行的良好的旧JavaScript。 如果您已经在使用Grunt或Gulp进行任务管理，那么这可能只是部署之前要运行的另一项任务。

有一些选择。 最著名的编译器是Traceur ，它们起源于Google和Babel ，最初称为6到5，但是随着ECMAScript的发展，即使我们尝试实现它，也需要一个更通用的名称。

目前，转译似乎是在实际项目中使用ES6的最安全方法，而不必担心跨环境的支持差异。 它也与习惯于更严格和基于类的语言的开发人员的工作流程紧密地联系在一起。 但是，自省之后，存在一些怪异的缺点：

• 首先，在大多数情况下，编译根本不进行任何功能检测-ES6代码已完全转换为ES5（或者在某些情况下甚至可以转换为ES3，如果您想这样做）。 这意味着本机支持ES6的浏览器将永远无法获取代码。 它使浏览器中的实现有点多余，并且-更糟的是-它不允许在浏览器中测试ES6实现的性能和有效性。
• 传统上，网络是视图源。 过去，这就是我们许多人学习如何为其编写代码的方式。 在错误控制台中看到有问题后，我们查看了源代码并发现了其他人使用的代码，并且调试过程也在做同样的事情。 如今，我们拥有用于开发人员的工具，具有更多高级功能。 但是，如果我们编译代码，就永远不会编写要执行的代码。 我们在浏览器中调试的代码是编译器创建的，编译器针对性能进行了优化，而不是为了提高可读性。 为了调试我们的代码，我们需要找到一种方法来将生成的代码与编写的代码连接起来。 为此，我们使用源映射 。 这也适用于Sass或更少生成的CSS。
• 从其他代码生成代码可能会导致大量文件。 当最终结果意味着用户必须下载兆字节的JavaScript才能获得更轻量级的接口时，我们编写的原始代码紧凑，干净，结构化不一定重要。

表现如何？

每当我们向浏览器引入新功能时，就会出现一个问题，那就是我们使处理速度加快还是减慢了速度。 我们只是不知道，直到我们收集了足够的数据来找出优化的地方。 在ES6的情况下，如果我们对代码进行转译，则无法真正进行数据收集。 目前， 凯文·德克尔（Kevin Decker）的速度报告显示，本机在浏览器中ES6的性能看起来并不太令人鼓舞。

该报告显示了ES6功能相对于每秒ES5基准操作的性能。 所有不是深绿色的东西都比JavaScript慢。 并非深绿色的所有内容要么较慢，要么与ES5性能相同​​。 这意味着只有传播算子 ， Promises ， Maps和Sets可以带来性能上的好处。

ES6很重要，需要我们注意

现在，就整个Web开发而言，ES6处于一个怪异的境地。 它是一个标准，得到了很好的支持（例如，Web组件除外），但是它也破坏了向后兼容性。 除了要赞扬它所做的所有伟大事情，并没有显示可能对您有用的示例之外，我想邀请您参加有关ES6的讨论。 这就是为什么我想在这里结束时提几个问题供您思考，我们很乐意在评论中听到您的意见。

如果我们的主要目的是通过编码工作来创建Web内容，那么我们需要问自己几个问题：

• 我们是否让开发人员的便利性胜过最终用户体验？ 是否比在特定环境下交付性能最佳的解决方案更重要，交付速度更快，更重要？
• 在我们更轻松，更快速，更可维护的情况下，构建能够期望更多最终用户环境的大型应用程序是否可以？
• 能够更轻松地更改应用程序并以更明确的方式扩展应用程序来弥补对用户的锁定吗？
• 现在是时候在沙子上划一条线，使JavaScript更安全，更容易扩展了吗？
• 网络持续向后兼容的概念存在缺陷吗？ 我们是通过迎合最低公分制来阻止自己吗？
• ES6的新功能真的有好处吗？还是我们只是试图追赶并重复其他环境所做的事情？ 看到整个软件可能损坏 ，这真的是我们能做的最好的事情吗？
• 这些更改的好处值得使用它们的努力吗？ 进入网络的新开发人员是否应该使用编译器，预处理器和任务运行程序来入门？
• 当编译器创建ES5时，我们如何帮助浏览器更好地支持ES6？
• 是使用JavaScript的子集（如TypeScript）更好的选择吗？
• 从浏览器获取的代码中提取我们编写的代码是正确的方向吗？ 视图源已经失去了它的用处吗？
• ES6是否是另一种在Web上工作的方式–就像使用emscripten is或Flash was将字节码转换为JavaScript一样？ 对于Web开发人员来说，预编译步骤似乎很奇怪，但是Java的人对此完全可以接受。 换句话说，ES6是否不适合所有人，但我们会尽力做到这一点？

在接下来的几个月中，围绕ES6将会令人兴奋，它的本质意味着将有相当长的一段时间进行持续的讨论和讨论。 它对不喜欢JavaScript的灵活性和随机性的人非常有吸引力。 它会使那些坚定地使用JavaScript的人感到困惑，并且感到很多开销，而没有太多直接的好处。 进化总是伴随着成长的痛苦。 是时候说出来，尝试一下对您有用的了。

使用JavaScript进行更多操作

本文是Microsoft技术传播者开发的Web开发系列文章的一部分，内容涉及实用的JavaScript学习，开源项目以及互操作性最佳实践，包括Microsoft Edge浏览器和新的EdgeHTML呈现引擎 。

我们鼓励您使用dev.modern.IE上的免费工具跨浏览器和设备进行测试，包括Microsoft Edge（Windows 10的默认浏览器）：

• 扫描您的站点以查找过期的库，布局问题和可访问性
• 在Mac，Linux和Windows上使用虚拟机
• 在您自己的设备上远程测试Microsoft Edge
• GitHub上的编码实验室：跨浏览器测试和最佳实践

我们的工程师和宣传人员在Microsoft Edge和Web平台上进行了深入的技术学习：

• Microsoft Edge Web Summit 2015 （新浏览器，受支持的新网络平台标准以及来自JavaScript社区的嘉宾演讲者会期待什么）
• 哇，我可以在Mac和Linux上测试Edge和IE！ （来自Rey Bango）
• 在不中断网络的情况下推进JavaScript （摘自Christian Heilmann）
• 使Web正常工作的Edge渲染引擎 （来自Jacob Rossi）
• 使用WebGL释放3D渲染 （来自David Catuhe，包括vorlon.JS和babylonJS项目）
• 托管的Web应用程序和Web平台创新 （来自Kevin Hill和Kiril Seksenov，包括歧管 .JS项目）

Web平台的更多免费跨平台工具和资源：

• 适用于Linux，MacOS和Windows的Visual Studio代码
• 使用node.JS进行代码和Azure上的免费试用

From: https://www.sitepoint.com/the-es6-conundrum/