WebAssembly · compilation · machines virtuelles
Qu’est-ce que WebAssembly, exactement ?
Le malentendu le plus répandu au sujet de WebAssembly est de croire qu’il s’agit d’un langage que l’on écrit. Ce n’en est pas un. La définition officielle est précise, et la lire au pied de la lettre répond à la plupart des questions que l’on se pose.
La définition, mot pour mot
WebAssembly, abrégé en Wasm, est un format d’instructions binaire pour une machine virtuelle à pile. Il est conçu comme une cible de compilation portable pour les langages de programmation, permettant le déploiement sur le web pour des applications client et serveur.
Deux conséquences en découlent immédiatement. C’est une cible, ce qui signifie que quelque chose d’autre se compile vers elle, comme C se compile en code machine. Et elle est à pile, ce qui est une décision de conception sur la façon dont la machine virtuelle conserve les opérandes, pas un détail avec lequel vous interagissez directement.
Personne n’est censé écrire du Wasm à la main pour de la production, pas plus que personne n’écrit du x86 à la main. Vous écrivez du Rust, du C, du Go ou un autre langage, et le compilateur émet du Wasm.
Les quatre objectifs de conception, et ce que chacun coûte
Le projet énonce quatre objectifs, et il vaut la peine de les lire comme des compromis plutôt que comme une liste de fonctionnalités.
Efficacité. La machine à pile est conçue pour s’exécuter à la vitesse native en tirant parti des capacités matérielles communes disponibles sur un large éventail de plateformes. Notez la nuance : des capacités communes, sur un large éventail. La vitesse vient ici du ciblage de ce que toutes les plateformes possèdent, pas de l’exploitation de ce que l’une d’elles fait le mieux.
Sûreté. Wasm décrit un environnement d’exécution sûr en mémoire et cloisonné, qui peut être implémenté à l’intérieur des machines virtuelles JavaScript existantes. Le module ne peut pas atteindre quoi que ce soit en dehors de ce que l’hôte lui remet.
Ouverture. Il est conçu pour être affiché lisiblement dans un format textuel pour le débogage, les tests, l’expérimentation, l’optimisation, l’apprentissage, l’enseignement et l’écriture de programmes à la main. Un format binaire qui livre une contrepartie lisible fait un choix délibéré contre l’opacité.
Portabilité. Le but affiché est de préserver la nature sans version, testée par fonctionnalité et rétrocompatible du web. Cette seule formule explique pourquoi Wasm n’a pas de numéros de version à négocier : vous testez la présence d’une fonctionnalité, vous ne demandez pas à quelle release vous parlez.
La relation avec JavaScript
Wasm ne remplace pas JavaScript, et la formulation officielle sur leur interaction est prudente d’une manière qui mérite d’être remarquée. Les modules pourront appeler vers et depuis le contexte JavaScript et accéder aux fonctionnalités du navigateur à travers les mêmes Web APIs accessibles depuis JavaScript.
Ce futur, pourront, figure dans la description officielle. C’est un rappel que la frontière entre les deux a été une cible mouvante, et que tout ce que vous lisez sur Wasm et le DOM devrait être vérifié par rapport à la version que vous livrez réellement plutôt que par rapport à un billet de blog.
La forme pratique aujourd’hui : Wasm calcule, JavaScript orchestre. Le travail numérique lourd, les codecs, la compression, la simulation, la cryptographie relèvent tous du premier rôle. Atteindre la page, gérer les événements et appeler les API du navigateur relèvent du second.
Il n’a jamais été réservé aux navigateurs
Le nom induit les gens en erreur, et le site le dit clairement : WebAssembly prend également en charge les intégrations hors du web. La définition elle-même mentionne des applications client et serveur.
C’est pourquoi Wasm apparaît dans des endroits où il n’y a aucun navigateur : des systèmes de plugins qui doivent exécuter du code non fiable en toute sécurité, des runtimes en périphérie, du scripting embarqué à l’intérieur d’applications plus grandes. Dans tous ces cas, l’attrait tient au même couple de propriétés, un bac à sable et un format binaire portable, et le navigateur est simplement l’hôte le plus visible plutôt que le seul.
Quand c’est le mauvais outil
Si votre goulot d’étranglement est le réseau, Wasm n’aide pas. Un module doit toujours être téléchargé, et un calcul rapide derrière un transfert lent reste lent.
Si votre travail consiste surtout à manipuler le DOM, franchir la frontière pour le faire coûte plus que cela ne rapporte. C’est précisément ce que JavaScript sait déjà bien faire.
S’il vous faudrait réécrire du code qui fonctionne, pesez-le honnêtement. Wasm brille quand un langage compilé est déjà le choix naturel, ou quand vous avez une base de code C ou Rust existante à emmener avec vous.
La version courte
WebAssembly est un format d’instructions binaire pour une machine virtuelle à pile, et une cible de compilation portable plutôt qu’un langage que l’on écrit. Ses quatre objectifs sont l’efficacité à la vitesse native sur du matériel commun, un bac à sable sûr en mémoire, un format texte lisible à côté du binaire, et la portabilité sans version et testée par fonctionnalité du web.
Il complète JavaScript au lieu de le remplacer, et il prend en charge les intégrations hors du web, ce qui explique qu’il apparaisse dans les systèmes de plugins et les runtimes serveur aussi volontiers que dans les navigateurs. Lisez la définition au pied de la lettre et l’essentiel de la confusion qui l’entoure disparaît.
Si vous vous intéressez à la façon dont les langages compilés atteignent une cible en général, notre note sur ce qu’est un algorithme commence un niveau en dessous.
La définition, les quatre objectifs de conception et leur formulation, l’affirmation sur les appels vers et depuis le contexte JavaScript, et la note sur les intégrations hors du web sont tirées du site officiel de WebAssembly, vérifié au moment de la rédaction. La spécification évolue ; vérifiez auprès de la documentation courante avant de vous appuyer sur une capacité précise.