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 chevronné 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 chevronné 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 éclairé 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".
Avatar de nhugodot nhugodot - Nouveau membre du Club https://www.developpez.com
le 02/03/2017 à 8:47
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...
Avatar de hotcryx hotcryx - Membre chevronné https://www.developpez.com
le 02/03/2017 à 10:11
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.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 02/03/2017 à 11:11
Citation Envoyé par hotcryx Voir le message
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.

Citation Envoyé par sekaijin Voir le message
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.

Citation Envoyé par nhugodot Voir le message
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é.
Avatar de hotcryx hotcryx - Membre chevronné https://www.developpez.com
le 02/03/2017 à 13:09
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.
Avatar de badaze badaze - Membre éclairé https://www.developpez.com
le 02/03/2017 à 16:29
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.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 02/03/2017 à 20:54
Citation Envoyé par badaze Voir le message
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.
Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 04/03/2017 à 11:06
Citation Envoyé par Uther Voir le message
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...
Même pas besoin de framework C'est le but même de l'existence de JavaScript côté client.

A+JYT
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 08/03/2017 à 14:46
@sekaijin: ton explication ne me paraît pas claire. Ce que tu décris est davantage le fonctionnement des compilateurs vers WASM que WASM lui-même.

WASM n'est pas un moteur ni un compilateur, c'est un format (deux en fait, une version binaire et une version texte). Il existe et existera de nombreux compilateurs de différents langages source vers ce format. L'existence d'au moins deux compilateurs différents est requise pour passer l'étape de Minimum Viable Product, mais leur implémentation ne fait pas partie des spécifications WASM.

Aussi le code WASM n'est pas un AST. Les AST sont les produits de l'analyse syntaxique du langage source, et donc propre à ce langage. Un compilateur C++ --> WASM utilisera un AST C++, un compilateur Python --> WASM un AST Python etc. D'ailleurs le format de l'AST n'est pas standardisé, on peut imaginer deux compilateurs du même langage avec deux formats d'AST différents. Du côté de WASM, il n'y a aucun AST puisque le format reçu par les navigateurs sera binaire. L'implémentation dans les navigateurs est simplement un décodeur, pas un compilateur: il ne "produit pas de code" à cette étape. Toutes les étapes qui utilisent l'AST à des fins d'optimisation sont faites en amont par le compilateur, et non pas par le navigateur.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 08/03/2017 à 15:47
Vous avez tous les deux raison :
- Sur le fond WebAssembly fournit une abstraction intermédiaire entre le langage et le binaire comme les bytecode classiques (Java, LLVM, ...)
- Sur la forme le WebAssembly se présente comme un AST dans le sens ou il est constitué sous forme d'arbre plutôt que d'une suite d'instructions.

Par contre le WebAssembly n'est pas l'AST du langage d'origine mais de l'AST d'un langage intermédiaire standard.
Avatar de Lcf.vs Lcf.vs - Membre éprouvé https://www.developpez.com
le 08/03/2017 à 19:07
Pitite question...

WASM, ok... mais j'me demande quand même pourquoi on pense directement à d'autres langages que le JS... après tout, il pourrait, lui aussi, être compilé et ça faciliterait grandement son adoption par la communauté des développeurs, puisqu'ils le connaissent déjà, non?
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 08/03/2017 à 23:52
JavaScript est déjà compilé par les moteurs web actuels en utilisant le plus d'optimisation spécifiques possible. Utiliser WebAssembly n'apporterait rien.
Le problème c'est que c'est un langage qui comme son nom l'indique a été conçu pour faire du script. Il a donc des points intrinsèquement problématiques pour des applications a grandes performances (GC, typage dynamique,...). Le but de WebAssemby est justement de permettre de reposer sur des base de plus bas niveau.
Avatar de Lcf.vs Lcf.vs - Membre éprouvé https://www.developpez.com
le 09/03/2017 à 0:06
Ben, justement... à mon sens, il pourrait te permettre de développer en JS... et de te convertir le tout en plus bas level, afin d'éviter la phase JIT
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 09/03/2017 à 7:22
Sauf que "convertir le tout en plus bas level" ne veux pas dire grand chose. Être "bas niveau" c'est gérer manuellement les détails comme l'allocation mémoire, les types, ... Or JavaScript de par sa conception se doit de gérer tout cela automatiquement.
Convertir automatiquement un code qui n'a pas a gérer la mémoire, c'est justement la définition du haut niveau.

Le JIT en soi n'est pas forcément du haut niveau. on peut faire du JIT en C++. Le WebAssembly ne permettra de toute façon pas de s'affranchir de l'étape de compilation vu que ça reste une représentation intermédiaire. La représentation est certes optimisée pour une compilation plus rapide. Mais vu toute les optimisations que font déjà les moteurs JavaScript actuels sur ces points avec généralement trois niveaux de compilation/interprétation suivant le besoin de prioritaire entre vitesse de compilation et performance, WebAssemby n'apportera certainement pas de gains visibles.
Avatar de Lcf.vs Lcf.vs - Membre éprouvé https://www.developpez.com
le 09/03/2017 à 9:00
Hum... mon incompréhension relève sans doute du fait de ma méconnaissance des langages de bas niveau...

Mais, à mon sens, sachant que ces optimisations sont connues, sachant aussi comment le JS est interprété et exécuté par un langage de plus bas niveau, je ne vois pas trop ce qui empêcherait de faire tout cela avant, de compiler le tout et de l'envoyer à WASM.

Je pense notamment à l'opcode, en PHP, qui fonctionne un peu sur le même principe, même si je ne sais pas si cet opcode est réellement déjà compilé.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 09/03/2017 à 10:00
Rien ne l’empêche de le faire, mais ça revient à refaire ce que les moteur JS actuels font déjà eux mêmes, sans doute mieux. On ne gagnera rien en performance.
Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 10/03/2017 à 17:09
il existe un prototype de compilateur pour un langage appelé thinscript
ça n'a absolument rien d'opérationnel.

ce qui est intéressant c'est que thinscript n'est que peu ou prou du TypeScript.
l'un comme l'autre sont des langages qui peuvent sans difficulté être interprété. Mais pour un usage normal on passe par une phase de compilation.
TypeScript fournis un compilateur écrit en typescript qui produit du js.
de ce fait le compilateur lui-même s'exécute sur node-js et produit un script JS.

thinscript est conçu de la même façon. il est écrit en thinscript mais il produit soit du js soit du c soit du wasm
ainsi le compilateur peut être recompilé avec gcc ou autre et produire un exécutable
mais une application produite avec thinScript pourra par ce biais être exécuté par node-js ou un navigateur si on a produit du js
sur une machine si on est passé par une compilation C
ou sur WebAssembly.

typescript tout comme thinscript sont des langage très proche de javascript. voire encore plus des dernière génération ecmascript.
il montre bien que de tels langages peuvent être compilés.
il est un point qui lui ne peut absolument pas être compilé c'est la génération de code dynamiquement. je ne parle pas d'affecter une fonction à un membre ou ce genre de chose mais bien de définir du code dans une string pour l’exécuter ensuite.
Mais ce point est facile à résoudre dans WASM moyennant quelques astuces. L'interactivité WASM/JS est prévue et il est possible de faire appel à JS pour évaluer un script. lors de la compilation il faut donc dans ce cas généré un appel à js
en gros tout le reste peut être compilé.

Quels intérêts ? j'en vois deux
permettre au développeur front de continuer à travailler dans leurs langages front.
produire un exécutable dont le source n'est pas "directement" accessible du client. (au même titre qu'un code C++ peut être désassemblé le code WASM peut être converti en AST lisible par un développeur.)
ces deux points sont des inquiétude forte de la communauté.

attention tout comme le projet thinscript il s'agit d'un test qui n'a pas vocation à aboutir.
j'ai écrit en thinscript un complément pour produire un compilateur thinscript qui s'exécute sur la JVM.
ce compilateur fonctionne avec eclipse et maven et produit directement depuis un sources thinscript un js un wasm un c
Mais il montre qu'on peut produire du WASM avec les outils habituels des développeurs.
Dans le même ordre d'idée en me basant sur http://www.jsweet.org/ j'ai regardé comment produire un WSAM à partir de java
Il ne s'agit pas d’exécuter une JVM ou du code JAVA sur le navigateur. il s'agit d'utilise la SYNTAXE java pour développer des appli front
seule la syntaxe est retenue. c'est la même approche que le compilateur java du gnu qui produit un exec pour votre machine.
il n'embarque pas de JVM seule la syntaxe est retenue. là encore le compilateur JAVA va produire un AST qu'il faut parcourir pour produire le wasm, d ela même façon que Javac parcours l'AST pour produire du ByteCode.

A+JYT
Avatar de Lcf.vs Lcf.vs - Membre éprouvé https://www.developpez.com
le 10/03/2017 à 20:10
Citation Envoyé par sekaijin Voir le message
Quels intérêts ? j'en vois deux
permettre au développeur front de continuer à travailler dans leurs langages front.
Ah, tu me rassures, mon idée ne semble donc pas si idiote que ça
Avatar de Stéphane le calme Stéphane le calme - Chroniqueur Actualités https://www.developpez.com
le 13/03/2017 à 12:42
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)
Avatar de Tartare2240 Tartare2240 - Membre régulier 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 éclairé 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 chevronné https://www.developpez.com
le 13/03/2017 à 16:30
Une tuerie les fleurs de l'arbre qui tombent
Avatar de micka132 micka132 - Membre émérite 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 régulier 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 émérite 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 actif 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 éprouvé 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à.
Avatar de Tartare2240 Tartare2240 - Membre régulier https://www.developpez.com
le 14/03/2017 à 9:31
Citation Envoyé par micka132 Voir le message
Ca ne changera strictement rien au fait que le navigateur doivent télécharger les 100 megas de Gimp.
A ce niveau-là, je suis d'accord, y'aura toujours le téléchargement qui risque de prendre des plombes. Mais de ce coté-là, je pense que ce sera le compilateur en WebAssembly qui peut gérer le système d'update, avec par exemple "Téléchargement de la dernière mise à jour terminée. Veuillez rafraichir votre navigateur pour en profiter pleinement." Et ça, ça me fait rêver

Un exemple pratique, il m'a été une fois demandé de faire un outil web pour une entreprise car déployer un logiciel sur tous les PC aurait été une véritable misère et aurait pris des semaines et car beaucoup de PC étaient encore sous Windows XP (en 2016). Cela aurait été beaucoup plus simple et plus rapide de créer un soft pour mais à cause de cette problématique, on a demanda une appli web. Avec WebAssembly, cette contrainte n'aurait pas existé
Avatar de Lcf.vs Lcf.vs - Membre éprouvé https://www.developpez.com
le 14/03/2017 à 9:48
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...
Scuce de l'expression... mais t'es un grand malade...

J'doute pas que certaines boites en arrivent là un jour mais j'trouve ça tellement inconscient, ne serait-ce que pour des raisons de coûts énergétiques/environnementaux
Avatar de Tartare2240 Tartare2240 - Membre régulier https://www.developpez.com
le 14/03/2017 à 10:10
Citation Envoyé par Lcf.vs Voir le message
Scuce de l'expression... mais t'es un grand malade...
On m'a toujours dit qu'il me manquait un grain quelque part

En fait je vois tellement de choses qui pourraient être faites par le consortium des navigateurs (mises en cache des ressources téléchargées, versionning...) et les avantages actuels du web (uniformité selon les OS, un seul code source...) que, avec une association de tous les grands noms, ça pourrait littéralement révolutionner le web qu'on voit aujourd'hui et lui rajouter toutes les grosses applications. Du coup, au niveau coût énergétique/environnemental, ce sera pas plus cher qu'un check régulier des versions et d'un téléchargement des nouvelles versions car tout serait stocké chez le client.
Avatar de LSMetag LSMetag - Membre expert https://www.developpez.com
le 14/03/2017 à 10:35
L'inconvénient que j'ai pu remarquer c'est que WebAssembly n'a vraiment un intérêt qu'à partir de technologies d'assez bas niveau comme le C++.

Le bytecode est un langage proche du langage machine. Donc le langage se doit d'être assez proche pour pouvoir gérer la mémoire, le processeur, de manière précise. Les garbage collector et optimisations "propriétaires" de langages de haut niveau seraient mis à mal, et au final, non seulement on pourrait, dans le cas de Dart (qui génère du javascript optimisé) ou de frameworks comme JQuery, générer un bytecode non optimisé et plus lent que le Javascript, mais également créer des failles de sécurité plus dangereuses (comme avec Java Web Start et les Applets Java) donnant alors un accès bas niveau à des hackers.

Des tests ont déjà été faits en ce sens, par exemple ici : https://medium.com/dartlang/dart-on-...a70#.wwqoasl55

C'est pour ça que WebAssembly serait très efficace, mais à partir de technologies pouvant être compilées en bytecode telles quelles, sans transformations préalables. Ce n'est pas la même utilité que le JS. C'est plus dédié à de véritables applications sur le web voire même des jeux vidéo 3D.
Avatar de bilgetz bilgetz - Membre actif https://www.developpez.com
le 14/03/2017 à 11:44
Citation Envoyé par Tartare2240 Voir le message
A ce niveau-là, je suis d'accord, y'aura toujours le téléchargement qui risque de prendre des plombes. Mais de ce coté-là, je pense que ce sera le compilateur en WebAssembly qui peut gérer le système d'update, avec par exemple "Téléchargement de la dernière mise à jour terminée. Veuillez rafraichir votre navigateur pour en profiter pleinement." Et ça, ça me fait rêver
Je pense plutôt à le coupler avec les service workers, qui est justement la pour faire ce boulot.
Avoir une version offline et télécharger en arrière plan la maj au besoin, notification via events des que c'est finie. Refresh pour avoir la nouvelle version.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 14/03/2017 à 12:19
Citation Envoyé par abriotde Voir le message
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.
...
A peu près d'accord sauf sur la lisibilité du code. Ça n’arrêtera jamais que les débutants. Et de toute façon si on veut faire du code illisible, il y a des outils qui font plus que de la simple minification tout en restant en JavaScript.

Pour les failles de sécurité, il n'y a pas de raison a ce qu'il n'y en ait plus en Wasm qu'en JavaScript. Les deux reposent sur les mêmes API et sont compilés en natif en JIT.

Citation Envoyé par Gugelhupf Voir le message
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).
En théorie, on peut déjà le faire maintenant, vu que rien ne t’empêche d'implémenter son propre GC en WASM.
C'est juste qu'on ne fera probablement pas mieux que ce que font déjà les navigateurs Web.

Citation Envoyé par champsy_dev Voir le message
À la vue des spécifications d'ASM on est loin de la mort de JavaScript
http://asmjs.org/spec/latest/
...
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) ?
Là, il y a un grosse confusion entre "asm.js" et "WebAssembly" : c'est deux technologies différentes, même si elles on des buts en partie communs.
- asm.js s'appuie sur le JavaScript car c'est la base minimale que gèrent tous les navigateurs web. Ça lui permet de pouvoir être exécutés sur tous les navigateurs, y compris ceux qui ne gèrent pas spécifiquement la technologie.
- WebAssembly (ou Wasm), au contraire ne se base plus sur JavaScript mais sur un bytecode qui vise à être bien plus efficace en temps de chargement et de compilation. Par contre il ne fonctionnera que sur les navigateurs qui le gèrent spécifiquement.

Citation Envoyé par Lcf.vs Voir le message
Scuce de l'expression... mais t'es un grand malade...

J'doute pas que certaines boites en arrivent là un jour mais j'trouve ça tellement inconscient, ne serait-ce que pour des raisons de coûts énergétiques/environnementaux
En jouant avec les spécifications récentes du W3C qui permettent de mettre explicitement des ressources en cache, ce n'est pas si idiot que ça en fait.
Offres d'emploi IT
Responsable de lot / architecte fpga H/F
Safran - Ile de France - Éragny (95610)
Ingénieur système de commande de vol H/F
Safran - Ile de France - Massy (91300)
Expert application Supply Chain & Achats H/F
Safran - Ile de France - Evry (91)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil