IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les premiers projets publics de travail de WebAssembly sont disponibles
Et portent sur la norme de base, l'interface JavaScript et l'API Web

Le , par Stéphane le calme

150PARTAGES

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

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

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

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

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

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

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

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


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

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


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

Source : introduction à WebAssembly (Mozilla Hack)

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

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

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

Source : W3C

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Uther
Expert éminent sénior 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.
4  0 
Avatar de Uther
Expert éminent sénior 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.
3  0 
Avatar de RyzenOC
Inactif 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.
3  0 
Avatar de pol2095
Membre habitué 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.
7  5 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior 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?

3  1 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior 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) !
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 15/11/2017 à 21:51
Citation Envoyé par RyzenOC Voir le message
j'ai le sentiment que cela vas finir comme cela ces finis avec les activeX et les applets Java.
ActivX 1995 : Technologie du futur vous aller pouvoir exécuter du C++ dans le navigateur, c'est finit le client lourd

Applet Java 1995 : Technologie du futur vous aller pouvoir exécuter du java dans le navigateur, c'est finit le client lourd
Falsh player 1996 : Technologie du futur vous aller pouvoir faire de la 3D dans le navigateur, c'est finit le client lourd
La situation est quand même très différente.
  • Pour Active X le soucis était que c'était une technologie intrinsèquement non portable car totalement centrée sur Windows et dangereuse niveau sécurité. Elle brisait allègrement la frontière entre ce qui est la charge de l'OS et du navigateur.
  • Pour Java, Flash ou (p)NaCl, le soucis et que c'était des technologies qui arrivaient comme une rustine par dessus les spécification du web.et les navigateurs n'avaient aucune maîtrise dessus. Elles étaient sous le contrôle d'une seule société. Enfin leurs API étaient généralement en doublon de celles de HTML et s'intégraient plus ou moins mal avec.

La principale différence de Wasm avec les technologies précédentes, c'est qu'il aura accès exactement aux mêmes API que le JavaScript, pas plus. Ce qui fait qu'il aura, entre autre une surface d'attaque bien plus faible. Il le fera juste de manière plus performante vu que ce bytecode ne sera pas limité par les spécificités d'un langage de haut niveau.

Citation Envoyé par RyzenOC Voir le message
toutes les 3 semaines les browsers reçoivent des maj de sécurité de la meme manciere qu'avant on faisait les maj de adobe flash player et java
Pour info les navigateurs majeurs reçoivent déjà des mises a jour de sécurité planifiées toutes les 4 semaines (IE, Edge) ou six semaines (Chrome,Firefox), voire moins en cas de faille dangereuse exploitable. Donc wasm ne devrait pas changer pas grand chose au problème.

Citation Envoyé par RyzenOC Voir le message
mais le js c'est pas assez puissant, on vas créer webassembly, du code C/C++ compilé exécuté dans le navigateur, j’émets de grosse crainte quand on sait que le C est le langage le plus sujet aux failles de sécurité liée à la mémoire (ce qui est logique), Corruption mémoire, Kernel Stack/Heap...
Sauf que l'on ne va pas compiler directement le C sur le client et l'executer comme si c'était n'importe quelle application. On passe par l'intermédiaire d'un bytecode qui offre des garanties de sécurité(accès mémoire contrôlé) et bien sur il sera exécuté dans une sandbox avec des accès réduits.

Citation Envoyé par RyzenOC Voir le message
ne me dites pas que ces technos sont safe et qu'elles ont été conçue des le départ pour être inviolable, soyons sérieux il y'a déjà eu des virus qui se sont installé via du code JS, je vois pas pourquoi il en serait autrement avec webassembly.
Le risque zéro n'existe pas, mais ces technologies ont en effet été conçues pour être aussi "safe" que possible à défaut d'être inviolable. Cette technologie n'est ni plus ni moins sure que le JavaScript qui est déjà présent partout dans les navigateurs.
2  0 
Avatar de Zefling
Expert confirmé https://www.developpez.com
Le 08/12/2019 à 9:47
Citation Envoyé par matthius Voir le message
Ça m'a affolé qu'on puisse exécuter du Javascript avec un navigateur. Peu d'informaticiens arrivent à déchiffrer l'asm.
Moi ça m'affole pas plus que ça. J'étais plus affolé par ActiveX où l'on pouvait faire des actions hors du navigateur. JS et Wasm sont cloisonnés à une page de navigateur. Puis aujourd'hui faire un site sans ça c'est compliqué ou fait tout faire à l'ancienne.

Et je te mets au défit de déchirer ce code JS : https://js1k.com/2019-x/details/4130
Pas besoin de faire de l'asm pour rendre un code illisible.
2  0 
Avatar de Tartare2240
Membre averti 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.
2  1 
Avatar de micka132
Expert confirmé 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...
2  1