C’est ainsi qu’est né le projet WebAssembly, qui est soutenu par Google, Mozilla, Microsoft et des développeurs du moteur de rendu Web Webkit. WebAssembly est un format binaire pour la compilation d’applications pour le Web.
En novembre 2016, Google, Mozilla et Microsoft ont annoncé la disponibilité d’une WebAssembly Browser Preview. Cette étape a marqué entre autres :
- une RC pour le design MVP (terme qui désigne la plus petite entité productible, utilisable et vendable dans le domaine informatique) qui inclut notamment la sémantique, le format binaire et l'API JS ;
- des implémentations compatibles et stables de WebAssembly dans V8 et SpiderMonkey, dans les builds de développement de Chakra et en progression dans JavaScriptCore ;
- une chaîne d'outils de travail pour les développeurs qui veulent compiler des modules WebAssembly à partir de fichiers sources C / C ++.
Conformément à sa feuille de route, la WebAssembly Community Group a annoncé hier être arrivé la fin de cette étape.
« Les membres WebAssembly CG représentant les quatre navigateurs Chrome, Edge, Firefox et WebKit, sont parvenus à un consensus sur le fait que la conception de la première API WebAssembly et le format binaire sont complets dans la mesure où aucun autre travail de conception n’est possible sans expérience de mise en œuvre et usage. Ceci marque la fin de la Browser Preview et indique que les navigateurs peuvent commencer à livrer WebAssembly par défaut. Dès lors, les fonctionnalités futures seront conçues pour assurer la compatibilité ascendante », a déclaré Luke Wagner, un ingénieur travaillant pour le compte de Mozilla et membre de la WebAssembly Community Group.
Il a expliqué que le consensus inclut une API JavaScript et un format binaire accompagnés d'un interprète de référence. Il est possible de tester WebAssembly à l'aide de la chaîne d'outils Emscripten.
« Les prochaines étapes consisteront à former un groupe de travail du W3C, pour élaborer des spécifications pour la version initiale de WebAssembly et de continuer à travailler sur l’itération des futures fonctionnalités au sein de l’actuel WebAssembly Community Group », a-t-il continué.
Il est important de préciser que développer avec WebAssembly n’implique pas abandonner JavaScript. Comme le note Lin Clark, un ingénieur au sein de l’équipe Mozilla Developer Relations, « les développeurs n'ont pas besoin de choisir entre WebAssembly et JavaScript pour leurs applications. Cependant, nous nous attendons à ce que les développeurs échangent des parties de leur code JavaScript pour du WebAssembly ».
Il a proposé une petite comparaison entre JavaScript et WebAssembly où WebAssembly s’avère plus rapide (et donc plus adapté ?) dans certains cas que JavaScript parce que :
- faire de la récupération de données avec WebAssembly prend moins de temps, car il est plus compact que JavaScript, même lorsqu'il est compressé ;
- décoder WebAssembly prend moins de temps que l'analyse de JavaScript ;
- la compilation et l'optimisation prennent moins de temps avec WebAssembly étant donné que ce dernier est plus proche du code machine que JavaScript et a déjà subi une optimisation côté serveur ;
- la réoptimisation n’est pas nécessaire puisque WebAssembly a des types et d'autres informations intégrés, de sorte que le moteur JS n'a pas besoin de spéculer quand il optimise de la façon dont il le fait avec JavaScript ;
- l’exécution prend souvent moins de temps étant donné que l’ensemble d’instructions de WebAssembly est plus idéal pour les machines ;
- la mémoire est gérée manuellement.
Source : annonce du consensus, comparaison entre WebAssembly et JavaScript