Interprétation ou compilation ?

WebAssembly, le format binaire du web créé par Apple, Google, Microsoft et Mozilla

Nex Impact du 19 juin 2015

Les développeurs Java et .NET s’écrient : « Ah ! »

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.

 

 

 

WebAssembly, le nouveau standard qui veut rendre le Web vingt fois plus rapide

 

01 Net du 18 juin 2015

 

Les principaux éditeurs de navigateurs se mettent ensemble pour créer une nouvelle technologie d’exécution de code, permettant de créer des aplications Web encore plus complexes.

 

Gilbert Kallenborn

 

/Mozilla, Microsoft, Google et Apple viennent de lancer un nouveau projet qui pourrait bien annoncer une nouvelle ère du Web. Baptisé « WebAssembly », son but est de doter les navigateurs d’une technologie permettant d’accélérer considérablement l’exécution des logiciels. Le principe retenu est celui du « bytecode », c'est-à-dire un code intermédiaire entre le code source écrit par le développeur et les instructions machines que peut exécuter un processeur.

 

L’avantage, c’est que ce type de code peut être traité beaucoup plus rapidement que, par exemple, un code Javascript. Celui-ci fait partie de la famille des langages interprétés, ce qui signifie que le code écrit par le développeur est envoyé tel quel au navigateur qui, grâce à son compilateur intégré, le convertit à la volée en code exécutable. D’après les membres du projet WebAssembly, l’exécution d’un « bytecode » serait 20 fois plus rapide que du Javascript, même dans sa version la plus optimisée (en occurrence asm.js). De quoi faire saliver beaucoup de fournisseurs de services Web, surtout quand il s’agit de proposer des fonctionnalités avancées sur les terminaux mobiles.

 

Eviter le cloisonnement

 

En réalité, le « bytecode », ce n’est pas vraiment nouveau sur Internet. Il existe déjà de nombreux spécimens sur la Toile, plus ou moins vivants : Java, .NET, Adobe Flash... Certes, ces programmes peuvent s’intégrer dans une page Web, mais les interactions avec celle-ci restent finalement assez limitées, avec à la clé un certain cloisonnement pas très pratique. C’est un peu pour cette raison que les développeurs se sont tournés vers JavaScript, un langage non seulement facile à utiliser mais aussi totalement intégré dans l’environnement web.

 

Avec WebAssembly, les géants high-tech veulent avoir le meilleur des deux mondes : un code qui s’exécute rapidement ET une forte intégration dans l’environnement Web. Ainsi, il est prévu que les programmes WebAssembly pourront dialoguer sans problème avec les modules JavaScript d’une page, et cela de manière synchrone. Ils pourront également accéder aux fonctionnalités du navigateur au travers des mêmes interfaces de programmation que celles utilisées par JavaScript. Et, bien sûr, WebAssembly serait intégré de manière native dans tous les navigateurs. Il n’y aurait donc pas besoin de télécharger de plugins ou d’extensions embarrassantes.

 

Pour l’instant, tout ceci n’est évidemment qu’une projection vers le futur. Le projet vient à peine d’être lancé et son chemin vers la standardisation est encore long. Mais le fait qu’il regroupe d’ores et déjà les principaux éditeurs de navigateurs est plutôt un gage d’avenir.

 

Sources :

 

Ars Technica, GitHub, Note de blog de Brendan Eich

 

 

 

 

 

Google, Microsoft, Mozilla And Others Team Up To Launch WebAssembly, A New Binary Format For The Web

 

TechCrunch.com du 17 juin 2015

 

Frederic Lardinois (@fredericl)

 

 Microsoft, Mozilla And Others Team Up To Launch WebAssembly, A New Binary Format For&body=Article:%20http://techcrunch.com/2015/06/17/google-microsoft-mozilla-and-others-team-up-to-launch-webassembly-a-new-binary-format-for-the-web/

 

Google, Microsoft, Mozilla and the engineers on the WebKit project today announced that they have teamed up to launch WebAssembly, a new binary format for compiling applications for the web.

 

The web thrives on standards and, for better or worse, JavaScript is its programming language. Over the years, however, we’ve seen more and more efforts that allow developers to work around some of the limitations of JavaScript by building compilers that transpile code in other languages to JavaScript. Some of these projects focus on adding new features to the language (like Microsoft’s TypeScript) or speeding up JavaScript (like Mozilla’s asm.js project). Now, many of these projects are starting to come together in the form of WebAssmbly.

 

The new format is meant to allow programmers to compile their code for the browser (currently the focus is on C/C++, with other languages to follow), where it is then executed inside the JavaScript engine. Instead of having to parse the full code, though, which can often take quite a while (especially on mobile), WebAssembly can be decoded significantly faster

 

The idea is that WebAssembly will provide developers with a single compilation target for the web that will, eventually, become a web standard that’s implemented in all browsers.

 

By default, JavaScript files are simple text files that are downloaded from the server and then parsed and compiled by the JavaScript engine in the browser. The WebAssembly team decided to go with a binary format because that code can be compressed even more than the standard JavaScript text files and because it’s much faster for the engine to decode the binary format (up to 23x faster in the current prototype) than parsing asm.js code, for example.

 

Mozilla’s asm.js has long aimed to bring near-native speeds to the web. Google’s Native Client project for running native code in the browser had similar aims, but got relatively little traction. It looks like WebAssemly may be able to bring the best of these projects to the browser now.

 

As a first step, the WebAssembly team aims to offer about the same functionality as asm.js (and developers will be able to use the same Emscripten tool for WebAssembly as they use for compiling asm.js code today).

 

In this early stage, the team also plans to launch a so-called polyfill library that will translate WebAssembly code into JavaScript so that it can run in any browser — even those without native WebAssembly support (that’s obviously a bit absurd, but that last step won’t be needed once browsers can run this code natively). Over time then, the teams will build more tools (compilers, debuggers, etc.) and add support for more languages (Rust, Go and C#, for example).

 

As JavaScript inventor (and short-term Mozilla CEO) Brendan Eich points out today, once the main browsers support the new format natively, JavaScript and WebAssembly will be able to diverge again.

 

The team notes that the idea here is not to replace JavaScript, by the way, but to allow many more languages to be compiled for the Web. Indeed, chances are that both JavaScript and WebAssembly will be used side-by-side and some parts of the application may use WebAssembly modules (animation, visualization, compression, etc.), while the user interface will still be mostly written in JavaScript, for example.

 

It’s not often that we see all the major browser vendors work together on a project like this, so this is definitely something worth watching in the months and years ahead.