WebAssembly : Chrome, Firefox et Edge peuvent déjà livrer des versions de leurs navigateurs
Avec WebAssembly activé par défaut

Le , par Stéphane le calme, Chroniqueur Actualités
Étant donné que les applications Web gagnent de plus en plus en complexité, les éditeurs de navigateurs ont apporté de nombreuses optimisations à leur moteur d’exécution JavaScript, afin d’en améliorer les performances. Toutefois, pour ne pas évoluer de façon dispersée, ils se sont mis ensemble pour tirer parti du meilleur de leurs précédents investissements pour développer une solution qui pourra bénéficier d’une large prise en charge.

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


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


 Poster une réponse

Avatar de Lcf.vs Lcf.vs - Membre éprouvé https://www.developpez.com
le 01/03/2017 à 12:51
Intéressant... mais pas pour demain, alors qu'on doit encore faire du compatible IE.
Avatar de tralloc tralloc - Membre actif https://www.developpez.com
le 01/03/2017 à 13:01
Très bonne nouvelle !
Avatar de hotcryx hotcryx - Membre émérite https://www.developpez.com
le 01/03/2017 à 13:54
Donc WebAssembly est lié à WebGL?
Avatar de michel.bosseaux michel.bosseaux - Membre averti https://www.developpez.com
le 01/03/2017 à 14:46
hotcryx : je ne vois pas ce qui, dans cet article, t'as permis de lier Webassembly (qui se veut un format binaire pour le web, et donc permet d'écrire en n'importe quel langage, compiler vers webassembly pour utiliser ensuite dans le navigateur) avec WebGL, qui concerne la 3D dans le navigateur. Tu es le seul à avoir mentionné WebGL (que ce soit dans l'article ou les commentaires, aucune autre référence n'y est faite).
Les technologies n'ont strictement rien à voir. On peut peut-être imaginer qu'un code au format Webassembly pourra utiliser, si nécessaire, la technologie WebGL si le but est d'afficher de la 3D. Mais à part cela, les buts des deux technologies sont tout à fait différents.
Avatar de hotcryx hotcryx - Membre émérite https://www.developpez.com
le 01/03/2017 à 16:50
C'était une question
Je sais qu'on ne parle pas de webGL mais il y a un article récent et quand je vois la démo, ça laisse supposer que ce pourrait être du webGL.
N'était ce pas le moteur Unity dans la démo
Avatar de tralloc tralloc - Membre actif https://www.developpez.com
le 01/03/2017 à 16:53
Oui c'est le moteur unity dans la démo.
Par contre j'aimerais bien moi aussi savoir comment ça marche.
Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 01/03/2017 à 18:42
Pour répondre à cette question il faut revenir au fondement des langages et des compilateurs/interprètes.

Que ce soit un compilateur et une exécution ou une interprétation le processus est semblable.

On part d'un code source dans un langage, et on abouti à un binaire exécuté par le processeur.
La différence entre compilation/exécution et interprétation se situe dans le temps. À quel moment, on fait certaines actions pour passer du code source au binaire*?

Pour faire simple ce processus passe par plusieurs étapes.
  1. Lecture du flux de caractères du code source.
  2. Regroupement en "mot" des éléments du langage.
  3. Analyse syntaxique
  4. Analyse sémantique
  5. Production binaire
  6. Exécution.


Dans le cas d'un compilateur/exécution les étapes 1 à 5 sont faites à la compilation.
Dans le cas d'un interprète elles sont faites à l'exécution.

