随着2024年三月的到来，前端技术领域迎来了一系列更新和进展。从Babel 7.24.0带来的装饰器和JSON模块改进，到Parcel v2.12.0的新特性，每项更新都体现了技术社区对前端开发便利性和效率的持续追求。此外，Package Metadata Interoperability Collab Space的成立、Deno团队的最新调查、JSR的公测发布，以及Jco 1.0的推出，都在不同维度上推动了前端技术的发展。这些进展虽然各有侧重，但共同构成了前端技术不断前行的足迹。本文将逐一解析这六大技术亮点，探索它们对开发者及开发生态的潜在影响。

1、Babel 7.24.0版本 - 装饰器和JSON模块的革新

在这个迅速变化的前端世界里，我们总是追求着更优雅的代码书写方式和更高效的开发流程。最近，Babel团队发布了7.24.0版本，带来了一系列激动人心的更新，特别是对装饰器的实现进行了更新，以匹配最新的提案版本，并且在类的私有字段和方法的转换方式上进行了改进。同时，他们还添加了对在浏览器和Node.js中导入JSON模块的支持，这是一个较早的Stage 3提案，依赖于导入属性（Import Attributes）的特性。

装饰器的新风采

装饰器是一种在ES2016（即ES7）中提出的语法，用于修改类和类成员的行为，但它直到现在仍处于提案阶段。在过去的几年中，装饰器提案接受了许多小的更新，不幸的是，不同的工具实现了略有不同的版本。

Babel 7.24.0版更新了其装饰器的实现，以匹配提案的最新版本，这个版本也已经被TypeScript实现，并且正在浏览器中原生实现中。与2023-05版本相比，最大的区别在于通过context.addInitializer方法注册的初始化器的执行顺序。

JSON模块导入：轻松管理配置

另一个亮点是对JSON模块提案的支持，该提案允许使用带有type: "json"导入属性的导入声明直接导入JSON文件。这意味着我们现在可以更为方便地管理配置文件和数据，而不必依赖于其他工具或编写额外的代码来读取JSON。

资讯详情：
https://babeljs.io/blog/2024/02/28/7.24.0

2、Parcel v2.12.0版本新特性解析

最近发布的Parcel v2.12.0版本，它为前端开发者带来了哪些激动人心的新特性和改进。

宏（Macros）——编译时代码生成的强大工具

在v2.12.0版本中，Parcel引入了对宏的支持。这是一个非常有趣的特性，它允许你在构建时使用普通的JavaScript函数来生成代码。与运行时代码相比，宏的执行完全发生在构建时，这意味着最终的包中将不包含宏代码，而是宏执行的结果。这为性能优化和代码组织提供了全新的可能性。

比如，通过宏，你可以在构建时生成优化后的正则表达式，甚至根据特定的规则动态生成额外的资源。这种在构建阶段执行代码的能力，无疑为开发者解锁了更多的创新玩法。

import regexgen from 'regexgen' with {type: 'macro'};

const regex = regexgen(['foobar', 'foobaz', 'foozap', 'fooza']);
console.log(regex);

编译后

console.log(/foo(?:zap?|ba[rz])/);

在线REPL —— 体验Parcel的魔法

Parcel v2.12.0还带来了一个新的在线REPL，这是一个在浏览器中直接试用Parcel的平台。你可以在这里编辑代码、浏览文件，甚至使用大部分Parcel特性，比如观察模式、开发服务器、热模块替换等。这个REPL使用了最尖端的Web技术，如Web Assembly、服务工作线程、Web工作线程后端和IndexedDB，甚至可以通过运行一个编译版本的Yarn来安装npm包。这为快速尝试Parcel提供了一个非常便捷的方式。

CSS捆绑与性能优化 —— 更流畅的开发体验

在CSS处理方面，Parcel现在使用Lightning CSS来转换和捆绑CSS文件。这意味着更好的对现代CSS特性的支持，如@import与级联层次、媒体查询和支持查询的改进支持，以及更正确的处理复杂CSS顺序问题。

