Faire de WebAssembly un langage de première classe sur le Web

• Depuis son lancement initial en 2017, WebAssembly a progressé en prenant en charge l’exécution de langages bas niveau comme C/C++, mais il est toujours traité comme un langage de seconde zone sur la plateforme Web
• Seul JavaScript peut interagir directement avec les API Web, et WebAssembly doit pour cela s’appuyer sur un code de liaison JS complexe (glue code)
• Cette structure entraîne une procédure de chargement complexe, un surcoût de performance et une rupture des toolchains selon les langages, ce qui dégrade l’expérience développeur
• Pour résoudre ce problème, Mozilla propose le WebAssembly Component Model, qui permet d’appeler les API Web et de charger des modules de manière standardisée sans JavaScript
• Si ce modèle s’impose, WebAssembly pourrait devenir un environnement d’exécution de première classe dans le navigateur, ouvrant la voie à une adoption plus simple par les développeurs généralistes

---

Pourquoi WebAssembly est traité comme un langage de seconde zone

• WebAssembly ne peut accéder à la plateforme Web qu’à travers JavaScript, sans droit d’appel direct aux API Web
  • JavaScript se charge simplement via une balise <script>, alors que WebAssembly nécessite un processus de chargement manuel via l’API JS
  • Il faut passer par des appels d’API complexes comme WebAssembly.instantiateStreaming(), que les développeurs doivent mémoriser ou automatiser via des outils
• La proposition esm-integration simplifie ce chargement en permettant d’importer directement des fichiers .wasm via le système de modules JS
  • Chargement direct possible sous la forme <script type="module" src="/module.wasm"></script>

Les limites d’accès aux API Web

• Là où une simple ligne console.log("hello, world") suffit en JavaScript, WebAssembly exige une procédure complexe impliquant accès à la mémoire JS, décodage de chaînes et encapsulation de fonctions
  • WebAssembly ne peut ni accéder à l’objet console ni au DOM ; il doit donc passer par des appels indirects via partage mémoire et import/export de fonctions côté JS
• Le code de liaison (glue code) généré dans ce processus diffère selon les langages et est produit automatiquement par des outils comme embind ou wasm-bindgen
  • Mais cela entraîne une plus grande complexité de build, un surcoût à l’exécution et des incompatibilités entre langages

Les causes techniques qui empêchent WebAssembly de devenir un langage de première classe

• Difficulté d’intégration des compilateurs : le compilateur de chaque langage doit générer séparément le code d’intégration avec JS et la plateforme Web, ce qui n’est pas réutilisable
• Incompatibilité des compilateurs standards : un fichier généré avec rustc --target=wasm ne s’exécute pas directement dans le navigateur
  • Il faut installer séparément une toolchain non officielle qui implémente l’intégration à la plateforme
• Biais de l’écosystème documentaire : la documentation Web, comme MDN, est majoritairement centrée sur JavaScript, ce qui élève la barrière d’entrée pour les utilisateurs d’autres langages
• Problèmes de performance : les appels DOM passant par des liaisons JS subissent une baisse de performance de 45 % par rapport aux appels directs
  • Dans les expérimentations du framework Dodrio, supprimer le glue code JS a réduit de moitié le temps d’application des modifications du DOM
• Dépendance à JavaScript : pour utiliser WebAssembly en production, il faut au final comprendre JS, ce qui mène à un problème de leaky abstraction

L’arrivée du WebAssembly Component Model

• Le WebAssembly Component Model définit une unité d’exécution standardisée utilisable en commun par plusieurs langages et runtimes
  • Il permet d’effectuer directement l’accès aux API Web, le chargement des modules et l’édition de liens, sans JavaScript
  • Il peut être généré par différents langages et exécuté dans divers runtimes, comme les navigateurs ou Wasmtime
• Grâce à WIT (Interface Description Language), il est possible de déclarer les API nécessaires et de les appeler directement depuis le composant
  • Exemple :

    component {
      import std:web/console;
    }
    

    → Le code Rust peut alors appeler console::log("hello, world")
• Le navigateur peut charger directement un composant via <script type="module" src="component.wasm"></script>, avec gestion automatique des liaisons aux API Web sans JS

Interopérabilité avec JavaScript

• Le Component Model prend aussi en charge une architecture d’application hybride
  • Exemple : écrire un décodeur d’image en WebAssembly, puis l’appeler depuis JS sous la forme import { Image } from "image-lib.wasm";
  • JS peut utiliser les composants WebAssembly via import/export comme s’il s’agissait de modules ordinaires

Perspectives et participation

• Mozilla collabore avec le WebAssembly CG sur la standardisation du Component Model, et Google est également en phase d’examen
• Les développeurs peuvent expérimenter via Jco ou Wasmtime dans le navigateur ou en CLI
• Si ce modèle s’impose, WebAssembly pourrait passer d’une fonctionnalité réservée aux power users à une technologie Web accessible aux développeurs généralistes