WebAssembly a-t-il pour vocation de remplacer à long terme JavaScript ?
Le standard est au centre des discussions des développeurs web

Le , par Stéphane le calme, Chroniqueur Actualités
Au départ, en 1995, JavaScript a été présenté comme un langage léger pour les scripts assez simples. De plus, il a été pensé de telle façon qu’il soit facilement utilisable, même par les développeurs novices, pour des choses relativement simples, comme s’assurer que vous avez rempli un formulaire correctement lorsque vous le soumettez par exemple.

Plus tard, en 2008, a été lancé ce qui a été désigné comme étant la guerre des performances ; les navigateurs ont commencé à ajouter la compilation à la volée (JIT, une technique visant à améliorer la performance de systèmes bytecode compilés par la traduction de bytecode en code machine natif au moment de l'exécution). Tandis que le JavaScript s’exécutait, le JIT pouvait voir des modèles et faire en sorte que le code s’exécute plus rapidement en fonction de ces modèles. C’est ce qui a contribué à l’amélioration des performances de JavaScript qui a alors commencé à être utilisé pour plus de choses qu’il n’était censé gérer au départ, comme la programmation côté serveur avec Node.js.

Pourtant, malgré ces améliorations, il arrive que les performances soient imprévisibles. Aussi, pour accélérer les choses, le JIT a ajouté quelques éléments à l'exécution, parmi lesquels :
  • l’optimisation et la désoptimisation ;
  • de la mémoire utilisée pour les informations de compatibilité et de récupération du moniteur pour les cas où des récupérations se produisent ;
  • de la mémoire utilisée pour stocker les versions de base et optimisées d'une fonction.

Autant d’éléments qui font qu’il arrive que le navigateur ne peut pas exécuter une application aussi rapidement qu’en natif. C’est alors qu’intervient WebAssembly.

Avec WebAssembly qui a été activé par défaut sur Firefox 52, le premier navigateur à l’embarquer, il serait intéressant de faire le point dessus. Tout d’abord, comme l’explique l’ingénieur Mozilla Lin Clark, « WebAssembly est un moyen de prendre du code écrit dans des langages de programmation autres que JavaScript et d'exécuter ce code dans le navigateur ».

Il est déjà arrivé sur des forums de discussion que les développeurs se demandent si WebAssembly a vocation de remplacer à long terme le JavaScript étant donné que le standard a été vanté comme étant « plus rapide que JavaScript ». Mais l’ingénieur tient à préciser que ce n’est pas le but ; s’il reconnaît également que WebAssembly s’avère plus rapide que JavaScript dans certains domaines, il précise qu’il ne veut pas sous-entendre que vous aurez à faire un choix entre WebAssembly et JavaScript : « en fait, nous nous attendons à ce que les développeurs utilisent WebAssembly et JavaScript dans la même application ».

Toutefois, pour bien souligner l’impact potentiel de WebAssembly, il a procédé à des séries d’études comparatives qui ont pour objectif de montrer aux développeurs en quoi WebAssembly est « plus rapide que JavaScript », tout en donnant des exemples concrets où des ingénieurs pourraient opter pour une coexistence de WebAssembly et JavaScript. Il a évoqué le cas de l’équipe React, de Facebook, qui pourrait remplacer le code de leur DOM virtuel par une version WebAssembly : « les gens qui utilisent React n’auront rien à faire ; leurs applications vont fonctionner comme avant et elles vont bénéficier des avantages apportés par WebAssembly ».

WebAssembly permettra donc aux applications complexes de fonctionner de façon optimale sur navigateur – telles que les jeux vidéo immersifs en 3D, le design informatisé, l’édition d’image et de vidéo et la visualisation scientifique. À ce propos, des démonstrations ont été mises en ligne l'année dernière, désormais il s’agit de passer à une implémentation concrète. Les développeurs pourront utiliser WebAssembly pour accélérer les applications web existantes.


Au fil du temps, de nombreuses applications de productivité existantes (par exemple les services de messagerie, les réseaux sociaux, les outils de traitement de texte) et des framework JavaScript vont probablement profiter de WebAssembly pour réduire considérablement les temps de chargement et améliorer simultanément les performances tout en fonctionnant. Contrairement à d'autres approches qui ont besoin de plug-ins pour obtenir des performances quasi natives dans le navigateur, WebAssembly fonctionne entièrement dans la plateforme Web. Cela signifie que les développeurs peuvent intégrer des bibliothèques WebAssembly pour des calculs intensifs (par exemple la compression, la détection de visage) dans des applications Web existantes qui utilisent JavaScript pour des travaux moins intensifs.

Pour avoir une idée du rendu avec WebAssembly, voici une démo proposée de Zen Garden par Epic Games qui allie WebAssembly et WebGL 2 dans Firefox 52.


« Nous espérons que, comme WebAssembly continue d'évoluer, vous pourrez également l'utiliser avec des langages de programmation souvent utilisés pour les applications mobiles, comme Java, Swift et C# », a déclaré Mozilla.

Source : introduction à WebAssembly (Mozilla Hack)

Mise à jour du 15/02/2018 : Les premiers projets publics de travail de WebAssembly sont disponibles

Le groupe de travail WebAssembly a publié trois premiers projets de travail publics :
  • WebAssembly Core Specification, qui décrit la version 1.0 de la norme WebAssembly de base, un format de code sécurisé, portable et de bas niveau conçu pour une exécution efficace et une représentation compacte ;
  • WebAssembly JavaScript Interface, qui fournit une API JavaScript explicite pour interagir avec WebAssembly ;
  • WebAssembly Web API, qui décrit l'intégration de WebAssembly avec des plateformes Web plus larges.

WebAssembly est une architecture de jeu d'instructions virtuel avec de nombreux cas d'utilisation et peut être intégrée dans de nombreux environnements différents, ce qui permet d’obtenir des applications hautes performances sur le Web. Le code WebAssembly est également conçu pour être facile à inspecter et à déboguer, en particulier dans des environnements tels que les navigateurs Web.

Source : W3C


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Tartare2240 Tartare2240 - Membre actif https://www.developpez.com
le 13/03/2017 à 14:31
Je pense personnellement que WebAssembly a un potentiel absolument spectaculaire, notamment au niveau de la VR et des applications lourdes qui seront encore plus faisables sur navigateur sans avoir besoin de téléchargement conséquent. Mais pour les sites web "classiques" comme on en voit aujourd'hui de partout, aucune raison de passer par autre chose que JS, il fait le travail.
Avatar de abriotde abriotde - Membre éprouvé https://www.developpez.com
le 13/03/2017 à 15:17
Il y a beaucoup de raison de passer a WebAssembly pour tous ou presque.
1) Pour les gros sites, avoir un site plus efficace (site plus rapide = plus de visiteurs).
2) Pour les royalties avoir un code encore plus illisible que la simple minification.
3) Pour les petits site, s'ils utilisent un framework (Jquery) ou un CMS), cela sera transparents... alors refuser des performances en plus.

