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, Chroniqueur Actualités
WebAssembly, ou wasm, est un nouveau type de code qui peut être exécuté dans un navigateur web moderne. C'est un langage bas niveau semblable à l'assembleur, permettant d'atteindre des performances proches des applications natives (par exemple écrites en C/C++) tout en fonctionnant sur le Web. WebAssembly est conçu pour fonctionner en lien avec JavaScript et, en passe de devenir une norme dans l'industrie, il donne aux développeurs web un certain nombre d'options qu'ils n'avaient pas auparavant. Il leur permet par exemple de :

  • profiter du format compact wasm pour transmettre des fichiers rapidement sur le réseau et les charger en tant que modules JavaScript ;
  • obtenir des performances quasi natives sans utiliser de plug-in ;
  • écrire un code à la fois performant et sécurisé, car il s'exécute dans le sandbox de sécurité du navigateur ;
  • avoir un choix de langages en dehors de JavaScript. Il permet par exemple aux développeurs d'écrire du code en C ou C++, puis de compiler directement en wasm, sans devoir compiler le code en JavaScript d'abord. En dehors de C/C++, des langages supplémentaires seront supportés à l'avenir.

Avec les avantages qu’il présente, il n’a fallu que deux ans à tous les principaux fournisseurs de navigateurs pour prendre en charge le nouveau standard. Hier, dans un billet de blog, Mozilla a en effet annoncé que le support WebAssembly est désormais disponible dans tous les principaux navigateurs. Au cours des dernières semaines, Apple et Microsoft ont fourni de nouvelles versions de Safari et Edge, avec le support de WebAssembly. Étant donné que Mozilla Firefox et Google Chrome prenaient déjà en charge WebAssembly, cela veut dire que les quatre principaux navigateurs sont désormais capables de générer du code compilé dans le format wasm sur le Web.

« Google, Apple et Microsoft s'étaient tous engagés à prendre en charge WebAssembly dans leurs navigateurs. Avoir ce support sur le marché aujourd'hui est un développement vraiment passionnant », a déclaré Luke Wagner, l'ingénieur de Mozilla qui a créé le précurseur de WebAssembly, asm.js, et qui a dirigé le travail sur la spécification WebAssembly.

Pour les développeurs, la prise en charge du nouveau standard par les principaux navigateurs signifie qu'ils peuvent tirer parti de WebAssembly avec l'assurance que la plupart des utilisateurs seront en mesure d'exécuter des modules wasm par défaut.

WebAssembly apporte des performances sur le Web qu'il est extrêmement difficile d'atteindre avec JavaScript seul, notamment pour l'industrie du jeu. « Asm.js et WebAssembly étaient sans l'ombre d'un doute pour les entreprises de l'industrie du jeu, car elles avaient d'énormes investissements dans des programmes en C ++ qu'elles ne voulaient pas réécrire pour le Web », a déclaré Wagner. Raison pour laquelle cette industrie a été la première à adopter WebAssembly et asm.js. D’après l’ingénieur de Mozilla, Epic et Unity ont devancé les autres en étant les premiers à mettre en ligne leurs moteurs de jeu à l'échelle industrielle sans réécrire les bases de code C++ en JavaScript.

Mais aujourd'hui, les cas d'utilisation de WebAssembly et asm.js se sont développés au-delà des jeux en ligne. À mesure que les utilisateurs expérimentent le processus d'utilisation du format WebAssembly, et du compilateur Emscripten, ils trouvent des moyens de transférer des applications de plus en plus sophistiquées vers le Web. D'après Luke Wagner, les applications portées sur le Web grâce à WebAssembly couvrent divers domaines, y compris la vision par ordinateur, la cartographie 3D, le traitement des signaux numériques, l'imagerie médicale, la simulation physique, le chiffrement, la compression, etc. « Nous voyons maintenant des gens utiliser WebAssembly pour toutes sortes de nouveaux projets », dit-il. Pour lui, cela promet que nous serons un jour capables de faire tourner n'importe quelle application sur le Web et de la faire fonctionner comme si elle fonctionnait localement sur un PC.

Source : Blog Mozilla

Et vous ?

Qu’en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de clorr clorr - Nouveau membre du Club 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...
Avatar de RyzenOC 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.
Avatar de Watilin Watilin - Expert confirmé 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 ?
Avatar de RyzenOC 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.
Avatar de Uther Uther - Expert éminent 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.
Contacter le responsable de la rubrique Accueil