Pour passer d'une étape à une autre il y a échange d'information dans une structure dédiée.
Entre l'étape 3 et l'étape 4 la structure communément utilisée est un Arbre Syntaxique Abstrait: AST.
Cet arbre représente l'ensemble du code qui devra être exécuté. Sa production contient une représentation de tout le code source.
mais il peut subir de nombreuse modification (les compilateurs sont les champions de l'optimisation)
par exemple
Supprimer le code mort.
Supprimer les tests inutiles.
etc.

L'arbre étant une structure simple son parcours pour faire l'analyse sémantique est facilité. Ce processus consiste à définir ce que doit faire le programme.
Il existe plusieurs façons de définir ce que produit cette étape.
La dernière étape est la production du binaire. Qui là encore va utiliser la structure simple produite par l'analyse sémantique pour travailler.
Cette étape va grandement dépendre du processeur cible.

On voit que les étapes les plus coûteuses sont les 3 premières.
Ce que propose WASM c'est une définition commune de l'AST.
Cette définition commune permet beaucoup de choses.
La première est que de nombreux langages peuvent être analysés et produire un AST conforme.
La deuxième est que l'analyseur sémantique ne dépend plus que de l'AST. on peut donc produire du code pour de nombreuses cibles. De nombreux acteurs peuvent proposer un producteur alternatif.

WASM va un cran plus loin en affichant la volonté de définir un format binaire universel pour enregistrer cet arbre dans un flux (fichier)
Cela permet de séparer la phase d'analyse de la phase de production.
Cette dernière peut donc être faite dans le navigateur.
Les avantages par rapport à une interprétation sont que la coûteuse analyse et déjà faite. Les optimisations de code peuvent être déjà faites. Le format de l'AST est compact (mieux sur le net). La structure est très basique donc facile à lire (pour une machine). La production de code machine est facilité.

Comment cela s'intègre dans le navigateur*? Le navigateur possède plusieurs moteurs le premier est le moteur d'interprétation du HTML qui passe du code html svg xml au DOM le second est le moteur JavaScript qui relie le code js au DOM.
Ce moteur est un compilateur à la volée. Il conserve dans sa mémoire les blocs de code qu'il a déjà interprété. Ces deux moteurs accèdent au du code natif du navigateur. Pour cela une table de point d'entrée est conservée dans le moteur js. Ce qui permet à du js d'invoquer les fonctions d'un plug-in par exemple.
L'arrivée de WASM ne remet pas tout ça en cause. Elle le complète.
Le moteur WASM va prendre en charge les AST. il va finir la compilation (étape 4 et 5) et ajouter des points d'entrées dans la table. Le code WASM sera vu par le moteur JS comme du code natif ce qu'il est réellement.
Toute la finesse du moteur va résider dans sa stratégie.
Il peut par exemple compiler tout l'AST dès la réception mais cela peut prendre du temps (si l'AST est très gros).
Il peut ne compiler qu'une partie et remettre à plus tard (lors d'une activation d'une portion de code) le reste.
il peut profiter des temps de faible activité
etc.

Pour faire très bref WASM est appliquer le principe de la compilation en reportant sur le client la dernière phase qui le production de code.

Il ne s'agit pas comme dans la JVM de byteCode le compilateur java compile comme le compilateur C mais pour un processeur idéal qui n'existe pas. La JVM exécute ce code en simulant ce processeur et suivant le contexte le bytecode lui-même compilé à la volé en code machine.

Pour finir tout AST peut être interprété (on fait des interprètes C ou C++ par exemple) il en va de même avec WASM.

A+JYT
Avatar de Mrsky Mrsky - Membre confirmé https://www.developpez.com
le 01/03/2017 à 21:36
Superbe explication ! Pour un dev web comme moi qui ne traite qu'avec du très haut niveau et qui va sûrement devoir toucher a WASM ça va m’être très utile comme point de départ pour mes recherches. Merci !
Avatar de badaze badaze - Membre éprouvé https://www.developpez.com
le 02/03/2017 à 0:31
De ce que j'ai compris on pourra écrire des web assemblies à partir de langages de plus haut niveau du moment qu'il existe un "compilateur" (je mets exprès entre guillemets) qui génère du code web assembly.

Questions
Qu'en est-il de la sécurité ? Est-ce que les web assemblies auront accès au système de fichiers des PC qui les exécutent par exemple ?
Est-ce que les navigateurs pourront être paramétrés pour ne pas les exécuter ?
Avatar de maitredede maitredede - Membre régulier https://www.developpez.com
le 02/03/2017 à 6:51
Pour ce qui est de la sécurité, vu que la conversion de l'AST vers le binaire est laissé au choix du navigateur, il va pouvoir mettre l'accent sécurité sur les instructions dangereuses. Par exemple, quand un programme voudra lire une variable en mémoire, la méthode de "lecture de mémoire" ne permettra pas de sortir de la zone allouée au javascript de la page. De la même manière, "écrire une variable en mémoire" ne permettra pas d'écrire en dehors de cette zone, empêchant du même coup les "buffer overflow" qui permettent entre autre "l'exécution de code arbitraire".
Contacter le responsable de la rubrique Accueil