Il restera toujours du javascript sur le web de même qu'il existe toujours des sites pur HTML (sans Javascript) pour plusieurs raison:
- Moins de failles de sécurité.
- Plus simple à développer / déployer.
...
Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 13/03/2017 à 16:10
Utiliser WebAssembly ne signifie pas que JavaScript va disparaître, rien n'empêchera de développer en JavaScript pour produire du WebAssembly (lorsque le GC sera opérationnel).
Nous pouvons faire un parallèle avec le bytecode de la JVM, on peut développer avec le langage que l'on souhaite (Scala, Groovy etc), ce n'est pas pour autant que le langage Java a disparu
Avatar de hotcryx hotcryx - Membre extrêmement actif https://www.developpez.com
le 13/03/2017 à 16:30
Une tuerie les fleurs de l'arbre qui tombent
Avatar de micka132 micka132 - Membre expert https://www.developpez.com
le 13/03/2017 à 17:13
Citation Envoyé par Tartare2240 Voir le message
des applications lourdes qui seront encore plus faisables sur navigateur sans avoir besoin de téléchargement conséquent.
Tu parles de quels téléchargements conséquents?
Avatar de Tartare2240 Tartare2240 - Membre actif https://www.developpez.com
le 13/03/2017 à 17:21
Exemple totalement bancal : le jour où on arrivera à faire un outil aussi puissant que GIMP directement avec WebAssembly, on aura plus besoin de télécharger GIMP et, lorsqu'on voudra l'utiliser, on aura toujours la dernière version. Certes le serveur devra envoyer un sacré paquet de données à toutes les personnes voulant l'utiliser mais avec le futur de la connexion web, ce sera pas trop un problème... Enfin je l'espère... Ahem...

* A été traumatisé par les mises à jour Java *
Avatar de micka132 micka132 - Membre expert https://www.developpez.com
le 13/03/2017 à 17:39
Citation Envoyé par Tartare2240 Voir le message
Exemple totalement bancal : le jour où on arrivera à faire un outil aussi puissant que GIMP directement avec WebAssembly, on aura plus besoin de télécharger GIMP et, lorsqu'on voudra l'utiliser, on aura toujours la dernière version. Certes le serveur devra envoyer un sacré paquet de données à toutes les personnes voulant l'utiliser mais avec le futur de la connexion web, ce sera pas trop un problème... Enfin je l'espère... Ahem...

