L’un des objectifs des développeurs est d’améliorer les performances des applications Web. Il existe différentes solutions pour cela, dont l’une, le mode Webassembly est en train d’émerger, qui bénéficie du support des quatre principaux éditeurs de navigateurs : Google, Microsoft, Firefox, mais aussi WebKit qui est au cœur du Safari d’Apple. Grâce à cette technique, une application Web sera presque aussi rapide que si elle avait été développée en mode natif.
Webassembly est une technologie qui consiste à compiler un code source, C ou C++ dans un format intermédiaire, une sorte de byte code, comme pour Java (.class) ou .NET, mais destiné aux navigateurs. Webassembly est un langage de bas niveau, qui va s’exécuter dans un nouveau « run time » intégré dans les versions à venir des navigateurs. Il s’agit bien du langage machine du Web.

ASM.js et webassembly

Pour bien comprendre le positionnement de webassembly, il faut faire un petit retour en arrière sur les deux techniques qui nous permettaient jusqu’à présent d’accélérer les pages Web : asm.js et le mode natif.

En natif, c’est très simple. On développe du code avec le SDK fourni par Apple, Microsoft ou Google, bibliothèques et patterns, qui garantissent d’excellentes performances au détriment de la compatibilité, puisque ce qui a été écrit pour X, ne fonctionne pas avec Y.

La seconde technique concerne plus précisément JavaScript.

L’idée qu’ont eu les concepteurs de Mozilla était de faire du « transpilage » à partir d’un code source C ou C++ (mais d’autres langages étaient envisagés) et de générer un sous-ensemble de JavaScript, efficace et performant.

Pour être très précis, l’opération se fait en deux temps.

Dans une première étape, le code source est compilé avec Clang en code intermédiaire LLVM, qui s’exécute dans un « run time » dédié. Et c’est ce code intermédiaire qui est traduit en JavaScript, par un autre produit très connu, Emscripten.

In fine, les modules JavaScript issus de cette « filière » sont beaucoup plus rapides que leur équivalent traditionnel, Mozilla évoquant un rapport de 10.

L’inconvénient du procédé est qu’il implique de nombreuses restrictions sur le langage généré, qui n’est donc pas un « full » JavaScript. Ce qui explique que l’on ne développe généralement pas des applications métiers complètes de cette manière, mais simplement des modules réutilisables, à qui on demande seulement d’être performants.

Webassembly va plus loin

Webassembly est lui-aussi un langage intermédiaire (wasm) qui recherche la compatibilité avec tous les navigateurs, sans laquelle il n’a aucune chance de s’imposer.

C’est un format binaire, qui devra s’exécuter dans un « run time » dédié, qui ne sera ni la JVM Java, ni la CLR de .NET, ni même LLVM qui n’a pas été retenu pour des questions de portabilité.

On repartira donc pour l’instant des mêmes bases C/C++ avec des programmes que l’on va compiler pour obtenir une sorte d’assembleur wasm, destiné à ce fameux run time dédié que les éditeurs mettent en place dans leur navigateur, celui-ci comme un assembleur traditionnel pouvant être de nouveau traduit (JIT) en binaire (wast) pour être exécuté par le processeur de la machine. L’idée étant aussi que l’on puisse faire la même chose à partir de n’importe quel autre langage exploitable dans un environnement Web. Le passage du code source C/C++ au binaire pur, se fera donc en trois étapes.

Webassemby est une sorte d’assembleur spécifique à un « run time » implémenté dans le navigateur Internet par les quatre grands éditeurs du marché. Pour passer du source C/C++ au binaire, trois phases sont nécessaires : écriture du source, compilation wasm et JIT wast (illustration Wikipedia).

 

Pour une fois, les quatre grands acteurs, Google, Microsoft, Apple et Mozilla ont travaillé « main dans la main », pour définir le format et les spécificités de ce langage binaire. Ils ont même fini leur travail depuis la fin du 1er trimestre 2017, au moins pour une première version du langage, dite MVP (Minimum Viable Product), sur laquelle la communauté va pouvoir s’appuyer et définir le cadre dans lequel ils pourront l’utiliser et l’étendre.

Cela dit, Webassembly ne remplace pas JavaScript et son sous-ensemble asm.js. Les deux modes vont coexister et pourront même interagir, avec des modules Webassembly importés dans un univers JavaScript et réciproquement.

Mais ce qu’il faudra vérifier, ce sera surtout l’adéquation de Webassembly pour servir de support aux grosses applications, embarquées dans le navigateur, celles que l’on n’a jamais su écrire jusqu’à maintenant, sauf à passer par un développement natif.

Un peu de patience

Tout n’est évidemment pas terminé et les trois années à venir seront significatives.

Avec au bout chemin, trois natures de développement : HTML5 avec JavaScript classique, HTML5 avec des modules compilés asm.js et HTML5 avec Webassembly pour des applications plus ambitieuses. Dans un premier temps asm.js et Webassembly resteront compatibles et interchangeables, mais cela ne durera pas et dans un futur proche, les deux langages vont vivre leur vie indépendamment.

Et même s’il est encore trop tôt, pour se prononcer définitivement sur la pertinence de Webassembly, ce concept nous semble particulièrement structurant et à même de servir de base à une nouvelle génération d’applications Web. Plus que le successeur de JavaScript, il est pour nous le successeur dans le monde Web, de Java et de sa JVM. C’est là qu’il faut mettre le curseur.