Discussion :

[Stéphane le calme]

Les principaux navigateurs peuvent déjà livrer des versions avec WebAssembly activé par défaut,
en attendant les spécifications de la première version

É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

[Lcf.vs]

Intéressant... mais pas pour demain, alors qu'on doit encore faire du compatible IE.

[tralloc]

Très bonne nouvelle !

[michel.bosseaux]

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.

[hotcryx]

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

[tralloc]

Oui c'est le moteur unity dans la démo.
Par contre j'aimerais bien moi aussi savoir comment ça marche.

[sekaijin]

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

[Invité]

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 !

[Michael Guilloux]

Le support de WebAssembly est désormais disponible dans tous les principaux navigateurs
Safari et Microsoft Edge emboîtent le pas à Firefox et Chrome

WebAssembly, ou wasm, est un nouveau type de code qui peut être exécuté dans un navigateur web moderne. C'est un langage bas niveau semblable à l'assembleur, permettant d'atteindre des performances proches des applications natives (par exemple écrites en C/C++) tout en fonctionnant sur le Web. WebAssembly est conçu pour fonctionner en lien avec JavaScript et, en passe de devenir une norme dans l'industrie, il donne aux développeurs web un certain nombre d'options qu'ils n'avaient pas auparavant. Il leur permet par exemple de :

• profiter du format compact wasm pour transmettre des fichiers rapidement sur le réseau et les charger en tant que modules JavaScript ;
• obtenir des performances quasi natives sans utiliser de plug-in ;
• écrire un code à la fois performant et sécurisé, car il s'exécute dans le sandbox de sécurité du navigateur ;
• avoir un choix de langages en dehors de JavaScript. Il permet par exemple aux développeurs d'écrire du code en C ou C++, puis de compiler directement en wasm, sans devoir compiler le code en JavaScript d'abord. En dehors de C/C++, des langages supplémentaires seront supportés à l'avenir.

Avec les avantages qu’il présente, il n’a fallu que deux ans à tous les principaux fournisseurs de navigateurs pour prendre en charge le nouveau standard. Hier, dans un billet de blog, Mozilla a en effet annoncé que le support WebAssembly est désormais disponible dans tous les principaux navigateurs. Au cours des dernières semaines, Apple et Microsoft ont fourni de nouvelles versions de Safari et Edge, avec le support de WebAssembly. Étant donné que Mozilla Firefox et Google Chrome prenaient déjà en charge WebAssembly, cela veut dire que les quatre principaux navigateurs sont désormais capables de générer du code compilé dans le format wasm sur le Web.

« Google, Apple et Microsoft s'étaient tous engagés à prendre en charge WebAssembly dans leurs navigateurs. Avoir ce support sur le marché aujourd'hui est un développement vraiment passionnant », a déclaré Luke Wagner, l'ingénieur de Mozilla qui a créé le précurseur de WebAssembly, asm.js, et qui a dirigé le travail sur la spécification WebAssembly.

Pour les développeurs, la prise en charge du nouveau standard par les principaux navigateurs signifie qu'ils peuvent tirer parti de WebAssembly avec l'assurance que la plupart des utilisateurs seront en mesure d'exécuter des modules wasm par défaut.

WebAssembly apporte des performances sur le Web qu'il est extrêmement difficile d'atteindre avec JavaScript seul, notamment pour l'industrie du jeu. « Asm.js et WebAssembly étaient sans l'ombre d'un doute pour les entreprises de l'industrie du jeu, car elles avaient d'énormes investissements dans des programmes en C ++ qu'elles ne voulaient pas réécrire pour le Web », a déclaré Wagner. Raison pour laquelle cette industrie a été la première à adopter WebAssembly et asm.js. D’après l’ingénieur de Mozilla, Epic et Unity ont devancé les autres en étant les premiers à mettre en ligne leurs moteurs de jeu à l'échelle industrielle sans réécrire les bases de code C++ en JavaScript.

Mais aujourd'hui, les cas d'utilisation de WebAssembly et asm.js se sont développés au-delà des jeux en ligne. À mesure que les utilisateurs expérimentent le processus d'utilisation du format WebAssembly, et du compilateur Emscripten, ils trouvent des moyens de transférer des applications de plus en plus sophistiquées vers le Web. D'après Luke Wagner, les applications portées sur le Web grâce à WebAssembly couvrent divers domaines, y compris la vision par ordinateur, la cartographie 3D, le traitement des signaux numériques, l'imagerie médicale, la simulation physique, le chiffrement, la compression, etc. « Nous voyons maintenant des gens utiliser WebAssembly pour toutes sortes de nouveaux projets », dit-il. Pour lui, cela promet que nous serons un jour capables de faire tourner n'importe quelle application sur le Web et de la faire fonctionner comme si elle fonctionnait localement sur un PC.

Source : Blog Mozilla

Et vous ?

Qu’en pensez-vous ?

[maitredede]

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".

[nhugodot]

Un grand merci à l'explication complète!

J'ajoute que le code WebAssembly état binaire, compressé, il est plus petit donc rapide de charger une page web type SPA, lourde, webapp, et que ça va alléger notre 4G (ou 3G en Inde low cost par exemple)

Que cela permet aussi d'être sécurisé car un pirate interceptant la communication ne pourra lire le code comme il peut le faire avec tout script (donc dont JavaScript /ES) et injecter du code (vers le navigateur ou le serveur) (ai je bien compris?)

Bref, plus rapide, plus sécurisé, on a tout gagné.

Liberté:

