WebAssembly

En 1995, JavaScript voyait le jour comme un simple langage de script. Personne n’imaginait alors qu’il deviendrait le moteur d’applications Web sophistiquées. À l’origine, il servait surtout à valider des formulaires ou animer quelques éléments d’une page. Le gros du travail se faisait sur les serveurs, les navigateurs ne gérant que l’affichage et quelques interactions basiques.

Tout a changé avec l’arrivée de moteurs performants comme V8. JavaScript s’est mis à gérer des programmes de plusieurs milliers de lignes, des applications qui auraient été impensables quelques années plus tôt. Le langage se retrouvait utilisé bien au-delà de ce pour quoi on l’avait conçu.

Cette transformation a poussé les acteurs du Web à chercher des voies alternatives. Microsoft a tenté sa chance avec ActiveX, qui reposait sur la signature de binaires x86 – une approche fondée sur la confiance plutôt que sur de vraies garanties techniques. Google a ensuite développé Native Client, qui introduisait le sandboxing pour du code machine sur le Web. Les performances s’approchaient du natif, mais les développeurs devaient suivre des contraintes strictes dans leur code, comme utiliser des masques binaires avant chaque accès mémoire.

Emscripten a ensuite ouvert une nouvelle possibilité : compiler du C ou du C++ vers JavaScript. Le système créait un environnement d’exécution en JavaScript et traduisait le code vers un sous-ensemble spécialisé, qui a donné naissance à asm.js. On pouvait enfin exécuter du code bas niveau dans un navigateur, mais JavaScript restait un intermédiaire contraignant.

C’est en 2015 que l’histoire prend un tournant inattendu. Des ingénieurs de Google Chrome, Mozilla Firefox, Microsoft Edge et Apple Safari se sont mis autour d’une table pour travailler ensemble. Ces concurrents historiques, qui s’étaient livrés à des « guerres des navigateurs » pendant des années, ont décidé de collaborer. Leur but ? Créer un format de bytecode portable qu’ils ont appelé WebAssembly.

Le projet avait des ambitions claires. Il fallait une représentation compacte, une validation rapide, une compilation efficace. Et surtout, une exécution sûre sans pénalité de performance. Les concepteurs ont fait un choix audacieux : formaliser la sémantique dès le départ. WebAssembly devenait ainsi le premier langage industriel conçu avec une sémantique formelle dès sa création.

L’architecture qui en résulte présente quelques particularités. WebAssembly s’appuie sur une machine à pile pour représenter les calculs. Mais grâce à son système de types, les compilateurs peuvent analyser le flux de données entre instructions sans avoir à matérialiser physiquement cette pile. Le contrôle de flux est structuré : pas de goto sauvage, mais des constructions classiques via des blocs imbriqués.

La mémoire fonctionne comme un grand tableau d’octets, séparé du code et de la pile d’exécution. Un programme défaillant ou compromis ne peut corrompre que ses propres données. Cette isolation garantit la sécurité : le code s’exécute dans un bac à sable qui l’empêche d’accéder au système hôte sans autorisation.

Le format binaire a été pensé pour le réseau. Les instructions tiennent sur un octet, les nombres entiers utilisent le format LEB128. Les navigateurs peuvent commencer la compilation dès les premiers octets reçus, sans attendre le téléchargement complet du module.

En 2017, les quatre principaux navigateurs intégraient le support de WebAssembly. Chaque équipe a choisi sa propre stratégie d’implémentation. V8 et SpiderMonkey ont réutilisé leurs compilateurs JIT pour compiler les modules avant leur instanciation. JavaScriptCore a suivi une voie similaire. Chakra a préféré traduire à la volée vers un bytecode interne, puis compiler les fonctions les plus sollicitées.

WebAssembly atteint souvent 80 à 90% des performances du code natif, tout en gardant la portabilité et la sécurité du Web. Le code généré est compact : 62,5% de la taille d’asm.js en moyenne, 85,3% de celle du x86-64 natif.

L’influence de WebAssembly déborde du navigateur. Sa conception le rend utilisable dans d’autres contextes. Des implémentations autonomes existent, qui transforment WebAssembly en format portable pour des applications natives. On retrouve là l’ambition originelle de Java avec son « écrire une fois, exécuter partout ».

Le développement continue. Les exceptions à coût nul sont arrivées, les threads aussi, ainsi que les instructions SIMD. L’intégration des ramasse-miettes des navigateurs est en cours, ce qui facilitera la compilation de langages comme Java, C#, Swift ou OCaml vers WebAssembly.

Au-delà de la technique, WebAssembly témoigne de l’accomplissement de la collaboration dans l’écosystème Web. Le projet montre qu’une approche rigoureuse, presque académique, peut cohabiter avec les réalités du développement industriel. Cette technologie a redéfini ce qu’il est possible de faire tourner dans un navigateur, sans sacrifier la sécurité qui est au cœur du Web.