Que s’est-il passé avec WebAssembly ?
(emnudge.dev)- 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
watlingssont mentionnés
1 commentaires
Avis sur Hacker News
Je pense que Wasm a atteint la plupart des objectifs fixés à sa création.
Personnellement, j’ai utilisé Wasm comme composant central dans des dizaines de projets.
Les moteurs JS sont très rapides, mais Wasm offre toujours un niveau de contrôle CPU élevé et d’excellentes performances.
En revanche, il n’a pas répondu aux attentes selon lesquelles il remplacerait complètement JS+HTML+CSS. L’absence de liaisons DOM en est, à mon avis, une raison majeure.
J’ai aussi essayé des frameworks Wasm comme Yew, mais cela donnait l’impression d’une couche maladroite ajoutée par-dessus JS.
Je n’ai pas encore testé Blazor, mais je reste plus à l’aise avec du code écrit en JS.
Cela dit, Wasm tourne discrètement à de nombreux endroits, et je pense que c’est la véritable preuve de son succès.
Par exemple, la fonction de changement de vitesse audio dans le navigateur n’atteint ce niveau de performance qu’en exécutant une bibliothèque C++ via Wasm.
Dès qu’on aura de vraies liaisons DOM, JS sera évincé du frontend en moins de 10 ans.
C# facilite le partage de code entre backend et frontend, et les templates Razor bénéficient d’un bon support IDE.
Mais il faut embarquer l’intégralité du CLR et de la BCL de .NET, ce qui alourdit fortement le bundle.
Comme l’accès au DOM est difficile, Blazor adopte une architecture avec un petit moteur de rendu Virtual DOM côté JS.
Les performances sont correctes, mais cela reste plus lent que du JS écrit à la main.
Bolero, basé sur F#, est aussi intéressant, mais difficile à faire accepter à l’équipe.
Pour interagir avec le DOM, il faut un langage de haut niveau adapté.
JS remplit bien ce rôle, et l’ensemble HTML/CSS/JS est déjà devenu la langue commune du développement UI.
Il existe aussi des tentatives d’abandonner le rendu du navigateur pour passer à des approches basées sur canvas, mais cela reste un créneau de niche.
Un monde où même un site web simple exigerait de télécharger un runtime de plusieurs Mo serait horrible.
En réalité, la lenteur ne vient pas de JS mais du DOM, puisque tout doit de toute façon interagir avec lui.
J’ai travaillé plusieurs années sur WebAssembly et je prévois de publier bientôt un framework basé sur Wasm.
L’écosystème progressait rapidement, puis a soudainement ralenti, et l’introduction de WASI et du Component Model a semé la confusion.
Le niveau de support varie selon les moteurs, ce qui oblige souvent à jongler entre documentation, code et issues.
Le plus gros problème est le support de JS/TS. Aujourd’hui, l’intégration ressemble à du bricolage proche du hack, donc elle n’est pas stable.
Web Containers ont apporté des améliorations, mais beaucoup de développeurs sont déjà partis vers Bun.
Le potentiel de Wasm est énorme.
En théorie, il pourrait devenir la cible de compilation commune à toutes les plateformes.
Mais en pratique, on en est surtout à accélérer certaines fonctionnalités de Figma, ce qui est un peu décevant.
Le développement piloté par des comités en limite aussi la vitesse.
À l’époque de Native Client, on pouvait envisager des applications à vitesse native, alors qu’aujourd’hui Wasm est plus lent.
On aurait pu appliquer à Wasm le même modèle de liaisons que celui utilisé pour JS, ce qui est regrettable.
En plus, Wasm n’est même pas plus rapide que JS.
HTML/CSS/JS ont déjà prouvé leur utilité, tandis que Wasm reste encore une stack technique peu familière.
L’écosystème centré sur Docker freine les choses.
Beaucoup d’outils de build de l’écosystème JS sont écrits en Rust, et certains s’exécutent dans le navigateur via Wasm.
L’écosystème React ou npm utilise aussi Wasm en interne.
Si Wasm disparaissait, le monde du frontend JS serait fortement secoué.
En revanche, les frameworks UI natifs pour Wasm restent encore insuffisants.
Ils doivent dépendre du DOM et du CSS, et passer par JS pour accéder aux API du navigateur, ce qui est inefficace.
On peut contrôler le DOM avec Rust ou Kotlin, mais Rust est trop bas niveau pour le frontend.
Le cross-compiling mobile devient de plus en plus courant, et JetBrains Compose Multiplatform en est un exemple.
Ce qui freine l’évolution de Wasm, c’est le tooling.
Le débogage en est encore au niveau du
printf, et le plugin DWARF de Chrome n’a plus été mis à jour depuis longtemps.Le processus consistant à produire des fichiers .wasm par langage puis à configurer les import/export est complexe.
Le support du GC n’est pas complet non plus, si bien que des écosystèmes comme .NET doivent embarquer leur propre GC.
WIT ressemble à une nouvelle tentative de COM/CORBA/gRPC.
Emscripten est complexe et instable, et wasi-sdk manque de fonctionnalités.
Ni LLVM ni les moteurs ne sont réellement bien optimisés, et le tooling Wasm de Rust est en pratique à l’arrêt.
Il n’existe même pas de moyen standard d’importer un module Wasm depuis JS.
Le support du multithreading exige en plus de configurer des en-têtes COOP/COEP, ce qui le rend impossible sur GitHub Pages.
Si le tooling avait dépassé le stade de la « démo technique », Wasm serait bien plus utilisé.
Dans notre entreprise Leaning Technologies, nous utilisons activement Wasm.
Avec WebVM, nous exécutons des binaires x86 dans le navigateur,
avec BrowserCraft, nous lançons des applications Java (y compris Minecraft),
et avec BrowserPod, nous faisons tourner des conteneurs Node.js dans le navigateur.
C’est très puissant, mais ce sont des outils pour power users. Compiler une logique frontend classique en Wasm reste inefficace.
Le rythme de progression de CheerpJ est impressionnant, et certains pensent que si cela était arrivé 10 ans plus tôt, la plateforme web aurait été différente.
Pour ceux qui n’aiment pas JS, le vrai attrait de Wasm est justement de pouvoir créer des sites web sans JS.
Je travaille sur Dioxus, un framework Wasm basé sur Rust.
Sur le frontend Wasm, le problème venait du manque d’outils de base : découpage des bundles, hot reload, symboles de débogage, intégration des assets, etc.
En 2025, beaucoup de ces points ont été améliorés, et l’intégration avec des outils comme Vite s’est aussi améliorée.
Grâce aux outils d’IA, la vitesse de développement en Rust a augmenté, et j’espère que les frameworks Wasm attireront davantage l’attention à l’avenir.
Certains ont souligné que la taille binaire de Wasm était trop importante.
Dans un environnement DSL, le téléchargement peut prendre de quelques secondes à plusieurs minutes.
Selon eux, JS est plus léger et peut s’exécuter pendant le téléchargement.
Avec un build Rust, on peut descendre à 10 à 100 KB.
JS ne s’exécute pas pendant le téléchargement, et Wasm peut démarrer plus vite grâce à la compilation en streaming.
Cela revient en partie à réimplémenter des fonctions déjà fournies par le navigateur.
Par exemple, FSHistory implémente une émulation x86 en 24 KB.
En revanche, les écosystèmes natifs ne sont pas habitués à optimiser la taille du code.
L’affirmation de l’article selon laquelle « il n’existe pas de grand site web construit avec Wasm » ne correspond pas à mon expérience.
L’objectif des projets Wasm n’a jamais été de remplacer l’ensemble d’une web app.
J’ai l’impression que beaucoup de gens se sont forgé de mauvaises attentes et demandent ensuite pourquoi cela n’a pas marché.
J’ai réellement appliqué Wasm dans plusieurs cas d’usage concrets.
On peut traiter cela côté backend en ne renvoyant que les parties nécessaires.