網路封包

這會是一篇簡短的文章......但希望後續能有更長的文章。

寒假期間我有時間做了一個實驗：

使用 C#/.NET 創建的 Web 工具能否產生與 Rust / Go / Zig ...相當的效能？

所以我做了一些編碼...（你可以在 GitHub 上找到）

過程

我從一個粗略的捆綁器邏輯開始：

• 開啟檔案
• 閱讀他們的內容
• 使用正規表示式來偵測，例如 JS 檔案中的 import 語句
• 解析連結模組
• 開啟已解析/現有的 package.json 檔案以識別模組路徑

結果很簡單：使用 AoT（提前編譯）.NET 當然可以用於高效能的 Web 專案。

所以我繼續做了一點實驗；用實際的程式碼理解來取代正規表示式。

太長了；結果

答案是：是的！ ？

捆綁器目前功能不完整，但第一個結果非常強大。自述文件中顯示的基準表明其性能絕對與其他工具處於同一水平。夠快了。

更多詳情

就我個人而言，我認為 C#/.NET 比 Rust 簡單得多，而且比 Go 更強大。它也有一些缺點 - 不是說謊。

C#/.NET 能夠在該領域可行的主要原因是 AoT。如果沒有 AoT，啟動效能（以及運行時要求）就會扼殺整個想法。

另一方面，AoT 也帶來了一些挑戰。有些庫無法使用或需要進行一些工作才能整合。因此，.NET 的一些彈性無法使用。

對於 rspack 等工具也使用的最大測試項目，我們得到以下結果：

請注意，即使捆綁器的功能不完整，但它的設計足以在專案上產生有效的結果。因此，儘管目前所有結果都是初步的，但至少有一定的有效性。

Test	esbuild	rspack	Vite	網路封包
Small lib	326ms	611ms	601ms	359ms
Small project	670ms	912ms	1658ms	418ms
Medium project	1931ms	2877ms	10601ms	974ms
Large project	2189ms	2422ms	13710ms	1357ms

所以，是的，網路封包 已經擊敗了競爭對手，甚至有可能獲得更好的性能。雖然它可以進一步優化，但當引入諸如來源映射或樹搖動之類的東西時，它也會損失一些效能。現在我確信，由於潛在的最佳化（例如 JS AST 生成中的串流），總體上應該與現在大致相同。

目前最大的障礙是它只支援 JS(X) - 還沒有 TypeScript （它嘗試解析這些文件，但一旦使用類型就會失敗）。它「相當」容易支持，但我需要為此分叉 Acornima，而且只有當該專案有足夠的討論度時我才會這樣做。

前景

還有很多事情可以參與其中，那就太好了。不過，需要先弄清楚一些基礎知識。諸如來源映射、TypeScript 支援或配置系統之類的東西會很棒。

這個實驗中有一些其他捆綁器沒有做的事情。例如，如果您的 HTML 入口點有一個導入映射，那麼導入映射中的條目將自動視為外部。同樣，您可以將某些依賴項設定為共用 - 在這種情況下，會自動產生導入映射條目/在生成的 HTML 中建立導入映射。相當整潔。

將來，捆綁器將對 SASS、CSS 模組、CSS-in-JS 以及模組聯合和本機聯合提供本機（即開箱即用）支援。

你有什麼想法？您認為這是一個可行的想法還是只是垃圾？我們需要一個具有合理預設值的快速 .NET 原生捆綁器嗎？

以上是網路封包的詳細內容。更多資訊請關注PHP中文網其他相關文章！