青岛网站建设迅优,长春网站制作建设,深圳最好的外贸seo培训,药品包装设计公司最后一个支持 ES5 的浏览器 IE 11 在 2022 年被微软停止支持#xff0c;那么今天 Web 上的 ES5 现状如何#xff1f;在构建生产代码时#xff0c;Web 开发者的最佳实践是什么#xff1f; 本文将通过数据来回答这些问题#xff0c;并基于这些数据为网站开发者和库作者提供一… 最后一个支持 ES5 的浏览器 IE 11 在 2022 年被微软停止支持那么今天 Web 上的 ES5 现状如何在构建生产代码时Web 开发者的最佳实践是什么 本文将通过数据来回答这些问题并基于这些数据为网站开发者和库作者提供一些具体的建议帮助他们在未来处理旧版浏览器的支持问题。
简要声明
在深入探讨 ES5 使用的实际数据之前本文需要澄清一点编写或发布 ES5 代码本身并没有什么错。
JavaScript 引擎对 ES5 代码的优化时间比对现代代码的优化时间长得多所以如果你有旧的 ES5 代码仍在工作没有必要仅仅为了使其“现代化”而更新它。
然而如果你使用 ES6语法编写代码然后使用构建工具将其转译为 ES5这通常会导致大量的 polyfill 和转译器膨胀显著增加最终包的大小。
为了说明这一点下面是一个例子
console.log([1, 2, 3].at(-1));如果你手动将这段代码转译为 ES5它可能看起来像这样
var arr [1, 2, 3];
console.log(arr[arr.length - 1]);然而如果你使用Babel转译这段代码并配置它以添加 polyfills——即使你仅限于根据源代码中的使用情况添加所需的 polyfills——它会包含71 个 core-js 依赖项并从 31 字节增加到11,217 字节的最小化代码
这个例子的重点不是要说 Babel 或 core-js 不好。这些工具需要支持所有可能的 ES6代码这要求它们考虑各种边缘情况尽管这个特定的例子没有任何边缘情况。
相反重点是强调选择支持旧版浏览器是有代价的而且这个代价可能非常高。
不幸的是问题实际上比代码膨胀更糟糕。如果查看下面的数据了解今天流行的网站实际上是如何转译和部署他们的代码到生产环境你会发现大多数网站在互联网上发布的代码是转译为 ES5 的但仍然无法在 IE 11 中工作——这意味着转译器和 polyfill 膨胀被 100%的用户下载但没有一个用户受益。
数据分析
要了解 ES5 在 Web 上的现状需要关注以下三个方面因为它们都在我们作为 Web 用户接收到的最终代码输出中起着关键作用
流行的打包器和构建工具的默认配置流行 JavaScript 库中的代码状态网站所有者部署的代码状态
默认打包器和构建工具配置
大多数打包器和构建工具都具有极高的可配置性几乎可以对最终输出的代码进行无限控制。然而在实际操作中大多数开发者只是使用默认配置因此默认配置非常重要。
那么这些默认配置是什么具体来说这些默认配置是否会将代码转译为 ES5
可以通过State of JS 调查2023 年看到最受欢迎的构建工具按使用量大致排序如下
工具默认转译为 ES5备注Browserslist否本身不是构建工具但被许多构建工具内部使用是配置浏览器支持目标的最流行开源工具。defaults设置不再包括任何 ES5 浏览器。最后一个是 IE 11它在 4.21 版本中被标记为已废弃。Babel是Babel 的文档推荐设置targets选项使用 Browserslist但如果未指定它将转译所有代码为 ES5。webpack否默认情况下webpack 不会转译任何代码。大多数 webpack 用户包括babel-loader而 webpack 的使用示例建议设置targets: defaults。TypeScript (tsc)是TypeScript 的默认target选项是 ES5。Next.js否Next.js使用 Babel 进行转译默认设置一个 Browserslist 配置目标是现代浏览器即支持 ES 模块的浏览器。esbuild否esbuild默认不进行转译。你可以设置自定义目标以启用转译但 ES5 不支持作为转译目标。Vite否Vite 使用 esbuild默认设置自定义目标为现代浏览器即支持 ES 模块的浏览器。如果需要支持旧版浏览器Vite 允许用户安装一个插件。Rollup否Rollup 默认不进行转译。许多 Rollup 用户安装rollup/plugin-babel在这种情况下使用 Babel 的默认配置。Parcel否Parcel自动应用差异化服务并具有可自定义的目标。Closure Compiler否默认设置为ECMASCRIPT_NEXT即最新的一组稳定的 ES 特性。
如上表所示绝大多数打包器和构建工具默认不再转译为 ES5。值得注意的是较新的工具根本不支持 ES5这表明趋势正在向这个方向发展。
尽管如此Babel 仍然是最流行的 JavaScript 转译工具因此在 Web 上转译为 ES5 仍然相当普遍详见野外的 ES5 使用情况。
流行的 JavaScript 库
除了查看流行的构建工具外还查看了一些当今最流行的库同样基于State of JS 调查按受欢迎程度大致排序
为了测试这些库中的每一个我创建了一个仅导入该特定库的打包入口点使用库文档中的一个代码示例。然后我使用 Rollup 和 Webpack 打包代码测试输出并查看是否包含任何 ES6语法特别是任何IE 11 不支持的 ES6语法。
结果
库包含 ES6语法备注Lodash否仅 ES5React否仅 ES5date-fns是箭头函数three.js是async/await箭头函数展开运算符解构赋值d3是箭头函数展开运算符解构赋值Framer-motion是箭头函数展开运算符解构赋值greensock否仅 ES5dayjs否仅 ES5Zod是async/await箭头函数展开运算符解构赋值RxJS是箭头函数immer是箭头函数展开运算符解构赋值luxon是async/await箭头函数展开运算符解构赋值react-query否仅 ES5打包了 Babel 助手
如上所示许多流行的 JavaScript 库现在发布的是 ES6语法。
这很值得注意因为正如我之前提到的大多数使用 Babel 转译源文件的开发者在打包时明确配置他们的打包器不转译node_modules目录中的任何内容——这是库作者历史上觉得需要继续转译为 ES5 的主要原因。
截至 2024 年 9 月
Webpack 的babel-loader文档推荐的配置排除了node_modules。Rollup 的plugin-babel文档建议排除node_modules并且建议库作者不要发布 ES6 代码。
而 TypeScripttsc作为仅次于 Babel 的第二大转译工具只会转译项目自己的代码文件。它不会转译node_modules中的项目依赖项。
这就为任何希望支持 ES5 并使用 Babel 或tsc转译代码的网站带来了问题。除非他们对构建管道的各个部分如何相互作用有深刻的理解并且知道如何正确配置每一个部分否则他们可能会在不知不觉中将 ES6代码与 ES5 代码一起打包。
那么这是否真的对实际网站造成了问题还是大多数网站正确配置了他们的工具下一节将通过HTTP Archive的数据来回答这个问题。
注意 上表中的一些库发布了 ES5 和 ES6版本通常 ES5 版本设置在package.main字段而 ES6版本设置在package.module或package.exports字段。在这些情况下我只查看了使用默认配置时打包器拉取的脚本版本因为这是大多数人使用的而今天的打包器默认使用package.module或package.exports而不是package.main参见[1][2][3]。
野外的 ES5 使用情况
开发者用来将 ES6代码转译为 ES5 的三大主要工具是
BabelTypeScripttscClosure Compiler即 Google 内部的 JSCompiler
这三种工具都包括某种形式的 polyfills 和所谓的 ES5“助手”函数以避免在最终输出中重复。最常用的 ES5 助手函数库是babel-helperscore-jsregenerator-runtimetslib和$jscomp。
这些助手库中的许多函数都足够独特可以通过查询 HTTP Archive 来检测即使在最小化代码中哪些网站在使用它们。搜索这些助手函数的存在——而不是标准的 ES5 语法如var或非箭头function——有助于区分手写的旧 ES5 代码通常相当优化和由转译器生成的新 ES5 代码通常相当臃肿。
我在 HTTP Archive 上进行了搜索看看流行网站基于CrUX 受欢迎度排名的前 10,000 个网站在他们部署到生产环境的脚本包中包含这些助手的情况有多普遍。我还想看看网站提供未转译的 ES6语法的情况有多普遍。
以下是我发现的结果完整结果
89% 的网站提供至少一个包含未转译 ES6语法的 JavaScript 文件。79% 的网站提供至少一个包含 ES5 助手代码的 JavaScript 文件。68% 的网站提供至少一个同时包含 ES5 助手代码和未转译 ES6语法的 JavaScript 文件。
重申一下本文的观点——如果浏览器不支持 ES6语法如 IE 11那么它在尝试加载包含 ES6语法的脚本文件时会出错。而如果浏览器确实支持 ES6语法那么它不需要任何 ES5 助手代码或任何旧版 polyfills。绝对没有理由同时包含两者。
为了确认这个查询结果的准确性手动测试了列表中的 20 个随机网站确认它们确实在某些脚本包中同时包含 ES5 助手代码和 ES6语法。还手动在 IE 11 中访问了这些网站确认这些脚本包确实无法加载。
请记住这些不仅仅是互联网上的随机网站。这些是全球最受欢迎的 10,000 个网站
这意味着什么
对于一个网站来说提供包含 ES5 助手和未转译 ES6语法的代码实际上只有两种可能的解释
该网站不需要支持 ES5 浏览器但他们的一些依赖项转译为 ES5因此 ES5 代码出现在他们的输出中。该网站打算支持 ES5 浏览器但他们没有意识到一些依赖项发布了未转译的 ES6语法并且他们没有配置打包器来转译node_modules中的代码。
无论是哪种解释全球许多最受欢迎的网站都在提供大量不必要的代码这强烈表明我们当前工具推荐的默认配置并不起作用。
如果从这些数据中能找到一丝安慰那就是显而易见的是放弃对 IE 的支持不会对大多数企业产生明显影响。如果所有这些大公司显然没有受到这些 IE 体验破坏的影响那么你的公司也可能不会。
建议
对于库作者
库作者应将代码转译为 ES5 的最初理由是大多数网站需要转译为 ES5。然而鉴于目前前 10,000 个网站中有 89%发布了一些未转译的 ES6语法这一理由已不再有效。
根据本文提供的数据JavaScript 库作者不再需要将代码转译为 ES5。
实际上库作者对导入它们的网站的浏览器支持需求没有信息因此不应该为其所有用户做出这个决定。同时库作者也不应该假设所有用户都能够通过复杂的构建过程运行它们的库因此发布的代码应使用完全标准的 JavaScript并在当前广泛使用的浏览器中工作。
那么库作者应该选择什么目标在我看来库作者的最佳解决方案是使用Baseline——具体来说只包括Baseline Widely Available特性在任何发布的代码中。
如果你不熟悉 Baseline这是 W3C 内的WebDX 社区组的一项努力旨在帮助开发者轻松识别所有主要浏览器和浏览器渲染引擎在桌面和移动设备上稳定且广泛支持的特性。如果某个特性在所有四个主要浏览器的稳定版本中至少存在 30 个月则被认为是Baseline Widely Available。
针对Baseline Widely Available的主要好处是它是一个动态目标这意味着它不会像针对 ES5 那样被困在过去这也是 Next.js、Vite 和 Parcel 使用的esmodule目标目前正在发生的情况。
库作者可以通过以下Browserslist查询配置他们的构建系统以现在针对Baseline Widely Available特性适用于任何支持 Browserslist 的工具
targets: [chrome 0 and last 2.5 years,edge 0 and last 2.5 years,safari 0 and last 2.5 years,firefox 0 and last 2.5 years,and_chr 0 and last 2.5 years,and_ff 0 and last 2.5 years,ios 0 and last 2.5 years,
];注意 有一个开放的功能请求希望将 Baseline 支持添加到 Browserslist这将使上述查询简化为“baseline widely available”。
如果某个网站需要支持比Baseline Widely Available覆盖的更多浏览器这完全没问题。该网站可以始终配置其构建系统以进一步转译任何导入的库。关键是这个决定最好由网站开发者做出而不是库作者。
对于网站开发者
许多网站开发在同一个脚本包中同时提供未转译的 ES6语法和 ES5 助手代码这清楚地表明排除node_modules目录不进行转译的做法并不是一个好做法。
然而如今构建工具已经变得显著更快。此外网站可以配置他们的构建只在生产环境中处理node_modules中的代码。在开发中代码应该在开发者使用的任何浏览器上运行良好特别是如果库作者遵循我上面给出的建议并针对Baseline Widely Available。
主要观点
ES5 不再是构建工具或 JavaScript 库应该默认针对的目标。 如果工具仍然希望提供 ES5 支持这应该是有特定支持需求的单个网站可以选择的。构建工具和库不应该使用固定的浏览器支持策略。 这些策略很快就会过时这导致了本文数据中突出的问题。浏览器支持决策应该由网站本身做出而不是它使用的工具。一个好的浏览器支持策略是Baseline Widely Available。导入第三方库的网站开发者应该将这些库作为其构建的一部分进行处理。 不能假设所有库作者都有与你相同的浏览器支持需求。正如本文数据所示在许多情况下网站开发者可能比他们导入的库有更广泛的浏览器支持需求因此需要进一步转译它们。跨浏览器支持不应该完全依赖于你的构建工具来处理。 如果需要支持特定的一组浏览器那么你需要测试你的网站以确保它在这些浏览器中正常工作。
参考
The State of ES5 on the Web
