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)


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 du Club 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 expérimenté 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 du Club 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 du Club 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 du Club 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 du Club 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.
Avatar de pol2095 pol2095 - Membre du Club https://www.developpez.com
le 14/03/2017 à 12:40
Pour la vitesse, ça dépend également du compilateur C++ intégré dans le navigateur.
Est-ce qu'il y a des limitations, par exemple sous Windows, a-t-on accès aux librairies Windows comme "Winhttp"... ?
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 14/03/2017 à 13:01
Citation Envoyé par pol2095 Voir le message
Pour la vitesse, ça dépend également du compilateur C++ intégré dans le navigateur.
Est-ce qu'il y a des limitations, par exemple sous Windows, a-t-on accès aux librairies Windows comme "Winhttp"... ?
Il n'y a pas de compilateur C++ intégré au navigateur. Le système de fonctionnement sera du type :
Code : Sélectionner tout
1
2
3
4
5
+--------------------+     +---------+     +-------------+
| Developpeur        |     | Serveur |     |  Navigateur |
+--------------------+ ==> +---------+ ==> +-------------+
|C++/Rust/... -> Wasm|     | Wasm    |     |Wasm -> natif|
+--------------------+     +---------+     +-------------+
Le Wasm aura accès aux même API que JavaScript, ni plus ni moins.
Avatar de pol2095 pol2095 - Membre du Club https://www.developpez.com
le 14/03/2017 à 14:26
D'accord, c'est un langage de bytecode (comme Java) donc moins rapide que du natif, mais plus facile à faire fonctionner sur des systèmes différents.
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 14/03/2017 à 14:31
Pour info, Qt - une bibliothèque C++ très utilisée - continue d'investir dans ce genre de techno et planifie pour la version 5.10 (la version actuelle est la 5.8) de pouvoir faire tourner le rendu graphique à distance depuis un navigateur. Je vous laisse imaginer les possibilités en termes d’interaction (via wifi) avec des objets connectés... (plus besoin d'installer une application sur son smart phone !)

Running Qt applications in a browser via Native Client (NaCl) has been possible since 2009 and since Qt 5.8 VNC can be used for remote control of Qt applications. However these options are often not as convenient as desired. With Qt 5.10 we are planning to support streaming of Qt Quick application UIs over a network to a browser using WebGL. This streaming of OpenGL commands will allow using a common browser as a remote display of a Qt application running e.g. in a nearby embedded system or far across a network. Input from touch/mouse as well as keyboard is transmitted back to the Qt application. WebGL streaming will be implemented as a platform plugin in Qt 5.10. The streaming plugin converts all painting commands to WebGL commands and transmits the streams to clients. In turn those clients transmit user input back. Clients can be Qt applications or any web browser capable of showing WebGL 1.0.
http://blog.qt.io/blog/2017/02/22/qt-roadmap-for-2017/
Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 14/03/2017 à 18:22
Citation Envoyé par pol2095 Voir le message
D'accord, c'est un langage de bytecode (comme Java) donc moins rapide que du natif, mais plus facile à faire fonctionner sur des systèmes différents.
non ce n'est pas du bytecode

le bytecode est un code pour un processeur imaginaire qui aurait un nombre illimité de registre.

WASM est un arbre syntaxique
pour simplifier à l'extrême c'est un peut comme une fonction écrite en lisp les noeud sont les opérateurs et les feuilles des opérandes.
Voici un exemple d'AST généré par Clang
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
$ cat test.cc
int f(int x) {
  int result = (x / 42);
  return result;
}
 
# Clang by default is a frontend for many tools; -Xclang is used to pass
# options directly to the C++ frontend.
$ clang -Xclang -ast-dump -fsyntax-only test.cc
TranslationUnitDecl 0x5aea0d0 <<invalid sloc>>
... cutting out internal declarations of clang ...
`-FunctionDecl 0x5aeab50 <test.cc:1:1, line:4:1> f 'int (int)'
  |-ParmVarDecl 0x5aeaa90 <line:1:7, col:11> x 'int'
  `-CompoundStmt 0x5aead88 <col:14, line:4:1>
    |-DeclStmt 0x5aead10 <line:2:3, col:24>
    | `-VarDecl 0x5aeac10 <col:3, col:23> result 'int'
    |   `-ParenExpr 0x5aeacf0 <col:16, col:23> 'int'
    |     `-BinaryOperator 0x5aeacc8 <col:17, col:21> 'int' '/'
    |       |-ImplicitCastExpr 0x5aeacb0 <col:17> 'int' <LValueToRValue>
    |       | `-DeclRefExpr 0x5aeac68 <col:17> 'int' lvalue ParmVar 0x5aeaa90 'x' 'int'
    |       `-IntegerLiteral 0x5aeac90 <col:21> 'int' 42
    `-ReturnStmt 0x5aead68 <line:3:3, col:10>
      `-ImplicitCastExpr 0x5aead50 <col:10> 'int' <LValueToRValue>
        `-DeclRefExpr 0x5aead28 <col:10> 'int' lvalue Var 0x5aeac10 'result' 'int'
Ceci n'a rien à voir avec un code de type bytecode.

WASM est une représentation binaire de ce type d'objet.
Il n'est pas tout a fait vrai que le navigateur ne contient pas de compilateur.
en fait les compilateurs modernes utilise des chose comme llvm. il passe par un AST pour séparer l'analyse syntaxique de l'analyse sémantique
la première construit l'AST la seconde le parcours pour produire le code final.
C'est cette dernière partie qui est embarquée.

A+JYT
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 14/03/2017 à 19:03
Citation Envoyé par sekaijin Voir le message
non ce n'est pas du bytecode.

le bytecode est un code pour un processeur imaginaire qui aurait un nombre illimité de registre.
On est quand même très proche de ça : WASM définit un format binaire à destination d'une stack machine:
https://docs.google.com/document/d/1...uCZw7biII/edit

et c'est seulement sa représentation textuelle - qui par convention est en S‑expression (lisp like) - qui peut être qualifiée d'AST. Mais cette représentation textuelle n'est pas WASM (qui est binaire), et elle ne peut pas être comparée à l'AST de Clang :

Citation Envoyé par sekaijin Voir le message
Voici un exemple d'AST généré par Clang
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ cat test.cc
$ clang -Xclang -ast-dump -fsyntax-only test.cc
TranslationUnitDecl 0x5aea0d0 <<invalid sloc>>
... cutting out internal declarations of clang ...
`-FunctionDecl 0x5aeab50 <test.cc:1:1, line:4:1> f 'int (int)'
  |-ParmVarDecl 0x5aeaa90 <line:1:7, col:11> x 'int'
  `-CompoundStmt 0x5aead88 <col:14, line:4:1>
    |-DeclStmt 0x5aead10 <line:2:3, col:24>
    | `-VarDecl 0x5aeac10 <col:3, col:23> result 'int'
    |   `-ParenExpr 0x5aeacf0 <col:16, col:23> 'int'
    |     `-BinaryOperator 0x5aeacc8 <col:17, col:21> 'int' '/'
    |       |-ImplicitCastExpr 0x5aeacb0 <col:17> 'int' <LValueToRValue>
    |       | `-DeclRefExpr 0x5aeac68 <col:17> 'int' lvalue ParmVar 0x5aeaa90 'x' 'int'
    |       `-IntegerLiteral 0x5aeac90 <col:21> 'int' 42
    `-ReturnStmt 0x5aead68 <line:3:3, col:10>
      `-ImplicitCastExpr 0x5aead50 <col:10> 'int' <LValueToRValue>
        `-DeclRefExpr 0x5aead28 <col:10> 'int' lvalue Var 0x5aeac10 'result' 'int'
Ceci n'a rien à voir avec un code de type bytecode.
Je précise pour les lecteurs qu'il s'agit là de l'AST de LLVM et pas de WASM. Et pour l'annecdote, cet AST :
- il n'est pas abstrait (A) mais concret
- il n'est pas syntactique (S) mais sémantique
- ce n'est pas un arbre (T) mais un graphe



Voici un exemple "d'AST" de WASM:

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
(module
 (func $add
  (param $x i32)
  (param $y i32)
  (result i32)
  (i32.add 
   (get_local $x)
   (get_local $y)
  )
 )
 (export "add" $add)
)
http://ast.run/

Tu peux voir qu'on est beaucoup plus proche d'un langage machine abstrait de type bytecode, CIL (.Net), ou IR de LLVM... Non?

Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 15/03/2017 à 8:04
Citation Envoyé par sekaijin Voir le message
non ce n'est pas du bytecode

le bytecode est un code pour un processeur imaginaire qui aurait un nombre illimité de registre.

WASM est un arbre syntaxique
Je pense que le terme AST n'est pas vraiment bon, même si c'est celui qui est utilisé dans les documents de travail que j'avais regardé. En effet, quand on parle d'AST on s'attend a un arbre qui représente la syntaxe du langage d'origine, ce qui n'est pas le cas de WASM. Pour moi c'est plus un bytecode dans le sens ou il est une représentation intermédiaire indépendante du langage d'origine.

Pour moi, le terme le plus juste serait bytecode arborescent, alors que Java ou LLVM-IR seraient des bytecodes séquentiels.
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 15/03/2017 à 13:12
Citation Envoyé par Uther Voir le message
Pour moi, le terme le plus juste serait bytecode arborescent, alors que Java ou LLVM-IR seraient des bytecodes séquentiels.
Qu'entends-tu par bytecode sequentiel?

Ce sont des sujets pointus que je ne maîtrise pas, mais j'ai trouvé une différente entre WASM et ce qui se fait dans la plupart des autres langages : WASM n'est pas compatible avec la forme SSA.

Je ne sais pas bien ce que cela implique, j'aurais plutôt pensé que ça éloignait au contraire d'un design arborescent?!

Bref, je me demande... d'où vient cette histoire d'AST avec WASM?
Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 15/03/2017 à 15:37
Oui c'est toujours la difficulté de simplifier de trop pour vulgariser.

le bytecode java est une suite d'instructions pour un processeur abstrait
chose que n'est pas WASM même dans sa forme binaire.
Il se situe un cran avant la production d'une séquence d'instructions. cette dernière étant faite par le navigateur.

Difficile de causer de tels concepts tout en utilisant un langage commun.
A+JYT
Avatar de RyzenOC RyzenOC - Membre émérite https://www.developpez.com
le 15/03/2017 à 20:16
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

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é
Pardonnez mon ignorance mais c'est quoi l’intérêt de faire tourner gimp dans un navigateur ? sa apporte quoi de plus qu'un client lourd ?
Je développe que des clients lourd pour ma part, il existe pleins de solution simple pour pallier aux problèmes du développement multi-plateforme, du déploiement et des mise à jours (c'est souvent les remarques que j'entends de ceux qui développe du web)

Le dernier programme que j'ai développé (en python et QT) se mets à jour en utilisant un système de maj delta (il ne télécharge que les modifications entre le version du client et la dernière du serveur) et applique les mises à jour sans redémarrer le programme, donc sans killer et redémarrer les processus de mon soft.

L'avantage du client lourd par contre il est évident, c'est fonctionnel ! pas besoin de tester son programme à chaque maj des navigateurs.
Niveau performance, je sais pas si faire tourner des programmes comme gimp dans un navigateur se soit une bonne idée, ces programmes sont censé tirer partie au mieux du matos qu'il dispose et par conséquent sa nécessite des optimisations très fines de la part des dev, je ne sais pas mais je ne pense pas que webassembly soit aussi fin que des langages comme C/C++ ?

sans même parler des perf, il y'a la latence du au réseau, utiliser google doc pour moi est un "enfer" par exemple, c'est pas fluide sa n'a rien à voir avec libre office/ms office d'installer sur mon pc.