性能方面，Parcel v2.12.0通过改进核心图数据结构，减少了约52%的内存使用，并提高了约5%的写入性能。对于一个非常大的应用，这意味着大约减少了800MB的内存使用，而且没有对启动、构建或关闭时间产生负面影响。

资讯详情：
https://parceljs.org/blog/v2-12-0/

3、包元数据互操作性合作空间成立（Package Metadata Interoperability Collab Space）

在OpenJS Foundation下成立了一个名为“包元数据互操作性合作空间”的中立行业组织，旨在迭代package.json的非正式标准化过程，并改善JavaScript包元数据对应用开发者的互操作性。这一新动向不仅体现了技术社区对于提升开发效率和促进技术标准化的不懈追求，也反映出了在快速发展的前端生态中，如何通过合作和共享来推动技术的进步和创新。

为什么包元数据互操作性如此重要？

在现代的前端和全栈开发过程中，package.json已经成为配置JavaScript项目的事实标准。它不仅定义了项目的元数据，还包括其依赖关系和配置。然而，随着不同的JavaScript运行时和工具的出现，如何保持这些工具之间的元数据兼容和互操作性，成为了一个挑战。

OpenJS Foundation的这一行动旨在通过聚集不同利益相关者的力量，共同探讨和制定一套既能满足现有需求又具备一定灵活性的技术框架，从而促进工具的良性发展和生态的多样化。

创新的呼声：宏观视角下的package.json

随着Deno等新兴JavaScript运行时的出现，对package.json的依赖和评价出现了新的讨论。Deno的共同创始人Ryan Dahl曾公开表达对package.json的遗憾，这也促使Deno团队探索了包括deno.json在内的其他配置方案。尽管如此，Deno在2023年添加了对package.json的支持，以增强与Node和npm的兼容性，这一决策既是对历史的妥协，也是对未来可能的开放。

包元数据互操作性合作空间的任务

该合作空间不仅仅聚焦于改善package.json的标准化和互操作性，更重要的是，它旨在为广大的JavaScript生态提供一个探索和实验的平台，通过研究现有实践和工具，挖掘它们的优势和劣势，并围绕这些研究构建工具。这一过程旨在促进一个更加包容和多样化的生态系统，让不同的运行时和工具能够更好地协同工作。

资讯详情：
https://socket.dev/blog/openjs-improve-interoperability-of-javascript-package-metadata

4、近期，Deno团队发起了一项调查并公布了调查结果

近期，Deno团队发起了一项调查，旨在聚焦于改善Deno运行时的努力。通过超过700份的响应，我们不仅看到了Deno在发展中的进步，也识别出了需要改进的领域。以下是调查的关键洞察及他们在Deno 2发布前的重点工作方向：

• Node/npm兼容性已大幅提升

• 框架兼容性同样重要

• 实现Deno的任何地方部署

• 依赖管理的重大升级

• 迈向Deno 2的道路

Node/npm兼容性的显著进步

Deno团队了解到，对于某些用户而言，如果无法访问关键的npm模块或运行Node项目，可能会成为使用Deno的阻碍。因此，Deno团队在改善Node和npm兼容性方面投入了巨大的努力。调查结果显示，大多数受访者认为Deno已经在成为他们所有项目的默认运行时方面取得了长足的进步。但结果也表明，Deno团队在这方面还有更多工作要做。

重视框架兼容性

除了能够访问npm模块外，Deno团队还询问了运行第三方框架的重要性。约80%的受访者表示，第三方框架兼容性对他们的工作至关重要。虽然大多数人表示使用Deno运行第三方框架没有问题，但仍有一部分人遇到了困难，因此我们将在2024年把提高第三方框架兼容性作为重中之重。

任何地方部署Deno

使用Deno构建服务器和API仍然是一个主要用例，因此许多人选择在云中托管Deno并不令人惊讶。Deno团队很高兴地发现，近半数受访者在被问及在云中托管Deno项目的难易程度时选择了“强烈同意”。

依赖管理的重大升级

Deno推出时，提出了URL导入的激进想法，这在理论上是合理的。但他们遇到了问题——如果一个程序包含两个不同版本的模块怎么办？在模块图上调和这一点是一个复杂的工程问题。我们开发了像deps.ts这样的模式来管理远程依赖。但这仍然不是最佳方案，需要平铺并重新导出必要的符号，导致出现了一个更冗长和杂乱的package.json版本。

许多调查受访者同意依赖管理可以改进，并留下评论，要求提供管理依赖、去重传递依赖、更新依赖等方面的最佳实践。

迈向Deno 2

Deno团队感谢活跃的社区提供反馈并帮助Deno团队改善Deno，成为默认的JavaScript和TypeScript运行时。调查结果不仅强烈表明我们正走在正确的道路上，还帮助我们聚焦于对您来说重要的功能。

Deno团队计划在今年发布一个主要版本，将提供第三方框架兼容性、使用任何npm模块的能力，同时拥有一流的开发者体验。

Deno的旅程充满了挑战和机遇。随着Deno 2的逐步成型，Deno团队期待着能够解决社区中的痛点，并提供更加强大和灵活的工具，以支持现代开发者的需求。Deno团队致力于不断进步，旨在为开发者社区提供最佳的开发体验。让我们一同期待Deno未来的发展，并继续参与到这个充满活力的社区中来。

资讯详情：
https://deno.com/blog/2024-survey-results-and-roadmap

5、JSR (JavaScript Registry)：公共测试版现已开放

近日，由Ryan Dahl、Luca Casonato和Kevin Whinnery联合推出的JSR（JavaScript Registry）正式进入公共测试版。JSR致力于优化TypeScript的支持，并仅支持ES模块。它不仅能与Deno无缝配合，还能支持基于npm的项目（包括Node、Bun、Cloudflare Workers等），并且是完全开源且免费的。

安装与使用包：

对于Deno用户，安装包的命令如下：

deno add @luca/flag

对于npm（及类似npm的系统）用户，安装包的命令如下：

npx jsr add @luca/flag

使用包的方式与其他ES模块无异：

import { printProgress } from "@luca/flag";
printProgress();

为何及如何构建JSR：

• JavaScript作为全球默认的编程语言，无处不在。随着时间的推移，Node在过去15年中对JavaScript的普及起到了巨大的推动作用。而npm作为世界上最成功的包注册中心，拥有超过2.5百万的包和每月约2500亿次的下载量，对JavaScript生态的繁荣发展功不可没。

• ECMAScript模块和TypeScript的崛起。随着ECMAScript模块成为编写可复用JavaScript代码的网络标准，以及TypeScript为带来编译时类型检查的同时，也作为TC39出台最新JavaScript语言特性的试验田，JavaScript世界发生了翻天覆地的变化。

• Deno等新运行时的兴起。除了Node之外，如Deno、workerd（Cloudflare Workers）、Bun等新的JavaScript运行时不断涌现，它们在开发者体验、更贴近网络标准和设计权衡方面进行了创新。

• 构建JSR的设计目标。鉴于上述变化，我们认为是时候重新设想包注册中心应该如何工作了。JSR应该拥抱ESM作为JavaScript模块的网络标准，从TypeScript的角度出发进行设计，同时提供简单、快速且出色的开发者体验。它应该是免费和开源的，适用于JavaScript运行的任何地方，并在npm的成功基础上进一步发展，而不是分裂。

发布与使用JSR中的模块：

• 在JSR发布模块。模块作者可以专注于编写TypeScript代码，将其直接发布到JSR，无需构建步骤。JSR会自动处理API文档生成、为Node-like环境生成类型声明和转译等任务。

• 在项目中使用JSR模块。无论是在Deno项目还是npm类项目中，使用JSR模块都像使用其他ES模块一样简单。JSR还提供了从命令行发布自己的TypeScript和JavaScript模块的能力。

JSR的展望：

JSR不仅仅是Deno团队的努力成果，JSR团队希望它成为整个JavaScript生态系统的公共资源。JSR是以MIT许可证免费开源的，旨在为JavaScript和TypeScript开发者提供更高效的工具，无论他们的代码在哪里运行。通过JSR，JSR团队希望能够为未来15年的JavaScript社区创新提供动力，帮助开发者无论在哪里都能更高效地开发。

资讯详情：
https://deno.com/blog/jsr_open_beta

6、Jco 1.0：WebAssembly组件的JavaScript工具链

Bytecode Alliance宣布推出Jco 1.0——一款为WebAssembly组件及WASI 0.2设计的原生JavaScript WebAssembly工具链及运行时。Jco能够在Node.js内部原生运行Wasm组件，简化了使用不同编程语言编写的库在Node.js运行时执行的流程。通过实现完整的WASI 0.2 API表面，这些组件可以访问网络、文件系统以及Node.js运行时可用的其他系统API。

即将推出的特性：

• 支持浏览器（实验性可用）

• 将JavaScript编译为WebAssembly（实验性可用）

• 支持WebAssembly注册表（计划中）

Jco的目标：

Jco旨在成为JavaScript中所有与组件相关操作的综合工具。通过Jco 1.0，Bytecode Alliance稳定了一个用于Wasm组件的Node.js运行时，以及一个将其他语言编写的Wasm组件导入JavaScript的工具链。Bytecode Alliance希望继续稳定Jco的更多功能。一些功能目前处于实验阶段，包括原生浏览器支持，以及将JavaScript代码编译成WebAssembly的原生支持。其他如WebAssembly注册表的支持尚未开始，但我们预期将在后期添加。

在Bytecode Alliance的JavaScript工具链：

Jco是Bytecode Alliance的第三个JS工具链项目。以下是三个项目及其目前用途的快速概述：

• Javy：使用QuickJS JavaScript引擎构建的JavaScript → WASI 0.1编译器工具链。该工作在Wasm组件出现之前就已开始，但将来可能会添加支持。

• ComponentizeJS：使用SpiderMonkey JavaScript引擎构建的JavaScript → Wasm组件工具链，完全支持WASI 0.2。该项目较新，尚未被视为稳定。

• Jco：用于JavaScript的全面WebAssembly组件工具链及运行时。包括一个Wasm组件 → JS工具链，完全支持WASI 0.2。

使用Jco的优势：

Jco为WebAssembly组件提供了一个强大的JavaScript工具链和运行时，使得在Node.js环境中运行不同编程语言编写的库变得简单。通过实现WASI 0.2的全部API，Jco为Wasm组件提供了访问网络、文件系统和其他系统API的能力。随着对浏览器的支持、JavaScript到WebAssembly的编译以及对WebAssembly注册表的支持等特性的实验性推出和计划中的实现，Jco将为WebAssembly组件的开发和运行提供更广泛的平台和工具支持。

通过这种方式，Jco促进了不同编程语言之间的互操作性，为开发者在现代Web和Node.js生态中构建跨语言应用提供了强有力的支持。Jco的发布标志着WebAssembly在JavaScript生态中应用的一个重要里程碑，为开发者带来了新的可能性和便利。

资讯详情：
https://bytecodealliance.org/articles/jco-1.0

结束

通过对这六大前端技术更新的梳理，我们可以发现，无论是对开发工具的优化、新技术的尝试，还是对生态系统建设的探索，每一步进展都在为简化开发流程、提升开发体验，以及增强跨语言互操作性作出贡献。这些更新虽然在短期内可能需要开发者投入时间去学习和适应，但从长远看，它们无疑将为前端开发打开更多可能性，提高项目的质量和开发的效率。作为开发者，保持对新技术的好奇心和学习热情，不仅能够帮助我们把握行业脉搏，还能不断提升自己的技术竞争力。让我们一起期待并积极探索这些技术更新带来的新机遇。