有许多ES6特性看起来很棒,比如=>
语法、Map
对象和long等等。
老实说,我已经厌倦了检查addEventListener是否支持ie8 attachEvent,我不希望那种痛苦回到我的生活中来。
那么,你会如何处理这种新的情况呢?(或者说,在一年左右的时间里,你会怎么做)。您会不会将它们用于基本操作,而是添加另一层额外功能?你会把它仅仅用于那些你知道你将在支持它们的浏览器中运行的应用程序吗?你能等到至少有90%的支持吗?
我知道这些都是很好的特性,但在短期到中期的使用中,您似乎需要加倍检查和备份代码以获得支持。
对这个问题有什么启发吗?
编辑:请不要将此标记为副本。注意,我不是在问如何检查支持,而是问开始使用它是否明智,还是等待更好。我还在问,支持检查是否是最好的选择,而不是如何执行,或者在设计代码时是否有其他方法进行处理。
发布于 2015-05-29 17:44:29
tl;dr:利用转运器和填充物。
您是否应该使用新特性主要取决于您的目标环境,以及您究竟如何使用新功能。如果你只针对最新的浏览器版本,那么你就不会有问题了。必须支持IE8吗?这可能会更困难。
不过,通常情况下,您应该尽快开始使用新特性,并使用帮助您实现这一点的工具。
有两个方面需要考虑:
API
新API通常(但不总是)是多填充的。也就是说,您包括一个库,它检查API的某些部分是否存在,例如Map
,如果不存在,则提供另一个实现。
这些替代实现可能不是100%等效的,也可能不像本机实现那样具有性能,但我认为它们对于所有用例都适用于95%。
多填充的好处是,如果可用,您将自动使用本机浏览器实现。
语法
使用新的语法结构(如箭头函数或类)要复杂一些(但不多)。最大的问题是不支持语法的浏览器甚至无法计算代码。您只能将代码发送到浏览器实际可以解析的浏览器。
幸运的是,许多新的语法元素,比如箭头函数,实际上只是一些已经可以使用的ES5的语法糖。因此,我们可以将ES6代码转换为它们的ES5甚至ES3等价物。
在过去的一到两年里,出现了几种这样的工具,称为“转发器”。注意,转换程序必须在将代码发送到浏览器之前对其进行转换。这意味着,与其简单地编写JS文件并将其直接包含在页面中,还需要有一个首先转换代码的构建步骤(就像我们在其他语言中所做的那样,比如C或Java)。
这与几年前我们编写JS的方式不同,但是构建步骤越来越被JS社区所接受。也有许多构建工具试图使这尽可能地无痛。
其中的一个缺点是,与多填充不同的是,如果本地特性可用,您就不会神奇地使用它们。因此,您可能会在很长一段时间内继续发布这个转置版本,直到您的所有目标环境都支持您所需的所有功能。但这可能还是比根本不使用新特性更好。
https://stackoverflow.com/questions/30529367
复制相似问题