Et bien sûr, on va voir enfin poindre sans doute du Ruby PHP et Python POUR NAVIGATEUR, à la place de JS... Tous les frameworks vont pouvoir devenir full-stack enfin: vu le plaisir et la facilité de Ruby, l'écosystème PHP, ou l'universalité de Python, versus la Javascript fatigue, ça va drôlement changer les choses, et on pourra enfin faire un site web avec son language préféré.

Manque une brique dans cet écosystème néanmoins: les apps smartphones:

en mobile, on veut une app plus qu'une page web (idiot mais ok...), et le dev d'apps se faisant en natif Swift pour iOS ou Java pour Android, avec néanmoins une alternative type JS via React Native de Facebook (ce que nous faisons chez nous, merci FB!) qui ensuite et porté sur iOS ou Android (ou Web tout court...), quid de WebAssembly ici sur les apps?
Je vois un futur de WebApps en progressive web apps (très belle techno balbutiante!) donc bien sur le moteur web... Webkit... aïe, Apple fait encore des siennes et n'est pas partie prenante de WebAssembly (fuck la pomme, grrrr...) et son Safari ne le supportera pas. On revient avec le problème: comment faire du natif iOS sans Swift (ni Objective-C), sans JS (que Safari, lui, supporte...)? Ah mais je me trompe peut-être, Safari est sur Webkit et donc ... ça marcherait? J''ai un doute...

Un dernier point: WASM vs Java et les IoT:

Java était "code once, run anywhere" grâce à sa JVM sur donc un "CPU virtuel idéal". Ok ok... Mais là nous avons donc une autre techno assez similaire, en tout cas qui vise aussi à l'universalité (run anywhere) MAIS qui casse le gros problème de Java: Java lui-même (et ces mossieurs d'Oracle...): on peut ENFIN coder en tout language, et viser cette machine virtuelle (WebAssembly) universelle (on peut sûrement la porter ailleurs que sur un navigateur Web, tiens! Un embedded device? Automobile, GPS, etc.?)
Il serait intéressant de faire un comparatif de performance non pas JS versus WASM mais WASM versus Java JVM!!! En avez vous? Kill java...? ;-)
Avec les IoT qui déboulent (et leur non sécurité..., et leurs réseaux lents type SigFox à 3-5 SMS par jour, leur micro CPU lent, faible mémoire, etc.) WASM pourrait être un bon remplaçant à Java (qui a été d'ailleurs exactement fait pour ça, des micro-programmes téléchargeables! Je faisais des apps java sur SIM 16K envoyées par bouts de code par SMS en 98... c'est dire! Minitel était un superordinateur à côté...)

Les années 20 (2020... ;D) vont être prometteuses...

[hotcryx]

Si le code peut être compilé en assemblies, je crains la venue de petits virus... (mieux cachés).

JS ne va pas disparaître puisqu'il restera en amont, ni TrueScript, ni Java, un langage très portable et accessible par définition.

[Uther]

Donc WebAssembly est lié à WebGL?

Pas directement, mais il est fort probable que les utilisateurs de WebGL auront tout intérêt a utiliser WebAssembly pour profiter de meilleures performance et de langages plus habituels.

On voit que les étapes les plus coûteuses sont les 3 premières.

En fait tout dépend le niveau d'optimisation voulu. Si un veut un code très optimisé les dernières étapes sont de loin les plus couteuses.

Je pense que les moteur WASM essaieront d'optimiser ça un peu comme les moteur JIT Javascript actuels, en faisant d'abord une compilation rapide et mais optimisée histoire de démarrer rapidement. Puis ils feront une compilation plus optimisée pour le code qui nécessite plus de performances.

Que cela permet aussi d'être sécurisé car un pirate interceptant la communication ne pourra lire le code comme il peut le faire avec tout script (donc dont JavaScript /ES) et injecter du code (vers le navigateur ou le serveur) (ai je bien compris?)

Ce point là est faux : comme tout les bytecodes/binaires, le WebAssembly peut se désassembler et les code obtenu sera probablement plus lisible que du JavaScript brouillé.
Cacher le code n'a jamais amélioré la sécurité.

[hotcryx]

comme tout les programmes, le WebAssembly peut se désassembler et les code obtenu sera probablement plus lisible que du JavaScript brouillé.

Si le code est compilé (et pas interprèté) en C, C++, oui tu pourras le déassambler mais ce sera très très obscur.
Rien à voir avec du byte code.

[badaze]

Donc on va s'orienter vers des pages web qui ne contiendront plus que les balises html, head et body + le chargement des web assemblies qui génèreront le html via le DOM. Ce sont les éditeurs qui vont être contents.
On ne pourra plus voir les techniques utilisées. Dommage.

[Uther]

Donc on va s'orienter vers des pages web qui ne contiendront plus que les balises html, head et body + le chargement des web assemblies qui génèreront le html via le DOM. Ce sont les éditeurs qui vont être contents.
On ne pourra plus voir les techniques utilisées. Dommage.

Pour info, ils n'y a pas besoin de WebAssembly pour faire des pages entièrement basées sur la manipulation du DOM : c'est déjà ce que font des frameworks populaires comme ReactJS. A terme WebAssembly permettrait de faire ça, comme JavaScript le permet déjà, mais ça n'est clairement pas son but premier. D'ailleurs, la première version qui vient d'être acceptée ne permet pas encore de le faire directement.

Le but est surtout de remplacer avantageusement les codes lourds en JavaScript (jeux, animation,...) qui de toute façon sont le plus souvent déjà à base de JavaScript généré et très difficilement lisibles.

WebAssembly n'apporte rien qui ne soit déjà fait faisable (et déjà fait) avec JavaScript. Il aura juste de meilleures performances en temps de chargement et en vitesse d’exécution.

[Stéphane le calme]

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

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

[Tartare2240]

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.

[micka132]

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?

[Tartare2240]

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 *