WebAssembly, vers un web compilé ?

Edit : Les commentaires offrent un excellent complément à l’article.

Il y a maintenant deux ans on commençait à voir des vidéos d’Unreal Engine 3 tournant dans le navigateur.

Ce proof of concept mettait en avant asm.js, un sous ensemble de JavaScript à la fois restreint mais optimisé.

Concrètement asm.js offre la possibilité de transcrire du code C/C++ en JavaScript (dans la limite de ce sous ensemble) en utilisant emscripten. Ce code étant compilé, sa vitesse d’exécution permet d’atteindre un niveau de performance inaccessible pour un langage parsé et interprété à la volée.

Pendant que la fondation Mozilla travaillait sur asm.js, Google avancait sur son Native Client, ce qui était plutôt inquiétant en terme d’intéropérablité pour nous développeurs.

Heureusement les représentants des 4 navigateurs les plus utilisés ont décidé de se mettre au tour de la table et de standardiser leurs avancées dans un nouvel outil : WebAssembly (wasm).

Un groupe a donc était constitué au sein du w3c afin de spécifier WebAssembly et des dépôts ouverts.

Que va nous apporter WebAssembly ?

Dans l’exécution d’un programme classique en JavaScript le navigateur doit récupérer le code source, le compiler vers un bytecode et l’interpréter.

Même avec de la compilation just in time cela prend forcément du temps. L’idée ici est de fournir directement le bytecode au navigateur. Avec à la clé plusieurs avantages : le bytecode est plus léger que le code en tant que tel, hors compression on parle d’un facteur 3, compressé avec gzip ~30%. Cela signifie 30% de données de moins à transférer et trois fois moins à traiter.

La conversion du code JavaScript vers du code wasm va donc accélérer le temps de chargement de façon très significative mais moins le temps de traitement. En effet JavaScript génère également du bytecode qui est éxécuté. asm.js permet une optimisation en ne gérant qu’un sous ensemble de JavaScript et avec une syntaxe qui permet au compilateur un certain nombre d’optimisations.

Concrètement on a sous le capot une version de JavaScript typée statiquement (on a enfin trouvé une pseudo justification à l'usage du mot java) et sans objet.

On ne peut donc pas faire une transposition de l’ensemble du code JavaScript vers de l’asm en un claquement de doigt. Et on ne le pourra pas non plus avec WebAssembly.

Est-ce la mort de JavaScript ?

Non, WebAssembly n’est pas prévu comme un remplaçant à court terme de JavaScript, mais il va évoluer parallèlement ce qui à mon sens est un élément indispensable à son adoption.

Le web n’est pas un média de rupture, les technologies avancent certes rapidement mais en conservant de la rétro-compatibilité. Suivant cette idée, des prototypes de polyfill sont en cours afin de convertir du WebAssembly vers du JavaScript si ce premier n’est pas supporté (assurant la compatibilité mais faisant disparaître les avantages de wasm).

Toutefois le fait que les principaux navigateurs veuillent le standardiser est une excellente nouvelle et un gage d’avancées significatives à venir.

D’asm à wasm

À ce stade vous vous dites sûrement que wasm est uniquement une standardisation d’asm, mais wasm va plus loin. En effet la volonté est de pouvoir exécuter du code C/C++ dans le navigateur mais pas uniquement. À terme il sera possible d’y porter tout type de langage tout en accédant aux API de JavaScript.

Même si l’effort à fournir avant d’y arriver sera énorme le potentiel est extraordinaire.

Aujourd’hui des outils permettant de porter du code wasm vers asm existent (quand je lis que ce n’est pas un média de rupture), ce qui permet donc de l’exécuter dans les navigateurs supportant asm. Concrètement on parle de tous les navigateurs supportant ES6 puisque asm en est un sous ensemble.

Adieu view source ?

C’est pour moi un argument critique, cette mise à disposition du code dans un format binaire pourrait nous faire dire adieu à la possibilité d’en voir le source.

Certes les codes étant maintenant compressés, minifiés voir obscurcis on peut de moins en moins facilement lire le code d’une application web depuis son navigateur. Pourtant cela reste un des fondements du web.

Espérons que WebAssembly disposera d’une option de type source maps permettant de faire le lien entre le code généré et la source.

En tout cas WebAssembly me semble définitivement une technologie qui va compter dans les prochaines années.

L’équipe Synbioz.

Libres d’être ensemble.