Quand aux jeux vidéos dans le navigateur, pour remplacer les jeux flash oui mais il me semble techniquement aujourd'hui impossible d'arriver à faire un open world à la witcher 3 dans un navigateur en webGL, à un moment donné faut être réaliste.
Vous pouvez voir le jeu Bananabread, c'est du même style que Quake3 (la version d'origine et la version web), c'est une régression de 20ans techniquement, on est loin d'un Arma3 Apex.
Avatar de pol2095 pol2095 - Membre du Club https://www.developpez.com
le 16/03/2017 à 8:32
C'est peut-être un moyen d'inverser la tendance, parce qu'aujourd'hui internet, c'est 80% pour les apps et 20% pour le navigateur. Le navigateur est en perdition.
Je pense que c'est surtout conçu pour développer des jeux, mais ce qui manque avant tout au navigateur, c'est un SDK.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 16/03/2017 à 8:47
Citation Envoyé par RyzenOC Voir le message
Pardonnez mon ignorance mais c'est quoi l’intérêt de faire tourner gimp dans un navigateur ? sa apporte quoi de plus qu'un client lourd ?
L’intérêt c'est que les utilisateurs occasionnels peuvent l'utiliser directement sans installation définitive. Pour un usage régulier en effet une bonne application lourde semble préférable.
Avatar de RyzenOC RyzenOC - Membre émérite https://www.developpez.com
le 16/03/2017 à 8:53
Citation Envoyé par Uther Voir le message
L’intérêt c'est que les utilisateurs occasionnels peuvent l'utiliser directement sans installation définitive. Pour un usage régulier en effet une bonne application lourde semble préférable.
ok merci, on est donc bien sur la même longueur d'onde.
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 16/03/2017 à 23:51
J'ai creusé un peu plus le sujet et réussi à clarifier (un peu) cette histoire d'AST

WASM peut être vu comme une forme particulière de bytecode (de haut niveau) qui se distingue de Java/.Net par son support du modèle mémoire de C/C++. WASM dispose donc de son jeu d'instructions "virtuel" (Instruction Set Architecture) qui se distingue de LLVM par sa portabilité, sa faible taille et sa rapidité à être compilé. Cela trahit les priorités de WASM : poids faible des binaires pour un téléchargement rapide, rapidité de lancement dans le navigateur. A l'inverse LLVM a pour priorité de permettre des optimizations poussées du code par les backends. WASM s'en remet à ce dernier pour effectuer les coûteuses opérations d'optimisation et ne pas avoir à le faire lui-même.

N'ayant pas cette dernière contrainte, WASM peut se permettre de ne pas descendre au niveau du graphe de contrôle (CFG) / bytecode SSA comme les compilateurs mais rester au niveau de l'arbre syntaxique (AST) afin d'avoir une représentation plus compacte et permettre sa conversion en asm.js.

A noter que l'expérimentation PNaCl de Google a cherché à adapter le bytecode de LLVM pour satisfaire ces mêmes contraintes (le bytecode généré est livré et doit donc rester stable dans le temps là où le langage intermédiaire de LLVM est temporaire à la compilation et peut changer d'une version à l'autre). Mais les auteurs de WASM ont jugé qu'il était préférable de partir d'une page vierge plutôt que de chercher à adapter un système ayant d'autres objectifs.

https://github.com/bnjbvr/webassembl...r/Rationale.md
https://github.com/WebAssembly/desig...-binary-format

Citation Envoyé par RyzenOC Voir le message
Pardonnez mon ignorance mais c'est quoi l’intérêt de faire tourner gimp dans un navigateur ? sa apporte quoi de plus qu'un client lourd ?
On peut aussi le voir à l'envers : pouvoir alourdir les applications web plutôt que de "webiser" les clients lourds

En plus des avantages donnés par Uther, il y a aussi :
- la portabilité : au hasard, supporter les multiples distributions Linux ça consomme beaucoup de temps. Là tu cibles une seule plateforme et c'est réglé (du moins c'est la promesse)
- contrôle des licences : c'est beaucoup plus facile de t'assurer que tes utilisateurs n'ont pas une version crackée de ton soft !
- itinérance : l'utilisateur met ses données dans le cloud ($$$) et peut basculer d'un ordi à l'autre facilement

Après le client lourd natif risque de garder encore longtemps son avantage dès qu'il y a des traitements algorithmiques lourds. Au hasard, un logiciel de montage vidéo...

