Maison > interface Web > js tutoriel > pack réseau

pack réseau

Mary-Kate Olsen
Libérer: 2025-01-10 08:29:43
original
819 Les gens l'ont consulté

Ce sera un article court... mais j'espère qu'il y aura un suivi plus long.

Pendant mes vacances d'hiver, j'ai eu le temps de faire une expérience :

Les outils Web créés à l'aide de C#/.NET peuvent-ils offrir des performances comparables à celles de Rust / Go / Zig... ?

J'ai donc fait du codage... (que vous pouvez retrouver sur GitHub)

Le processus

J'ai commencé avec une logique de bundler grossière :

  • Ouvrir les fichiers
  • Lire leur contenu
  • Utilisez une expression régulière pour détecter, par exemple, les instructions d'importation dans les fichiers JS
  • Résoudre les modules liés
  • Ouvrez les fichiers package.json résolus/existants pour identifier les chemins des modules

Le résultat a été simple : l'utilisation d'AoT (compilation anticipée) .NET peut certainement être utilisée pour des projets Web très performants.

J'ai donc continué un peu l'expérience ; remplacer les expressions régulières par une compréhension réelle du code.

TLDR ; Résultats

La réponse est : oui ! ?

Le bundler est pour le moment incomplet en termes de fonctionnalités, mais les premiers résultats sont assez solides. Les références présentées dans le README indiquent que les performances sont définitivement dans la même fourchette que celles des autres outils. Donc assez vite.

Plus de détails

Personnellement, je pense que C#/.NET est beaucoup moins compliqué que Rust et plus puissant que Go. Cela comporte également quelques inconvénients - je ne vais pas mentir.

La principale raison pour laquelle C#/.NET peut être viable dans cet espace est l'AoT. Sans AoT, les performances de démarrage (ainsi que les exigences d'exécution) tuent toute l'idée.

L'AoT, en revanche, comporte certains défis. Certaines bibliothèques ne peuvent pas être utilisées ou nécessitent un certain travail pour être intégrées. Par conséquent, une partie de la flexibilité de .NET ne peut pas être utilisée.

Pour le plus grand projet de test également utilisé par des outils tels que rspack, nous obtenons ces résultats :

pack réseau

Notez que même le bundler est incomplet, il est suffisamment conçu pour produire un résultat valide sur le projet. Ainsi, même si tous les résultats sont pour le moment préliminaires, ils ont au moins une certaine validité.

Test esbuild rspack Vite pack réseau
Small lib 326ms 611ms 601ms 359ms
Small project 670ms 912ms 1658ms 418ms
Medium project 1931ms 2877ms 10601ms 974ms
Large project 2189ms 2422ms 13710ms 1357ms

Alors oui, pack réseau bat déjà la concurrence et a même un potentiel pour des performances encore meilleures. Bien qu'il puisse être optimisé davantage, il perdra également certaines performances lorsque des éléments tels que les sourcesmaps ou le tremblement d'arbres seront introduits. À l'heure actuelle, je suis convaincu qu'au total, cela devrait être à peu près le même à partir de maintenant en raison des optimisations potentielles (comme le streaming dans la génération JS AST).

Le plus gros obstacle pour le moment est qu'il ne prend en charge que JS(X) - pas encore TypeScript (il essaie d'analyser ces fichiers, mais une fois les types utilisés, il échouera). Ce serait "assez" facile à soutenir, mais je devrais faire appel à Acornima pour cela et c'est quelque chose que je ne ferais que s'il y a suffisamment de buzz autour du projet.

Perspectives

Il y a bien d’autres choses qui seraient superbes pour se lancer là-dedans. Cependant, certaines bases doivent d’abord être clarifiées. Des éléments tels que des sourcesmaps, la prise en charge de TypeScript ou peut-être un système de configuration seraient formidables.

Il y a certaines choses dans cette expérience qu'aucun autre bundler ne fait. Par exemple, si votre point d'entrée HTML a un importmap, alors les entrées dans l'importmap sont automatiquement prises comme externes. De même, vous pouvez définir certaines dépendances comme partagées - dans ce cas, il y a automatiquement des entrées importmap / une importmap créée dans le HTML résultant. Assez soigné.

À l'avenir, le bundler aura un support natif (c'est-à-dire prêt à l'emploi) pour SASS, les modules CSS, CSS-in-JS, ainsi que la fédération de modules et la fédération native.

Quelles sont vos pensées ? Pensez-vous que c'est une idée viable ou simplement une poubelle ? Avons-nous besoin d'un bundler natif .NET rapide avec des valeurs par défaut raisonnables ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

source:dev.to
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Derniers articles par auteur
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal