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 !

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

157PARTAGES

10  0 
É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

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

Avatar de 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
8  0 
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 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.
2  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