隨著2024年3月的到來，前端技術領域迎來了一系列的更新和進步。 從 巴別塔 724.0 為 Parcel v2 帶來了裝飾器和 JSON 模組改進12.0，每次更新都反映了技術社群對前端開發便利性和效率的持續追求。 此外，軟體包元資料互操作性協作空間的建立、Deno 團隊的最新調查、JSR 的公開測試版和 JCO 10的推出，推動了不同維度前端技術的發展。 這些進步雖然各有各的重點，但共同構成了前端技術不斷進步的足跡。 在本文中，我們將逐一分析這六項技術亮點，並探討它們對開發人員和開發生態系統的潛在影響。
在這個瞬息萬變的前端世界中，我們一直在尋找更優雅的寫作和更高效的開發過程。 近日，Babel 團隊發布了 724.版本 0，它帶來了許多令人興奮的更新，特別是對裝飾器實現的更新，以匹配最新的建議版本，並改進了類的私有欄位和方法的轉換方式。 同時，他們還在瀏覽器和節點中新增了對支援在 JS 中匯入 JSON 模組，這是乙個依賴於匯入屬性功能的較舊的第 3 階段提案。
為裝飾者帶來新的觸感。
Decorator 是 ES2016（即 ES7）中提出的一種語法，用於修改類和類成員的行為，但直到現在仍處於提案階段。 在過去的幾年裡，裝飾器提案收到了一些小的更新，不幸的是，不同的工具實現了略有不同的版本。
babel 7.24.版本 0 更新了其裝飾器實現以匹配該提案的最新版本，該提案也已由 Typescript 實現，並在瀏覽器中本機實現。 與 2023-05 版本相比，最大的區別在於上下文初始值設定項的註冊順序。
JSON模組匯入：輕鬆管理配置。
另乙個亮點是對 JSON 模組提案的支援，該提案允許使用具有以下型別的模組："json"匯入屬性的匯入宣告直接匯入到 JSON 檔案中。 這意味著我們現在可以更輕鬆地管理配置檔案和資料，而不必依賴其他工具或編寫額外的 ** 來讀取 JSON。
最近發布的 Parcel v212.版本 0，它為前端開發人員帶來了令人興奮的新功能和改進。
巨集 - 用於編譯時生成的強大工具。
在 v2 中12.在版本 0 中，Parcel 引入了對巨集的支援。 這是乙個非常有趣的功能，它允許您在構建時使用普通的 j**ascript 函式來生成 **。 與執行時相比，巨集的執行完全發生在構建時，這意味著最終包將不包含巨集，而是巨集執行的結果。 這為效能優化和組織開闢了全新的可能性。
例如，巨集允許您在構建時生成優化的正規表示式，甚至可以根據特定規則動態生成其他資源。 這種在構建階段執行**的能力無疑為開發者解鎖了更多創新的遊戲玩法。
import regexgen from 'regexgen' with ;
const regex = regexgen(['foobar', 'foobaz', 'foozap', 'fooza']);
console.log(regex);
console.log(/foo(?:zap?|ba[rz])/);**REPL – 體驗包裹的魔力。
parcel v2.12.0 還帶來了乙個新的 **repl，這是乙個直接在瀏覽器中試用包裹的平台。 在這裡您可以編輯**、瀏覽檔案，甚至使用大部分地塊功能，例如觀察模式、開發伺服器、熱模組替換等。 這個 REPL 使用 Web Assembly、Service Worker、Web Worker 後端和 IndexedDB 等尖端 Web 技術，甚至可以通過執行編譯版的 Yarn 來安裝 npm 包。 這提供了一種非常方便的方式來快速試用包裹。
CSS** & 效能優化 - 更流暢的開發體驗。
在CSS處理方面，Parcel現在使用Lightning CSS來轉換和**CSS檔案。 這意味著更好地支援現代 CSS 功能，例如@import和級聯層次結構，改進了對查詢和支援查詢的支援，以及更好地處理複雜的 CSS 順序問題。
效能方面，Parcel v212.0 通過改進核心圖資料結構，將記憶體使用量降低約 52%，寫入效能提高約 5%。 對於非常大的應用程式，這意味著可以減少大約 800MB 的記憶體使用量，而不會對啟動、構建或關閉時間產生負面影響。
在 OpenJS 基金會下成立了乙個名為 Package Metadata Interoperability Collaboration Space 的中立行業組織，用於迭代 PackageJSON 的非正式標準化，並為應用程式開發人員提高 j**ascript 包元資料的互操作性。 這一新趨勢，不僅體現了科技界對提高開發效率、推動技術標準化的不懈追求，也體現了如何在快速增長的前端生態中，通過合作與共享來推動技術進步和創新。
為什麼包元資料互操作性如此重要？
在現代前端和全棧開發流程中，打包JSON 已成為配置 j**ascript 專案的事實標準。 它不僅定義了專案的元資料，還定義了專案的依賴項和配置。 然而，隨著不同 j**ascript 執行時和工具的出現，保持這些工具之間的元資料相容性和互操作性已成為一項挑戰。
OpenJS基金會的這一舉措旨在通過將不同的利益相關者聚集在一起，開發乙個滿足現有需求並具有一定的靈活性的技術框架，從而促進生態系統的健康發展和多樣性。
創新的呼喚：巨集觀視角的一攬子計畫json
隨著新的 j**ascript 執行時（如 deno）的出現，軟體包的執行時數量顯著增加有乙個關於 JSON 依賴項和評估的新討論。 Deno 的聯合創始人 Ryan Dahl 公開表達了他對 package 的興趣JSON，這也促使 Deno 團隊探索將 Deno 納入其中JSON格式。 儘管如此，Deno 還是在 2023 年增加了對該軟體包的支援JSON 支援以增強與 node 和 npm 的相容性，這一決定既是對歷史的妥協，也是對未來可能性的開放。
包元資料互操作性協作空間的任務。
這個合作空間不僅僅專注於改進軟體包JSON 的標準化和互操作性，更重要的是，它旨在通過研究現有的實踐和工具，挖掘它們的優勢和劣勢，並圍繞這些研究構建工具，為更廣泛的 JASCRIPT 生態系統提供乙個探索和實驗的平台。 這個過程旨在促進乙個更具包容性和多樣性的生態系統，不同的執行時和工具可以更好地協同工作。
最近，DENO 團隊發起了一項調查，重點關注改進 DENO 執行時的努力。 通過700多份回覆，我們不僅看到了DENO的進展情況，還確定了需要改進的領域。 以下是調查的主要見解，以及他們在 Deno 2 發布之前的重點：
節點 npm 相容性得到了極大的改進。
框架相容性同樣重要。
在任何地方部署 Deno。
依賴項管理的重大公升級。
通往 Deno 2 的道路。
顯著改進了節點 npm 相容性。
Deno 團隊明白，對於某些使用者來說，無法訪問關鍵的 npm 模組或執行節點專案可能是使用 Deno 的障礙。 因此，deno 團隊在提高 node 和 npm 相容性方面投入了大量精力。 調查結果顯示，大多數受訪者認為DENO在成為其所有專案的預設執行時方面取得了長足的進步。 但結果也表明，Deno團隊在這一領域還有更多工作要做。
強調框架相容性。
除了能夠訪問 npm 模組之外，Deno 團隊還詢問了執行第三方框架的重要性。 大約 80% 的受訪者表示，第三方框架相容性對他們的工作至關重要。 雖然大多數人說使用 Deno 執行第三方框架沒問題，但仍有一些人遇到困難，因此我們將在 2024 年將提高第三方框架相容性作為重中之重。
隨處部署 deno
使用 Deno 構建伺服器和 API 仍然是乙個主要的用例，因此許多人選擇在雲中託管 Deno 也就不足為奇了。 Deno 團隊很高興地發現，當被問及在雲中託管 Deno 專案有多容易時，近一半的受訪者選擇了“非常同意”。
依賴項管理的重大公升級。
當 Deno 推出時，提出了 URL 匯入的激進想法，這在理論上是合理的。 但是他們遇到了乙個問題——如果乙個程式包含兩個不同版本的模組怎麼辦？ 在模組圖上協調這一點是乙個複雜的工程問題。 我們開發了類似 deps 的東西TS 用於管理遠端依賴項。 但這仍然不是最佳選擇，需要平鋪和重新匯出必要的符號，從而導致包更加冗長和混亂JSON 版本。
許多受訪者同意依賴關係管理可以改進，並發表評論，詢問管理依賴關係、傳遞依賴關係的重複資料刪除、更新依賴關係等的最佳實踐。
朝向 Deno 2
Deno 團隊要感謝活躍社群的反饋，並通過成為預設的 j**ascript 和 typescript 執行時來幫助 Deno 團隊改進 Deno。 這些發現不僅有力地表明我們走在正確的道路上，而且還有助於我們專注於對您重要的功能。
Deno 團隊計畫在今年發布乙個主要版本，該版本將提供第三方框架相容性、使用任何 npm 模組的能力以及一流的開發人員體驗。
Deno的旅程充滿了挑戰和機遇。 隨著 Deno 2 的成型，Deno 團隊期待解決社群中的痛點，並提供更強大、更靈活的工具來支援現代開發者的需求。 DENO 團隊致力於持續改進，旨在為開發者社群提供最佳的開發體驗。 讓我們展望DENO的未來，並繼續成為這個充滿活力的社群的一部分。
近日，由 Ryan Dahl、Luca Casonato 和 Kevin Whinnery 聯合推出的 JSR（J**Ascript Registry）正式進入公測階段。 JSR 致力於優化 Typescript 支援，僅支援 ES 模組。 它不僅與 Deno 無縫協作，而且還支援基於 NPM 的專案（包括 Node、BUN、Cloudflare Workers 等），並且完全開源且免費。
安裝和使用包：
對於 deno 使用者，安裝軟體包的命令如下：
deno add @luca/flag對於 npm（和類似 npm 的系統）使用者，安裝包的命令如下：
npx jsr add @luca/flag該軟體包的使用方式與其他 ES 模組相同：
import from "@luca/flag";
printprogress();
J**Ascript，作為世界上預設的程式語言，是無處不在的。 隨著時間的流逝，在過去的 15 年裡，Node 極大地推動了 j**ascript 的流行。 而 npm 作為世界上最成功的包註冊中心，擁有超過 2 個500 萬個包裹和每月約 2500 億次，為 j**ascript 生態系統的繁榮和發展做出了貢獻。
ecmascript 模組和 Typescript 的興起。 隨著 eMascript 模組成為編寫可重用 j**ascript 的 Web 標準，以及 TypeScript 引入了編譯時型別檢查，以及 TC39 引入最新 j**ascript 語言特性的試驗場，J**Ascript 的世界發生了巨大變化。
deno 等新執行時的興起。 除了 Node 之外，Deno、Worker （Cloudflare Workers）、BUN 等新的 j**ascript 執行時也在不斷湧現，它們在開發人員體驗、更接近網路標準和設計權衡方面進行了創新。
構建 JSR 的設計目標。 鑑於這些變化，我們認為是時候重新構想軟體包登錄檔應該如何工作了。 JSR 應該將 ESM 作為 J**Ascript 模組的 Web 標準，從 Typescript 的角度進行設計，同時提供簡單、快速和出色的開發人員體驗。 它應該是自由和開源的，在j**ascript執行的任何地方都可以工作，並建立在npm的成功之上，而不是**。
在 JSR 中發布和使用模組：
在 JSR 中發布模組。 模組作者可以專注於編寫 TypeScript，並將其直接發布到 JSR，而無需構建步驟。 JSR 自動處理諸如 API 文件生成、類節點環境的型別宣告和翻譯等任務。
在專案中使用 JSR 模組。 無論是在 Deno 專案還是 NPM 類專案中，使用 JSR 模組都像使用其他 ES 模組一樣簡單。 JSR 還提供了從命令列發布自己的 Typescript 和 J**Ascript 模組的功能。
JSR的前景：
JSR 不僅僅是 DENO 團隊努力的結果，JSR 團隊希望它成為整個 JASCRIPT 生態系統的公共資源。 JSR 在 MIT 許可下是免費和開源的，旨在為 JASCRIPT 和 Typescript 開發人員提供更高效的工具，無論他們執行在什麼環境中。 通過 JSR，JSR 團隊希望在未來 15 年內推動 J**Ascript 社群的創新，並幫助開發人員更高效地開發，無論他們身在何處。
位元組碼聯盟宣布推出 JCO 10 - 乙個是 WebAssembly 元件和 wasi 02. 原生 j**ascript webassembly 工具鏈和執行時設計。 JCO能夠在Node上做到這一點JS 原生在內部執行 wasm 元件，簡化了 Node 中用不同程式語言編寫的庫js 執行時執行的程序。 通過實現完整的 WASI 02 API 面，這些元件可以訪問網路、檔案系統和節點JS 執行時提供的其他系統 API。
即將推出的功能：
支援的瀏覽器（實驗性）。
將 j**ascript 編譯為 webassembly（實驗性）。
支援 WebAssembly 登錄檔（計畫中）。
JCO的目標：
JCO 旨在成為 J**Ascript 中所有與元件相關的操作的綜合工具。 通過 JCO 10、位元組碼聯盟穩定乙個節點JS 執行時，以及將用其他語言編寫的 WASM 元件匯入 J**Ascript 的工具鏈。 位元組碼聯盟希望繼續穩定JCO的更多功能。 一些特性目前處於實驗階段，包括原生瀏覽器支援，以及原生支援將 J Ascript 編譯為 WebAssembly。 對 WebAssembly 登錄檔的其他支援尚未開始，但我們希望在稍後階段新增它。
位元組碼聯盟中的 j**ascript 工具鏈：
JCO是位元組碼聯盟的第三個JS工具鏈專案。 以下是這三個專案及其當前用途的快速概述：
j**y： j**ascript wasi 0. 使用 Quickjs j**ascript 引擎構建1編譯器工具鏈。 這項工作在 wasm 元件出現之前就開始了，但將來可能會新增支援。
ComponentizeJS：使用 Spidermonkey J**Ascript 引擎構建的 J**Ascript WASM 元件工具鏈，完全支援 WASI 02。該專案相對較新，尚未被認為是穩定的。
JCO：乙個全面的 WebAssembly 元件工具鏈和 J**Ascript 執行時。 包括乙個完全支援 WASI 0 的 wasm 元件 JS 工具鏈2。
使用JCO的優點：
JCO 為 WebAssembly 元件提供了強大的 JASCRIPT 工具鏈和執行時，使其可以在 Node 中使用在 JS 環境中執行用不同程式語言編寫的庫很容易。 通過實現 wasi 02 所有 API，JCO 都為 WASM 元件提供了訪問網路、檔案系統和其他系統 API 的能力。 隨著瀏覽器支援、對 WebAssembly 編譯的 J**ascript 以及對 WebAssembly 登錄檔的支援等特性的實驗性推出和計畫實現，JCO 將為 WebAssembly 元件的開發和運營提供更廣泛的平台和工具。
通過這種方式，JCO 促進了不同程式語言之間的互操作性，為開發人員提供了現代 Web 和 Node 方面的專業知識JS 生態系統為構建跨語言應用程式提供了強大的支援。 JCO 的發布標誌著 WebAssembly 在 J**Ascript 生態中應用的乙個重要里程碑，為開發者帶來了新的可能性和便利。
通過對這六項前端技術更新的梳理，我們可以發現，無論是開發工具的優化、新技術的實驗，還是生態建設的探索，每一步的進步都在為簡化開發流程、提公升開發體驗、增強跨語言互操作性做出貢獻。 雖然這些更新在短期內可能需要開發者投入時間去學習和適應，但從長遠來看，它們無疑會為前端開發開闢更多的可能性，提高專案的質量和效率。 作為開發者，保持對新技術的好奇心和熱情，不僅有助於我們把握行業脈搏，還可以不斷提高自身的技術競爭力。 讓我們一起期待並積極探索這些技術更新帶來的新機遇。