Dies wird ein kurzer Beitrag sein...aber hoffentlich folgt ein längerer Beitrag.
Während meines Winterurlaubs hatte ich etwas Zeit für ein Experiment:
Können mit C#/.NET erstellte Webtools eine vergleichbare Leistung wie Rust / Go / Zig ... erzielen?
Also habe ich etwas programmiert... (das Sie auf GitHub finden können)
Ich habe mit einer groben Bundler-Logik begonnen:
Das Ergebnis war einfach: Mit AoT (Ahead-of-Time-Compilation) kann .NET durchaus für leistungsstarke Webprojekte verwendet werden.
Also fuhr ich noch ein wenig mit dem Experiment fort; Ersetzen regulärer Ausdrücke durch tatsächliches Codeverständnis.
Die Antwort lautet: Ja! ?
Der Bundler ist derzeit funktionsunvollständig, aber die ersten Ergebnisse sind recht überzeugend. Die in der README-Datei gezeigten Benchmarks zeigen, dass die Leistung definitiv mit der anderer Tools vergleichbar ist. Also schnell genug.
Ich persönlich denke, dass C#/.NET viel weniger kompliziert als Rust und leistungsfähiger als Go ist. Es bringt auch einige Nachteile mit sich – das will nicht lügen.
Der Hauptgrund, warum C#/.NET in diesem Bereich lebensfähig sein kann, ist AoT. Ohne AoT macht die Startleistung (sowie die Laufzeitanforderungen) die ganze Idee zunichte.
AoT hingegen bringt einige Herausforderungen mit sich. Einige Bibliotheken können nicht verwendet werden oder erfordern einen gewissen Aufwand für die Integration. Daher kann ein Teil der Flexibilität von .NET nicht genutzt werden.
Für das größte Testprojekt, das auch von Tools wie rspack verwendet wird, erhalten wir diese Ergebnisse:
Beachten Sie, dass der Bundler zwar unvollständig ist, aber ausreichend gestaltet ist, um ein gültiges Ergebnis für das Projekt zu erzielen. Obwohl alle Ergebnisse derzeit vorläufig sind, haben sie zumindest eine gewisse Gültigkeit.
Test | esbuild | rspack | Vite | Netpack |
---|---|---|---|---|
Small lib | 326ms | 611ms | 601ms | 359ms |
Small project | 670ms | 912ms | 1658ms | 418ms |
Medium project | 1931ms | 2877ms | 10601ms | 974ms |
Large project | 2189ms | 2422ms | 13710ms | 1357ms |
Also ja, Netpack schlägt die Konkurrenz bereits und hat sogar Potenzial für eine noch bessere Leistung. Obwohl es weiter optimiert werden kann, wird es auch etwas an Leistung verlieren, wenn Dinge wie Sourcemaps oder Tree Shaking eingeführt werden. Im Moment bin ich mir sicher, dass es aufgrund der möglichen Optimierungen (z. B. Streaming in der JS AST-Generation) insgesamt in etwa gleich bleiben sollte.
Die größte Hürde besteht derzeit darin, dass es nur JS(X) unterstützt – noch kein TypeScript (es versucht, diese Dateien zu analysieren, aber sobald Typen verwendet werden, schlägt es fehl). Es wäre „ziemlich“ einfach zu unterstützen, aber dafür müsste ich Acornima abspalten, und das würde ich nur tun, wenn das Projekt genug Aufsehen erregt.
Es gibt noch viele weitere Dinge, die großartig wären, wenn man sich darauf einlassen würde. Allerdings müssen zunächst einige Grundlagen geklärt werden. Dinge wie Sourcemaps, TypeScript-Unterstützung oder vielleicht ein Konfigurationssystem wären großartig.
Es gibt einige Dinge in diesem Experiment, die kein anderer Bundler macht. Wenn Ihr HTML-Einstiegspunkt beispielsweise über eine Importmap verfügt, werden die Einträge in der Importmap automatisch als externe Einträge übernommen. Ebenso können Sie bestimmte Abhängigkeiten als geteilt festlegen – in diesem Fall werden im resultierenden HTML automatisch Importmap-Einträge / eine Importmap erstellt. Ganz ordentlich.
In Zukunft wird der Bundler native (d. h. sofort einsatzbereite) Unterstützung für SASS, CSS-Module, CSS-in-JS sowie Modul-Föderation und native Föderation bieten.
Was denken Sie? Halten Sie das für eine realisierbare Idee oder einfach nur für Müll? Brauchen wir einen schnellen .NET-nativen Bundler mit sinnvollen Standardeinstellungen?
Das obige ist der detaillierte Inhalt vonNetpack. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!