Mozilla, Google, Microsoft et Apple ont décidé de développer un format binaire pour le web. Appelé WebAssembly, ce nouveau format pourrait être une cible de compilation pour n'importe quel langage permettant ainsi de fonctionner sur n'importe quel navigateur et autres agents.
Il y a quelques années de ça, nous avions discuté sur InfoQ l'intérêt d'un bytecode universel pour le Web (voir Débat : Avons-nous besoin d'un bytecode universel pour le web ?), dans lequel nous soulignions les difficultés d'en créer un. Le problème majeur était l'incapacité des principaux éditeurs de navigateurs à se mettre d'accord : Mozilla avançait asm.js, Google poussait PNaCl, Apple travaillait sur FLTJIT, et Microsoft ne semblait s'intéresser à aucun d'entre eux. Mais cela a changé. Les 4 éditeurs de navigateurs ont décidé de créer WebAssembly ou WASM/wasm, un format binaire pour le web. Certains parlent de bytecode, mais wasm n'est pas un bytecode au sens traditionnel, comme Brendan Eich le souligne : “WebAssembly est effectivement un AST compressé et encodé, mais pas une pile bytecode. Mais ne le dites pas. Vous pouvez toujours l'appeler bytecode si vous le souhaitez”.
Ce projet a évolué en toute discrétion pour le moment, mais il est récemment devenu public avec une présence sur GitHub et une Communauté W3C. WebAssembly est destiné à permettre aux programmes écrits dans des langages autres que JavaScript de fonctionner dans les navigateurs et autres agents serveurs, mobiles ou IoT. Ce format remplacera bientôt asm.js et PNaCl. Selon les documents de design du projet, qui ne sont pas encore définitifs, WASM utilise un format binaire pour des “raisons de performances : cela réduit le volume à télécharger et accélère le décodage, permettant ainsi même à des volumes de code importants de démarrer rapidement”. WASM s'accompagne d'un format text qui peut être utilisé pour debugger et pour les outils de développement. Ces outils devraient être capables de transcrire d'un format à l'autre sans perte d'information.
Une première étape temporaire dans l'implémentation de WebAssembly a été franchie : traduire le format en code asm.js pour qu'il puisse déjà fonctionner sur les navigateurs le supportant : Firefox, Edge, Chrome. Il y a déjà un prototype de polyfill créé dans ce but et les résultats initiaux montrent que le binaire gzippé est environ 20-30% plus petit que l'asm.js gzippé correspondant, et que le décodage de ce wasm est environ 23 fois plus rapide que le parsing de la source asm.js. WASM sera à terme supporté nativement par les VM des navigateurs.
WebAssembly devrait d'abord amener les programmes C/C++ au web, mais il pourra ensuite être amélioré pour supporter n'importe quel langage. Un backend LLVM et un portage de Clang sont prévus. WASM s'exécutera dans le "même univers sémantique que JavaScript", supportera les appels asynchrones vers et depuis JavaScript, accédera aux APIs des navigateurs et sera soumis aux mêmes restrictions de sécurité que JavaScript. Une application cliente pourra être écrite intégralement en WASM ou pourra avoir uniquement son code métier en WASM et son UI en HTML/CSS/JavaScript.
Annoncé peu de temps après le 20ème anniversaire de JavaScript et le même jour qu'Ecma annonçait la validation finale des spécifications ES6, WebAssembly n'est pas une bonne nouvelle pour JavaScript : WASM va permettre de coder pour le web dans n'importe quel langage qui compilera vers celui-ci. JavaScript sera en compétition directe avec les autres langages. Pourrait-on s'attendre à ce que Java ou C# compilent vers WASM ?
WebAssembly bénéficiera des leçons tirées de asm.js et PNaCl, puisque les équipes en charge chez Mozilla et Google sont impliquées dans sa création. Avoir Microsoft et Apple parmi les supporters est aussi très prometteur pour le projet. Le seul problème restant est le temps : généralement, les projets développés par des gros groupements prennent beaucoup de temps et le processus de standardisation est souvent lent.