- WebAssembly (Wasm) reste une technologie clé utilisée dans divers produits réels, jouant un rôle important dans les moteurs de jeu, outils de design et conteneurs web
- Le langage lui-même possède une structure efficacement mappée au matériel moderne et a été conçu autour de la sécurité et de la portabilité
- Son modèle de sécurité repose sur une logique de refus par défaut (
deny-by-default), permettant une isolation au niveau du processus et une exécution rapide
- Il est exploité dans divers environnements grâce à un écosystème de plugins et au support cross-language, mais son adoption ne va pas encore jusqu’à remplacer l’ensemble du navigateur web
- Aujourd’hui, WebAssembly est profondément intégré au niveau des bibliothèques et des runtimes, tandis que la standardisation et l’extension de ses fonctionnalités progressent rapidement
Cas d’usage concrets
- WebAssembly assure des fonctions clés dans Godot, Figma, Stackblitz, Squoosh.app, Zellij, Ruffle
- Godot l’utilise pour les builds de jeux web, et Figma pour transformer du code C++ en une forme exécutable dans le navigateur
- Stackblitz s’en sert pour les conteneurs web, et Ruffle comme émulateur Flash basé sur Wasm
- Cependant, les grands sites entièrement construits sur Wasm restent rares ; dans la plupart des cas, il est utilisé pour des fonctionnalités ciblées
Définition et vitesse de WebAssembly
- WebAssembly est un langage, et n’a pas de notion de vitesse en soi : ses performances dépendent du moteur d’exécution
- Comme pour JavaScript, ce sont les moteurs runtime (V8, SpiderMonkey, etc.) qui déterminent la vitesse d’exécution
- WebAssembly présente une structure efficacement mappée au matériel moderne, et peut être compilé ou interprété
Une structure conçue pour un mappage efficace
- Wasm est un bytecode proche du langage assembleur, qui peut être compilé vers la plupart des architectures matérielles sans perte significative
- WAT (WebAssembly Text) est la représentation textuelle de Wasm, avec une conversion presque 1:1
- Il ressemble au bytecode de la JVM, mais avec une API plus petite et des garanties de sécurité plus fortes
- Les accès mémoire sont explicites, et seules les ressources autorisées par l’environnement hôte peuvent être utilisées
Wasm comme cible de compilation
- De nombreux langages comme Rust, C, Zig, Go, Kotlin, Java, C# peuvent être compilés en Wasm
- Même des langages interprétés comme Python, PHP, Ruby peuvent s’exécuter via des builds Wasm
- Les navigateurs intègrent nativement un moteur Wasm, et il existe aussi des runtimes indépendants comme Wasmtime, WasmEdge, Wasmer
- Un artefact Wasm unique peut être exécuté de manière indépendante du matériel
Architecture de sécurité et usages
- WebAssembly adopte un modèle de sécurité “deny-by-default”, où seuls les accès externes explicitement importés sont autorisés
- Une pile de contrôle cachée, une mémoire linéaire et un jeu d’instructions limité assurent une isolation forte
- Cloudflare isole l’exécution de code Wasm à l’aide de V8 isolates, tandis que Fermyon offre des temps de démarrage de l’ordre de la sous-milliseconde
- Ruffle restaure en toute sécurité des contenus Flash, Pyodide exécute Python en Wasm, et Figma fait tourner ses plugins via QuickJS basé sur Wasm
Portabilité et embarquement
- Les runtimes Wasm sont légers, et Zellij, Envoy, Lapce ont adopté Wasm pour leurs systèmes de plugins
- Même dans les environnements disposant d’un moteur JavaScript, on peut utiliser diverses bibliothèques Wasm pour le traitement d’image, l’OCR, les moteurs physiques, le rendu, les toolkits multimédias, les bases de données et les parseurs
- Dans la plupart des cas, les utilisateurs ne se rendent même pas compte que Wasm est utilisé : il fonctionne de manière transparente à l’intérieur des bibliothèques
Réévaluer la vitesse et la taille
- Les navigateurs exécutent Wasm via le même pipeline que JS, ce qui implique des limites de performance liées à l’architecture du moteur
- L’efficacité varie selon le système de types du langage et le niveau d’optimisation du compilateur
- Le coût de la frontière entre l’hôte et le programme ainsi que l’augmentation de la taille des binaires sont souvent cités comme inconvénients
- Le standard WASI tente d’atténuer cela, mais la standardisation du type chaîne de caractères n’est pas encore achevée
- Zig produit les plus petits binaires Wasm
- En environnement natif, les threads, les E/S et l’utilisation mémoire peuvent entraîner une baisse des performances
Tendances de développement des langages et des standards
- La standardisation de Wasm progresse en parallèle via le groupe de travail du W3C et la Bytecode Alliance
- Cette dernière pilote notamment le développement d’outils comme WIT et le Component Model
- Les propositions de nouvelles fonctionnalités sont adoptées rapidement, même si certains débattent du rythme et de l’orientation du projet
- Wasm se diffuse davantage comme technologie d’intégration interne que comme remplaçant de JavaScript
- Des frameworks comme Blazor et Leptos exploitent Wasm sans manipuler directement JS
- Aujourd’hui, Wasm est principalement adopté par les auteurs de bibliothèques, et les développeurs généralistes peuvent l’utiliser sans avoir à en connaître le fonctionnement interne
- La difficulté des ressources pédagogiques est pointée comme un frein à l’apprentissage, et des projets éducatifs comme
watlings sont mentionnés
Aucun commentaire pour le moment.