Arriver à tourner à 150% des performances d'un code natif de base, c'est super. Mais un code natif optimisé peut tourner 3, 4, 10 fois plus vite que sa version de base, sans parler de la consommation mémoire et encore moins du multicoeur car WASM ne supporte pas le multi-threading (pour l'instant) !
Avatar de micka132 micka132 - Membre émérite https://www.developpez.com
le 17/03/2017 à 14:49
Citation Envoyé par Aurelien.Regat-Barrel Voir le message
On peut aussi le voir à l'envers : pouvoir alourdir les applications web plutôt que de "webiser" les clients lourds
Oui je pense que c'est ce qu'il faut y voir et pas vouloir remplacer ce qui se fait aujourd'hui en client lourd.
Par exemple les démos graphiques sont pour moi totalement stupides, on s'extasie devant des trucs qui se faisait il y a 10 ans sur du client lourd. Sans parler que les jeux aujourd'hui c'est les dizaines de Go des ressources qui sont longues à télécharger, franchement le joueur n'y gagnera rien à jouer sur le navigateur.
Citation Envoyé par Aurelien.Regat-Barrel Voir le message
En plus des avantages donnés par Uther, il y a aussi :
- la portabilité : au hasard, supporter les multiples distributions Linux ça consomme beaucoup de temps. Là tu cibles une seule plateforme et c'est réglé (du moins c'est la promesse)
- contrôle des licences : c'est beaucoup plus facile de t'assurer que tes utilisateurs n'ont pas une version crackée de ton soft !
- itinérance : l'utilisateur met ses données dans le cloud ($$$) et peut basculer d'un ordi à l'autre facilement
Là par contre je suis pas vraiment d'accord. La portabilité j'y crois pas, il n'y a qu'a voir sur des pages web relativement simple il arrive souvent qu'il y ait des incompatibilités, alors sur du complexe je ne vois pas par quel miracle les problemes ne vont pas se mutliplier.
-Le controle des licences je ne vois pas ce que ca change? Le control ne peut se faire que si c'est le serveur qui possede l'intelligence, si c'est le client qui travail quelque soit la technologie ca sera toujours crackable.
-Pour les données je ne comprends pas où est la difference avec un client lourd? C'est comme si tu confondais client lourd et déconnexion. Un client lourd il peut aller autant sur internet qu'un navigateur, si ce n'est encore plus parceque non limité par http!
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 17/03/2017 à 21:22
Citation Envoyé par micka132 Voir le message
Là par contre je suis pas vraiment d'accord. La portabilité j'y crois pas, il n'y a qu'a voir sur des pages web relativement simple il arrive souvent qu'il y ait des incompatibilités, alors sur du complexe je ne vois pas par quel miracle les problemes ne vont pas se mutliplier.
Parce que - de ce que j'en ai compris - c'est du rendu OpenGL, pas du DOM/HTML/CSS. Exemple d'application C++/Qt qui tourne dans le navigateur (grâce à Emscripten) :
http://vps2.etotheipiplusone.com:301...es/tetrix.html

On est d'accord que y'aura des problèmes d'incompatibilités entres navigateurs. Mais malgré tout, je pense qu'assurer la portabilité de cette façon est (beaucoup) moins coûteux que pour une application native portée sur plusieurs (déclinaisons d') OS. Et au pire des cas, si ça ne marche que sur Chrome par exemple, bon ben voilà, les principaux OS sont tous supportés moyennant l'utilisation de Chrome.

Citation Envoyé par micka132 Voir le message
-Le controle des licences je ne vois pas ce que ca change? Le control ne peut se faire que si c'est le serveur qui possede l'intelligence, si c'est le client qui travail quelque soit la technologie ca sera toujours crackable.
-Pour les données je ne comprends pas où est la difference avec un client lourd? C'est comme si tu confondais client lourd et déconnexion. Un client lourd il peut aller autant sur internet qu'un navigateur, si ce n'est encore plus parceque non limité par http!
C'est vrai. Dans mon esprit ce genre de techno (WASM) est une techno hybride - dans le sens de non destinée à être utilisée de façon isolée - qui sert à déporter (soulager) une partie de l'intelligence du serveur vers le client là où le client lourd va plutôt chercher à faire l'inverse. Donc pour moi avec WASM on a un modèle intrinsèquement connecté au Cloud (c'est un serveur web qui délivre l'application) là où pour le client lourd c'est quelque chose de plus qu'il faut mettre en place (et c'est assez complexe d'ailleurs).

Je n'avais pas imaginé qu'une application WASM puisse être lancée de manière locale comme une appli classique qu'on aurait préalablement téléchargé. Et je ne sais pas trop quoi penser de ce fonctionnement là !
Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 18/03/2017 à 10:06
Nous avons eu tout un tas de tentatives pour faire des applications desktop à partir des technos web app
Et effectivement WASM ouvre une voie dans ce sens.

Mais pour le moment le but c'est le navigateur.

Il est un point qui est important dans cette affaire c'est que WASM dans le Navigateur prévoit l'interaction entre WASM et JS.
Ce faisant nombre de fonctions que font tous les frameworks JS peuvent être mises à disposition sous la forme d'un Modules WASM.

Si on prend des librairies JS qui fournissent des widgets complexes un des problèmes est que cela est lourd et coûteux en code JS. non pas de coder avec mais de les avoir à dispo.
La même API JS ou presque en WASM sera plus compacte, plus efficace, plus rapide.
Cela permettra de bénéficier de toute la puissance de WASM dans les applications JS telles que nous les développons aujourd'hui.

Je ne veux pas dire par là qu'il faut reproduire les Lib JS que nous connaissons à l'identique. Mais qu’il faut repenser des frameworks JS en WASM pour qu'un site Web puisse en utiliser les fonctionnalités!

Pour moi il ne faut pas voir WASM comme un remplaçant de quoi que ce soit. il faut le voir comme un outils complémentaire à d'autres solutions.
il ne remplacera pas les compilateurs natifs, il ne remplacera pas la JVM ou .NET il ne remplacera pas JS
S'il réussit (est adopté) il se fera une petite place quelque part entre tout ça. Débordant sur le périmètre de certaines de ces technologies sans prendre toutes la placent. Se faisant il va nous forcer à revoir certains choix, non parce qu'il remplace mais parce qu'il apporte une autre perspective sur le sujet.
Comme chaque fois qu'une nouvelle technologie arrive on va découvrir d'autres façons d'appréhender les problèmes.

A+JYT
PS Il ne faut pas oublier les plug-ins qui sont des cibles potentielles.
Avatar de pol2095 pol2095 - Membre du Club https://www.developpez.com
le 18/03/2017 à 17:54
j'ai testé la démo sur mon ultrabook, ça saccade par rapport à la vidéo, avec en plus un beau plantage de Firefox. Sur mobile, il ne faut même pas y penser pour le moment.
De plus le temps de chargement...
Avatar de marsupial marsupial - Membre éprouvé https://www.developpez.com
le 18/03/2017 à 21:07
Citation Envoyé par Aurelien.Regat-Barrel Voir le message
Je n'avais pas imaginé qu'une application WASM puisse être lancée de manière locale comme une appli classique qu'on aurait préalablement téléchargé. Et je ne sais pas trop quoi penser de ce fonctionnement là !
Je vais sans doute dire une énormité.

Imaginons une application utilisant de l'IA. A l'heure actuelle, cette appli va demander du HPC et donc une station qui ne servira "que" de client pour traiter cette partie. Ou toute autre partie gourmande en puissance de calcul.
Avec du WASM, nous aurons l'avantage de ne disposer que de la partie UI sur le client à travers le navigateur transmettant uniquement les informations de l'utilisateur et tout le traitement lourd se fera en déporté dans le cloud en s'affranchissant d'énormément de contraintes techniques liées aux technologies. Et miracle, WASM peut être implémenté avec C# simplifiant la tâche du concepteur au développeur.

Pour la partie exécution en locale, avec l'hétérogénéité des plateformes, utiliser le navigateur comme environnement final d'exécution devient une solution ébauchée avec asm.js, et à mon sens bon nombres d'applis demandant d'être codées pour iOS, Android, Windows, Linux vont être simplifiées dans leur conception grâce à WASM. Reste à voir en production l'optimisation dépendante du navigateur d'un client de messagerie par exemple. J'espère que le W3C continuera à maintenir sa main mise sur le standard afin que cela ne parte pas dans tous les sens sinon la technologie perdrait son principal avantage : la portabilité alliée à des perfs respectables et suffisantes pour la satisfaction de l'utilisateur. Et dans un monde progressant vers le cloud, la 5G arrivant à grands pas, l'IA prenant de plus en plus place, je pense qu'il faut réfléchir mobilité donc hétérogénéité et de moins en moins poste de travail-clavier-souris.

Evidemment, CATIA sur smartphone ou hybride, ce n'est pas demain la veille
Offres d'emploi IT
Architecte électronique de puissance expérimenté H/F
Safran - Ile de France - Villaroche - Réau
Expert décisionnel business intelligence H/F
Safran - Ile de France - Évry (91090)
Ingénieur conception en électronique de puissance H/F
Safran - Ile de France - Moissy-Cramayel (77550)

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