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 !

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

Le , par Michael Guilloux

314PARTAGES

9  0 
Google, Microsoft et Mozilla proposent une démonstration fonctionnelle de WebAssembly dans leurs navigateurs,
le projet ambitionne de devenir le code binaire du web

Mise à jour du 02 / 11 / 2016 : WebAssembly a atteint le milestone Browser Preview

Google, Mozilla et Microsoft ont annoncé la disponibilité d’une WebAssembly Browser Preview. Cette étape marque 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 ++ ;

La WebAssembly Community Group l’intention d’annoncer des spécifications officielles au premier trimestre de 2017 et les éditeurs de navigateurs seront alors encouragés à rendre WebAssembly disponible par défaut. Une feuille de route est d’ailleurs disponible

Source : blog Google, feuille de route WebAssembly

Apple, Google, Microsoft et Mozilla ont rendu disponible une préversion du support du projet WebAssembly sur leurs navigateurs web respectifs qui ambitionne de devenir le code binaire du web. Soutenu par le W3C, ce projet ambitionne de simuler un processeur virtuel, capable d’exécuter des programmes à une vitesse proche du code natif. Il faut préciser qu’il ne part pas de zéro, puisqu’il reprend les principes d’asm.js, une technologie qui sert à booster la capacité de traitement des applications web.

Dans une démo AngryBots,une adaptation d’un jeu Unity,les éditeurs ont apporté les premières démonstrations fonctionnelles.

« Je suis heureux de vous annoncer que WebAssembly a atteint une étape importante : il y a désormais de multiples implémentations expérimentales dans les navigateurs, toutes sont interopérables », s’est félicité Luke Wagner, un ingénieur travaillant pour le compte de Mozilla. « Nous avons encore beaucoup de travail à faire sur l’implémentation de ce standard avant qu’il ne soit livré, mais nous avons là une bonne occasion de présenter l’étendue de nos progrès, parler de ce qui arrive par la suite et attendre les retours », a-t-il poursuivi.

Chez Microsoft, c’est Limin Zhu, le responsable programme Chakra, qui s’est exprimé. Après avoir présenté une démo d’AngryBots sur le navigateur Edge qui se sert du support préliminaire de WebAssembly dans le moteur Chakra, il a avancé « qu’en dépit de leur statut précoce, la démo démarre beaucoup plus rapidement qu’en utilisant uniquement asm.js, puisque les binaires WebAssembly ont une taille de fichier réduite et sont parsés plus rapidement que du JavaScript ordinaire ».


« Avec ChakraCore qui est désormais open source, nous avons développé notre implémentation de WebAssembly entièrement en open source dans la branche WebAssembly de notre dépôt ChakraCore », a noté Zhu. « Sous le capot, notre implémentation est en mesure de réutiliser la plupart des infrastructures existantes d’asm.js. Le code WebAssembly va dans les mêmes pipelines que le code asm.js après avoir été parsé », a-t-il continué.

Du côté de chez Google, l’entreprise apporte un support expérimental à WebAssembly sur son moteur KavaScript V8. Seth Thomson, le responsable du côté de Google, a fait comprendre que « sous le capot, la prise en charge de WebAssembly dans V8 a été pensée pour réutiliser au plus l’infrastructure de la machine virtuelle JavaScript existante, en particulier le compilateur TurboFan ». « Un décodeur WebAssembly spécialisé valide les modules en vérifiant les types, les indices de variables locales, les références de fonctions, les valeurs de retour et la structure du contrôle de flux en une seule passe », a-t-il continué.

« En tant qu’évolution des technologies existantes, WebAssembly est profondément intégré à la plateforme web, permettant d’accélérer aussi bien les téléchargements sur le réseau et les instances qu’asm.js, un sous-ensemble de bas niveau de JavaScript ».

« L’équipe V8/WebAssembly espère continuer sa collaboration avec les autres éditeurs de navigateurs ainsi que la grande communauté tandis que nous travaillons sur la publication d’un environnement d’exécution stable », a indiqué Thomson.

« Nous prévoyons également plusieurs fonctionnalités pour le futur (notamment le multithreading, le dynamic linking et une intégration au DOM et au ramasse-miettes) et de continuer le développement des toolchains pour la compilation C, C++ et d’autres langages, via le backend WebAssembly LLVM et Emscripten ».

Mozilla, pour sa part, a l’intention d’ajouter le support de WebAssembly dans les outils développeurs de Firefox, parmi lesquels le débogueur et le profileur, et envisage de travailler également sur une réduction du temps de chargement à froid et préparer un lot complet d’opérateurs. Luke Wagner, qui travaille également au W3C, indique que ce dernier suit le développement de près en vue de standardiser l’ensemble.

Source : blog Windows, V8 Project, Hacks Mozilla

Voir aussi :

Microsoft Edge trois fois plus rapide que IE 11 grâce à Asm.js le navigateur offrira plus de sécurité

Windows 10 : Microsoft intégrera à Chakra le support d'Asm.js, le module de Mozilla permettant à JavaScript d'avoir des performances proches du natif

asm.js s'approche des performances du code natif C/C++, Mozilla optimise son sous-ensemble de JavaScript
Vous avez lu gratuitement 4 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

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

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 RyzenOC
Inactif https://www.developpez.com
Le 15/11/2017 à 16:38
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

10ans plus tard ces technos sont considéré comme un cancer tres dangereuse pour les machines.
20ans plus tard on est enfin presque arrivé à s'en débarrasser (les activeX sont encore utilisé en Corée du sud)

2012 HTML5 : technologie du futur il pourra tous faire et sera en plus multiplate-forme et intégré de base dans le navigateur sans pouvoir le désactiver.
=> 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
entre temps on le fait évoluer, HTML5 prend le contrôle de la caméra, du micro, des devices USB, peut créer des fichiers dans le disque dur....
les pub flash qui bouffait 100% du cpu pentium4 monocœur ont été remplacé par du minage de bitcoin en js qui bouffe 100% du cpu et en plus c'est multicœurs

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

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 poruquoi il en serait autrement avec webassembly.
1  0 
Avatar de Watilin
Expert éminent https://www.developpez.com
Le 15/11/2017 à 19:17
Ça c’est la vision pessimiste.

Les anglophones ont ce mot, hindsight, qu’on peut traduire plus ou moins adroitement en sagesse rétrospective et qui désigne le fait qu’on apprend de nos erreurs et qu’on produit quelque chose de meilleur à chaque itération.

Certes, on n’arrêtera jamais de faire des erreurs, mais l’écosystème du Web produit des choses moins maladroites, plus efficaces, plus sûres qu’il y a dix ou vingt ans. Aujourd’hui, les navigateurs demandent l’autorisation à l’utilisateur·trice avant d’exécuter un ActiveX ou un plugin. Les requêtes médias et autres APIs (caméra, micro, géolocalisation, etc.) ont été conçues dès le départ sur ce principe d’autorisation.

Aujourd’hui les choses sont mieux cloisonnées et il est plus facile d’ajouter des sécurités quand le besoin se fait sentir. Exemple avec la récente décision de Firefox de limiter la méthode toDataURL des canevas, la soumettant à l’autorisation de l’utilisateur·trice, pour prévenir le fingerprinting.

Le problème du minage de bitcoin est un cas pathologique, on pourrait s’en servir pour accuser n’importe quelle techno. Il y aura toujours des failles, et des pirates pour exploiter ces failles.

Tes craintes sur les failles de C[++] sont infondées car il est clairement écrit que le WASM est exécuté dans une sandbox sécurisée. Encore une fois, hindsight. Tu sais, je suppose, qu’on peut écrire du code C[++] sécurisé en respectant les bonnes pratiques établies. Considère que le modèle de sécurité des navigateurs oblige à respecter ces bonnes pratiques.

Tu le dis très bien, aucune techno n’est inviolable, mais est-ce une raison pour fustiger toute tentative de progrès ?
1  0 
Avatar de clorr
Membre averti https://www.developpez.com
Le 15/11/2017 à 16:19
D'un cote, c'est la mort lente du client léger qui est à l'origine du web...
De l'autre cote, ca ouvre la porte du navigateur à d'autres langages, et du coup, ça signe peut etre une periode où on pourra réduire la fragmentation de nos stacks entre back et front autrement qu'en faisant du js cote serveur...
0  0 
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 15/11/2017 à 19:33
Citation Envoyé par Watilin Voir le message

Tu le dis très bien, aucune techno n’est inviolable, mais est-ce une raison pour fustiger toute tentative de progrès ?
évidemment que non, n'aimant pas le JS c'est d’ailleurs une bonne nouvelle pour moi d'avoir autre chose (je fais pas de web donc je fais partie des plus concernée par ce probleme).

Considère que le modèle de sécurité des navigateurs oblige à respecter ces bonnes pratiques.
d'un autre coté de ce que j'ai vue de cette techno, sa sera juste du code ayant les mêmes fonctionnalités que JS mais il sera "pre-compiler" pour que celui-ci soit directement interprété.
Il ne s'agit donc pas d'étendre les possibilités mais juste d'optimiser le poids et le temps d'exécution en codant en C/C++ au lieu du JS. C/C++ (ou n'importe quels autre langages au passage comme du Go, du python ou du... js )

Tes craintes sur les failles de C[++] sont infondées car il est clairement écrit que le WASM est exécuté dans une sandbox sécurisée.
Oui, les implémentations seront vraisemblablement bound checked.
0  0 
Avatar de matthius
Inactif https://www.developpez.com
Le 07/12/2019 à 10:08
Il faudra vérifier chaque lien et surtout le code source du processeur déclenché derrière. Je préfère me passer d'Intel pour avoir du Atom dans ce cas là.

Ça m'a affolé qu'on puisse exécuter du Javascript avec un navigateur. Peu d'informaticiens arrivent à déchiffrer l'asm.

Qu'est-ce que implémentations de langage portables ?
0  12