這會是一篇簡短的文章......但希望後續能有更長的文章。
寒假期間我有時間做了一個實驗：
使用 C#/.NET 創建的 Web 工具能否產生與 Rust / Go / Zig ...相當的效能？
所以我做了一些編碼...（你可以在 GitHub 上找到）
我從一個粗略的捆綁器邏輯開始：
結果很簡單：使用 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中文網其他相關文章！
