Sortie de Wasmer 5.0

Nouveau backend expérimental

• Ajout de la prise en charge de V8, Wasmi et WAMR
• Il est désormais possible d’intégrer facilement à Wasmer n’importe quel interpréteur ou runtime compatible avec la spécification Wasm-C-API
• L’intégration de V8 offre une excellente expérience de débogage via le débogueur V8 et Chrome Devtools
• Utiliser V8 comme backend signifie également bénéficier nativement de la prise en charge des exceptions WebAssembly et du garbage collection

Prise en charge d’iOS (via des bindings WAMR, Wasmi et V8)

• Wasmer apporte WebAssembly aux appareils iOS grâce à un nouveau mode interpréteur
• En s’appuyant sur les capacités de V8, Wasmi et WebAssembly Micro Runtime (WAMR), les développeurs peuvent désormais exécuter sans difficulté des modules WebAssembly sur iOS
• Aucune modification du codebase n’est nécessaire, ce qui permet de créer des applications hautes performances dans l’écosystème Apple

Allègement du codebase

• Pour la sortie de Wasmer 5.0, l’accent a été mis sur un codebase aussi léger que possible
• Certaines dépendances utilisées par Wasmer n’étaient plus maintenues depuis longtemps ou faisaient doublon avec des crates plus récentes et plus sûres
• Comme les bindings Emscripten n’étaient pratiquement plus utilisés depuis deux ans, leur support a été abandonné et les dépendances ont été nettoyées, ce qui a permis de supprimer au total 20 000 lignes de code du codebase de Wasmer

Améliorations des performances

• La désérialisation des modules est désormais jusqu’à 50 % plus rapide (c’est-à-dire lors d’un appel à Module::deserialize ou lors de l’exécution d’un module via wasmer run)
• Ces améliorations s’appuient sur une mise à jour majeure de rkyv, la bibliothèque de désérialisation zero-copy utilisée pour désérialiser les modules

Compilateurs mis à niveau : Cranelift et LLVM 18

• L’intégration de la dernière version de Cranelift améliore fortement la vitesse d’exécution, permettant aux modules WebAssembly de fonctionner plus rapidement que jamais
• Wasmer 5.0 inclut désormais la version la plus récente de LLVM (18), donnant aux développeurs accès aux dernières optimisations de la toolchain
• La mise à niveau de LLVM améliore la compatibilité et les performances, fournissant une base solide pour compiler et exécuter des modules WebAssembly complexes
• Wasmer 5.0 est également livré avec une prise en charge expérimentale de LoongAarch64
• Les benchmarks coremark réalisés avec les dernières versions des compilateurs montrent qu’avec Wasmer v5.0, LLVM et Cranelift sont environ 8 % plus rapides que sur Wasmer v4.4.0

L’avis de GN⁺

• La sortie de Wasmer 5.0 semble constituer une étape majeure pour l’écosystème WebAssembly. En particulier, la prise en charge d’iOS et l’offre de plusieurs options de backend devraient élargir considérablement le champ d’application de WebAssembly jusqu’aux applications mobiles
• En prenant en charge comme backend différents runtimes tels que V8, Wasmi et WAMR, les développeurs peuvent désormais choisir celui qui correspond le mieux à leurs besoins. Cela devrait contribuer de manière significative à renforcer la flexibilité et la compatibilité de WebAssembly
• Les efforts d’optimisation des performances via l’allègement du codebase et l’adoption de compilateurs plus récents méritent également d’être soulignés. Cela montre que Wasmer ne se contente pas d’ajouter des fonctionnalités, mais s’attache aussi à améliorer continuellement la qualité
• L’abandon du support des bindings Emscripten est un point regrettable, mais il semble être un choix rationnel dans la mesure où leur nécessité a diminué avec l’émergence de nouveaux standards comme WASI et WASIX
• Dans l’ensemble, Wasmer 5.0 est une release qui illustre bien l’évolution de WebAssembly, et Wasmer devrait continuer à s’imposer comme l’un des projets majeurs de l’écosystème WebAssembly. Cela dit, des efforts continus semblent encore nécessaires pour améliorer la stabilité et la maturité des fonctionnalités encore expérimentales

[GN⁺]

Avis sur Hacker News

• Les graphiques de performance sont confus et ont l’air maudits. Certains sont affichés en échelle logarithmique et, dans certains cas, il est difficile de comprendre ce qu’ils cherchent à dire. Par exemple, le graphique « Argon 2 » montre presque toutes les barres avec la même longueur, alors que chaque barre affiche un chiffre différent en millisecondes.
• L’utilisation de V8 comme backend apporte la prise en charge de la gestion des exceptions WebAssembly et du ramasse-miettes. J’attends avec intérêt davantage de nouvelles à ce sujet. Je me demande si wasm-gc permet de partager des données/chaînes hôte entre différents modules au sein d’un même runtime, ou si cela reste limité à un seul module.
• Sur la landing page de Wasmer, il est difficile de comprendre ce que fait le produit. Ils disent faire tout tourner partout, mais ce qu’ils font concrètement n’est pas clair. Cela ressemble à un produit orienté développeurs, mais il y a plus de buzzwords que d’explications techniques.
• Je suis satisfait de Wasmtime et je bricole actuellement avec le modèle de composants WASM et un système de plugins basé sur WASI. C’est amusant à développer.
• Je n’ai pas encore trouvé de bon cas d’usage pour WASM dans mes projets. C’est un peu comme avec le Raspberry Pi quand on ne sait pas vraiment quoi en faire. Je ne vois pas clairement pourquoi je choisirais WASM pour un projet Rust asynchrone.
• J’aimerais qu’il existe une solution qui ne nécessite pas les en-têtes Cross-Origin Isolated. J’utilise encore une ancienne version.
• Je me demande si WASM peut servir d’alternative moins gourmande en ressources aux applications Electron. WASM n’a pas d’accès au DOM, mais je me demande si cela pourrait être ajouté via des extensions.
• Je ne sais pas quel problème cette solution résout. Tous les runtimes JavaScript n’intègrent-ils pas déjà un moteur WASM ?
• Je me demande si cette solution permet d’évaluer du code Node.js en toute sécurité dans un sandbox.
• Les graphiques de performance sont difficiles à lire. Les séparateurs de milliers utilisent à la fois des virgules et des points, et la précision est arrondie de manière arbitraire à 1, 2 ou 3 chiffres.