* A été traumatisé par les mises à jour Java *
Ca ne changera strictement rien au fait que le navigateur doivent télécharger les 100 megas de Gimp.
Au mieux ca simplifie un peu pour les développeurs qui ne doivent pas se soucier de comment faire parvenir les mise à jour automatiquement vers le client.
D'un autre coté ca va poser les problèmes à l'utilisateur qui veut faire rapidement une petite modif sur un fichier pour une présentation dans 10 min et qui doit attendre que la mise à jour se termine...pas de bol ce jour là son internet rame à mort . Pour gérer ces cas là finalement il faudra un mécanisme de téléchargement en fond avec rechargement partiel...bref le developpeur y reperdra .
En vérité WebAssembly c'est comme flash ou les applets java, sauf que les gros du web se sont plus ou moins entendus pour pondre un truc en commun, mais ca n'a absolument rien de révolutionnaire.
Il y a donc les meme avantages : un developpement simplifié par rapport à JS avec des performances normalement meilleurs, sauf que ca sera non maitrisé par certains dev et comme flash on va se retrouver avec un affichage de texte qui te tue ton navigateur sans raison apparente...
Avatar de pol2095 pol2095 - Membre régulier https://www.developpez.com
le 13/03/2017 à 17:51
Je pense que le niveau générale des programmeurs web est très faible, ça n'aura qu'une faible portée.
Vu la place qu'on pris les apps sur mobile, ça arrive trop tard, de plus par rapport à une app, le navigateur à quand même de grosses restrictions, ne serait-ce que pour l'accès au disque local ?
Ensuite il y a quand même la surcouche du navigateur, qui fera qu'il sera toujours plus lent qu'une app native.
Tout est bon quand même pour se débarrasser de la daube javascript, qui n'est pas du tout adapter pour de gros projet (absence de classes...).
C++ par exemple dépend de la compétence des programmeurs et peut très vite créer des failles importantes sur un système, et peut même s'avérer très lent s'il est mal programmé, et quand on regarde la qualité des bibliothèques javascript c'est inquiétant.
Avatar de champsy_dev champsy_dev - Membre averti https://www.developpez.com
le 13/03/2017 à 21:43
À la vue des spécifications d'ASM on est loin de la mort de JavaScript http://asmjs.org/spec/latest/

This specification defines asm.js, a strict subset of JavaScript that can be used as a low-level, efficient target language for compilers. This sublanguage effectively describes a sandboxed virtual machine for memory-unsafe languages like C or C++. A combination of static and dynamic validation allows JavaScript engines to employ an ahead-of-time (AOT) optimizing compilation strategy for valid asm.js code.
Les développeurs C et C++ penseront certainement que la spécification a été écrite par un développeur JavaScript ( for memory-unsafe languages like C or C++ je dirais plutôt developer-unsafe languages )

Le problème resteras toujours le même tant que les différents paradigmes des langages de programmation ne serons pas clairement distingué pendant les formations des futures développeurs, on apprend généralement cette distinction mais on s'en rend réellement compte que bien après, après des années de POO ou de prototypages voir de programmation fonctionnelle pour les plus originaux, du coup passer de l'un à l'autre demande une gymnastique mentale qui arrive souvent trop tard dans la vie professionnelle.

Les dev .Net ou Java s'échinerons toujours corps et âme à trouver la librairie Javascript qui permet de faire de la POO quand on leur demandera de migrer leur belle application Desktop en Full Web plutôt que de révisé leur façon de faire (sans jeter la pierre j'ai fait pareil).

Et les développeurs Javascript, et bien ceux-là ils peuvent pleurer pour ajouter une méthode à un prototype sans passer par une étude approfondie des méthodes d'extension .Net (et encore en lisant les Guideline ils comprendrons que c'est déconseillé).

La cible première d'ASM est clairement JavaScript. Doit-il disparaître pour autant ... En relisant tous vos messages il semble évident que ceux qui développe du front depuis un peu de temps font rarement du javascript, plutôt du Type Script, du Dart ou autre, avec des grunts,des gulps pour automatiser tout ce qui peut l'être. Donc pourquoi ASM s'appuie sur JavaScript et pas directement sur un de ces langages (qui disposent de tout ce qu'il faut à mon avis pour être directement compilé sans passer par la case JavaScript) ?
Avatar de marsupial marsupial - Membre émérite https://www.developpez.com
le 14/03/2017 à 1:09
* le navigateur s'affranchit du matériel grâce à l'OS
* JS comme WebAssembly sont standardisés

==> des applications métiers totalement portables et indépendantes de l'environnement système/matériel

Je ne vois pas son avenir dans les sites web en dehors de quelques retouches par-ci par-là.
Contacter le responsable de la rubrique Accueil