Apple, Google, Microsoft et Mozilla s’associent autour d’un projet commun pour accélérer largement le chargement des sites et l’exécution du code sous-jacent. Nommé « WebAssembly », il doit fournir en fait un bytecode aux navigateurs, pour des performances qui pourraient être multipliées par plus de 20.
Le JavaScript, toujours l'objet de toutes les attentions
Si le JavaScript a permis l’émergence du Web 2.0, il fait l’objet de critiques permanentes. Il a conféré au développement web des avantages indéniables, parmi lesquels son indépendance face aux architectures matérielles coté clients. Tant qu’aucune faille de sécurité ne vient gâter la situation, la présence d’une sandbox est une certaine garantie de sécurité. Heureusement d’ailleurs, puisque l’objectif du JavaScript reste d’exécuter du code capable de transformer une simple page web en un service ayant presque autant de possibilités qu’un logiciel natif.
Le langage est tellement utilisé, y compris sur le web mobile, que de nombreux éditeurs se penchent continuellement sur ses performances. Car ces dernières sont désormais un élément clé de la rapidité générale d’un site web. Améliorer ces performances passe aussi bien par des modifications dans l’écriture du code que dans la manière dont il est lu, interprété puis exécuté. Mais ce sont justement toutes ces étapes qui empêchent le JavaScript d’avoir les mêmes performances qu’un code natif.
Parmi les améliorations les plus notables de ces dernières années autour du JavaScript, on pourra notamment citer asm.js, un sous-ensemble de JavaScript conçu par Mozilla pour être exécuté très rapidement. Le TypeScript de Microsoft se destine pour sa part à ceux qui ont de vastes projets en JavaScript et qui veulent donc simplifier l’écriture via l’ajout de fonctionnalités spécifiques. Le standard ECMAScript (derrière le JavaScript) évolue également de son côté en ajoutant notamment de nouveaux types de données.
WebAssembly, un code intermédiaire lu vingt fois plus vite
La question était donc de savoir comment garder les avantages de JavaScript tout en gommant ses défauts. La réponse proposée par Microsoft, Google, Apple et Mozilla est simple : fournir un bytecode. Il s’agit d’un code intermédiaire, que les développeurs .NET et Java connaissent déjà, et qui vient se placer entre le fichier texte classique et l’assembleur. On pourrait parler vulgairement de code « prémâché » ou simplement précompilé. De fait, présenté au compilateur, il est beaucoup plus facile à lire par la machine et n’a plus besoin d’être interprété.
Le projet se nomme WebAssembly, ou « wasm », et le fait qu’il soit soutenu par les quatre plus grands éditeurs de navigateurs représente d’emblée un sérieux atout. L’idée était de rester sur le JavaScript, qui sert dans tous les cas de dénominateur commun. Par exemple, un développeur peut utiliser le TypeScript de Microsoft sans craindre que le code ne soit pas lisible puisqu’il est converti en JavaScript. Ce dernier peut être utilisé pour atteindre des API ou certaines technologies, comme WebGL, d’où l’idée d’en bâtir une amélioration, et surtout pas d’essayer de le remplacer.
Dans la pratique, un code WebAssembly est donc déjà précompilé et beaucoup plus léger à télécharger. Pour le compilateur, le code wasm présente un visage uniforme avec des types de données faciles à comprendre, comme des entiers 32 bits ou des nombres à virgule flottante. Sous cette forme, le parsing du code est vingt fois plus rapide qu’avec asm.js.
Un projet qui démarre, mais qui devrait rapidement prendre de l'ampleur
Parce que WebAssembly devra se faire une place parmi les solutions web, les quatre éditeurs prévoient donc de faciliter le travail des développeurs. Lors de la préparation du bytecode, ces derniers obtiendront donc le wasm lui-même, ainsi qu’une version texte pour le débogage. Par ailleurs, puisqu’il faudra le temps que tous les navigateurs soient à jour chez les utilisateurs, un script JavaScript (nommé « polyfill ») permettra aux développeurs de convertir le code wasm en JavaScript classique. La lecture d’un code ou de l’autre dépendra donc uniquement du navigateur et de sa compatibilité avec la nouvelle technologie.
Pour l’instant, WebAssembly en est à un stade assez peu avancé, on pourrait même dire de prototype. Pour l’instant, l’écriture du code se focalise sur les langages C et C++, mais d’autres sont prévus par la suite. En outre, aucun organisme de standardisation ne travaille encore sur ce projet, mais les quatre éditeurs impliqués attendent sans doute de progresser plus avant dans les spécifications avant de le faire passer à la moulinette du W3C notamment.
Enfin, on signalera la participation au projet commun de Brendan Eich, créateur du JavaScript, et pendant un court laps de temps PDG de Mozilla. Dans un billet sur son blog, daté de mercredi, il fait d’ailleurs le récapitulatif de la situation et explique pourquoi, en dépit des nombreux efforts faits jusqu’à présent, WebAssembly peut apporter un véritable avantage au web.
