WebAssembly

de code binaire portable et un format texte correspondant pour les programmes exécutables ainsi que des interfaces logicielles facilitant la communication entre ces programmes et leur environnement hôte.

L'objectif principal de WebAssembly est de faciliter le développement d'applications performantes sur les pages web , mais il est également conçu pour être utilisable dans des environnements non web. Il s'agit d'une norme ouverte destinée à prendre en charge n'importe quel langage sur n'importe quel système d'exploitation, et en pratique, bon nombre des langages les plus populaires bénéficient déjà d'une prise en charge, même partielle.

Annoncé en World Wide Web Consortium (W3C) le 5 décembre 2019 et a reçu le prix du meilleur logiciel de langage de programmation décerné par l' Association for Computing Machinery (ACM) SIGPLAN en 2021. Le W3C maintient la norme grâce aux contributions de Mozilla , Microsoft , Google , Apple , Fastly , Intel et Red Hat . ( 2015 )

WebAssembly a été annoncé pour la première fois en 2015 et sa première démonstration a consisté à exécuter Angry Bots d' Unity dans Firefox , Google Chrome [ et Microsoft Edge (ancienne version) . Les technologies précurseurs étaient asm.js de Mozilla et Google Native Client [ , et l'implémentation initiale était basée sur les fonctionnalités d'asm.js

En mars 2017, la conception du produit minimum viable (MVP) a été déclarée terminée et la phase de prévisualisation s'est achevée. Fin septembre 2017, Safari 11 a été publié avec la prise en charge de WebAssembly. En février 2018, le groupe de travail WebAssembly a publié trois versions préliminaires publiques pour la spécification de base, l'interface JavaScript et l'API Web.

Le MVP était axé sur les langages de bas niveau tels que C et C++ , avec l'intention d'ajouter des fonctionnalités utiles pour les langages de haut niveau dans une version future.

Le multithreading est actuellement à l'état de brouillon, mais il est pris en charge par Chrome depuis la version 75 en juin 2019, Firefox version 79 et Safari version 14.1

La spécification WebAssembly 2.0 a été finalisée en 2022 et est devenue une norme W3C en décembre 2024. Elle ajoute de nombreuses instructions liées à l'instruction SIMD ( Single Instruction, Multiple Data ) et un nouveau type de données v128, avec la possibilité pour les fonctions de renvoyer plusieurs valeurs, des instructions d'initialisation/copie de mémoire en masse et des types de référence, qui sont des pointeurs opaques vers des objets situés en dehors de la mémoire linéaire.

WebAssembly 3.0 a été publié en septembre 2025. Parmi ses nouvelles fonctionnalités figurent un espace d'adressage 64 bits , la prise en charge de plusieurs espaces d'adressage, la gestion des exceptions et le ramasse-miettes pour les types struct et array. La prise en charge du ramasse-miettes permet une compilation plus efficace pour les langages de haut niveau, mais WasmGC de WebAssembly 3.0 ne possède pas les fonctionnalités requises par le runtime .NET .

Bien que WebAssembly ait été initialement conçu pour permettre une vitesse d'exécution de code quasi native dans le navigateur web, son utilité s'est avérée précieuse en dehors de ce cadre, dans des contextes plus généraux. Un environnement d'exécution WebAssembly est une machine virtuelle de bas niveau , semblable à la JVM ou à la Flash VM ; il peut être intégré à n'importe quelle application hôte, et des environnements d'exécution WebAssembly autonomes ont ainsi été créés, tels que serveurs d'applications pour héberger des applications WebAssembly « côté serveur » et à d'autres applications pour prendre en charge les architectures d'extension logicielle basées sur des plugins , comme WebAssembly for Proxies (Proxy-Wasm), qui spécifie une interface binaire d'application (ABI) basée sur WebAssembly pour étendre les serveurs proxy .

Les navigateurs Web empêchent le code WebAssembly de manipuler directement le modèle objet de document (DOM ). Le code Wasm doit donc faire appel à JavaScript pour cela.

Spectre et Meltdown , une fois la prise en charge des threads à mémoire partagée ajoutée. Face à cette préoccupation, les développeurs de WebAssembly ont suspendu le développement de cette fonctionnalité. Toutefois, afin d'explorer ces futures extensions du langage, Google Chrome a ajouté une prise en charge expérimentale de la proposition de threads WebAssembly en octobre 2018.

WebAssembly a été critiqué pour sa capacité à faciliter la dissimulation de preuves pour les auteurs de logiciels malveillants , les escrocs et les auteurs d'attaques par hameçonnage ; WebAssembly n'est présent sur la machine de l'utilisateur que sous sa forme compilée, ce qui « rend la détection des logiciels malveillants difficile » . La rapidité et la facilité de dissimulation offertes par WebAssembly ont conduit à son utilisation pour le minage de cryptomonnaies à l'insu des utilisateurs . Coinhive, un service désormais disparu qui facilitait le minage de cryptomonnaies dans les navigateurs web, affirmait que son « mineur utilise WebAssembly et offre environ 65 % des performances d'un mineur natif ». Une étude de juin 2019 de l' Université technique de Brunswick a analysé l'utilisation de WebAssembly sur le million de sites web les plus populaires selon Alexa et a constaté que son utilisation prédominante était le minage malveillant de cryptomonnaies, et que les logiciels malveillants représentaient plus de la moitié des sites web utilisant WebAssembly étudiés. Une étude de l'Université de Stuttgart datant d'avril 2021 a révélé que, depuis lors, le minage de cryptomonnaies a été marginalisé, tombant à moins de 1 % de tous les modules WebAssembly collectés à partir d'un large éventail de sources, y compris le million de sites Web les plus populaires selon Alexa.

Comme WebAssembly ne prend en charge que le flux de contrôle structuré , il est compatible avec les techniques de vérification de sécurité, y compris l'exécution symbolique .

Au début, la vitesse d'exécution d'un programme Wasm était estimée à environ 91 % (soit environ 10 % plus lente) de celle d'un programme natif comparable, sans compter le temps de chargement/d'instanciation ; cependant, divers tests ultérieurs indiquent une large gamme de performances, allant de 33 % à 200 % de la vitesse d'exécution du code natif, selon la tâche.Université du Massachusetts à Amherst a présenté une analyse approfondie des performances de WebAssembly par rapport au code natif . Cette étude a utilisé la suite de benchmarks SPEC CPU et un système appelé « Browsix-Wasm » pour exécuter des applications Unix non modifiées dans le navigateur, permettant ainsi de tester des applications réelles. Elle a révélé un écart de performances significatif entre l'exécution de WebAssembly et l'exécution native ; en particulier, les programmes WebAssembly ont affiché un ralentissement moyen de 45 % dans Firefox et de 55 % dans Chrome lors des tests en conditions réelles. Lors des ralentissements les plus importants, un programme WebAssembly pouvait mettre 2,08 fois plus de temps à s'exécuter dans Firefox et 2,5 fois plus de temps dans Chrome. L'article a identifié plusieurs raisons à cette différence de performances, notamment des optimisations manquantes, des problèmes de génération de code dans les compilateurs WebAssembly et les limitations inhérentes à la plateforme WebAssembly.

Une étude de 2021 suggère que WebAssembly est beaucoup plus rapide que JavaScript dans certains cas, comme l'exécution d'une fonction complexe sur un petit fichier ( par exemple , le traitement d'un fichier graphique) ; cependant, à l'époque, l'interpréteur JavaScript disposait de certaines optimisations dont les implémentations WebAssembly ne disposaient pas ( par exemple , la compilation à la volée ).

En 2022, des chercheurs ont déterminé qu'un programme Wasm s'exécute à environ 120 % (soit 20 % plus rapidement) de la vitesse d'un programme JavaScript comparable. Ces résultats concordent avec l'expérience de la startup Zaplib, dont les fondateurs ont expliqué dans un article de blog sa fermeture en raison des performances insuffisantes de WebAssembly. Leur objectif était d'améliorer significativement les performances des applications web existantes en les portant progressivement vers Rust /Wasm ; cependant, la migration du simulateur d'un client depuis JavaScript n'a permis qu'une amélioration de 5 % des performances. De même, concernant Figma , ils ont déclaré ce qui suit :

Après un examen plus approfondi, il apparaît que l'utilisation de WebAssembly par Figma relève davantage d'un concours de circonstances historiques — la volonté de développer en C++ pour assurer la compatibilité avec leur application native — que d'impératifs de performance critiques. Les fichiers Figma sont traités en C++/WebAssembly, ce qui représente sans doute un gain de vitesse considérable, mais l'essentiel des performances exceptionnelles de Figma est dû à son moteur de rendu WebGL .

En 2023, une étude des performances de WebAssembly pour les tâches cryptographiques a indiqué que « lorsqu’il utilisait l’environnement d’exécution le plus rapide, WebAssembly était seulement environ 2,32 fois plus lent (en médiane) que le code natif avec des optimisations spécifiques à l’architecture ». Ce résultat excluait deux tests où le code natif bénéficiait d’instructions spéciales implémentées directement dans le processeur de la plateforme cible ; pour ces tests particuliers, les programmes WebAssembly étaient « 80 fois plus lents que le code natif ».

Les tests de performance ont révélé plusieurs autres points faibles de WebAssembly, tels que des performances médiocres dues à l'absence d'accès direct au DOM, un problème qui est en cours de résolution.

interface binaire d'application (ABI) et interface de programmation d'application (API)) conçue par Mozilla , destinée à être portable sur n'importe quelle plateforme. Elle offre des fonctionnalités similaires à l'interface de système d'exploitation portable ( POSIX ), telles que les entrées/sorties de fichiers (E/S) limitées par une sécurité basée sur les capacités . D'autres ABI/API ont été proposées.

WASI est influencé par CloudABI et Capsicum .

Docker , a écrit en 2019 : « Si WASM+WASI avait existé en 2008, nous n’aurions pas eu besoin de créer Docker. C’est dire son importance. WebAssembly côté serveur est l’avenir de l’informatique. »

WASI 0.1 propose quelques API de type POSIX, telles que les entrées/sorties de fichiers, la lecture des variables d'environnement et la génération de nombres aléatoires, mais offre une prise en charge réseau très limitée. WASI 0.2 est repensé selon le modèle de composants WebAssembly. WASI 0.3 ajoutera la prise en charge des fonctions asynchrones ; l'hôte assure la traduction entre les appels de fonctions bloquantes et asynchrones, de sorte qu'une fonction exportée bloquante peut être appelée comme une fonction asynchrone, et inversement.

À partir de la version 0.2, WASI est défini selon le modèle de composants. Les interfaces de ce modèle sont spécifiées dans un IDL appelé WIT (WebAssembly Interface Types). Alors que le langage WebAssembly de base ne prend en charge que les entiers et les nombres à virgule flottante, les interfaces WIT peuvent exprimer des types tels que des chaînes de caractères, des listes, ainsi que des types d'enregistrements et de variantes définis par l'utilisateur, et sont indépendantes du langage. Les composants ne peuvent pas accéder à la mémoire des autres et interagissent donc uniquement via des fonctions importées et exportées. Le modèle de composants est conçu autour de la composition : deux composants peuvent être composés en un seul lorsque les exportations de l'un correspondent aux importations de l'autre, ce qui permet de virtualiser n'importe quelle interface. Les interfaces WIT sont regroupées en un « monde ». WASI 0.2 définit un monde d'interface en ligne de commande (CLI) similaire à l'API de type POSIX de WASI 0.1, et un monde de proxy HTTP pour les serveurs web.

Le modèle de composants n'est actuellement pas pris en charge par les navigateurs.