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 premières ébauches publiques du travail sur WebAssembly 2.0 ont été publiées
Les objectifs de conception incluent une sémantique rapide, sûre et portable

Le , par Stéphane le calme

75PARTAGES

13  0 
Pris en charge dans les principaux navigateurs, WebAssembly, ou Wasm en abrégé, fournit un format de code sûr, portable et de bas niveau conçu pour une représentation compacte et une exécution efficace. Il promet des applications Web plus rapides et permet l'utilisation d'autres langages que JavaScript pour la programmation Web. La technologie alimente désormais des applications distribuées complexes, ayant dépassé le navigateur et intégré le serveur. La publication d'un projet de travail n'implique pas l'approbation par le W3C ou les membres. Le projet de document peut être mis à jour, remplacé ou rendu obsolète par d'autres documents.

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 vous 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 (ou wasm).


À la base, WebAssembly est une architecture de jeu d'instructions virtuelle qui permet des applications hautes performances sur le Web et peut être utilisée dans de nombreux autres environnements. Il existe plusieurs implémentations de WebAssembly, notamment des navigateurs et des systèmes autonomes. WebAssembly peut être utilisé pour des applications telles que les codecs vidéo et audio, les graphiques et la 3D, le multimédia et les jeux, les calculs cryptographiques ou les implémentations de langage portables. 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.

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 ». Toutefois, comme l’a expliqué l’ingénieur Mozilla Lin Clark, 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 ».

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 au fil des ans. Les développeurs pourront utiliser WebAssembly pour accélérer les applications web existantes.

Parmi les démonstrations fonctionnelles qui ont été apportées, nous pouvons citer celle d'AngryBots, une adaptation d’un jeu Unity. Limin Zhu, le responsable programme Chakra chez Microsoft, avait présenté une démo d’AngryBots sur le navigateur Edge qui se servait alors 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 ».


WebAssembly, ce langage de 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, apporte un certain nombre d'options aux développeurs, entre autres :
  • la possibilité de profiter du format compact wasm pour transmettre des fichiers rapidement sur le réseau et les charger en tant que modules JavaScript ;
  • la possibilité d'obtenir des performances quasi natives sans utiliser de plug-in ;
  • la possibilité d'écrire un code à la fois performant et sécurisé, car il s'exécute dans le sandbox de sécurité du navigateur ;
  • 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 ; depuis 2017, le support de WebAssembly est disponible dans tous les principaux navigateurs notamment Firefox, Chrome, Safari et Microsoft Edge.

Jeudi 5 décembre 2019, le World Wide Web Consortium (W3C) a annoncé que la spécification WebAssembly Core est désormais une norme Web officielle : « après HTML, CSS et JavaScript, WebAssembly devient le quatrième langage pour le Web qui permet au code de s'exécuter dans le navigateur », note le W3C.

« L'arrivée de WebAssembly élargit la gamme d'applications qui peuvent être réalisées en utilisant simplement les technologies Open Web Platform. Dans un monde où l'apprentissage automatique et l'intelligence artificielle deviennent de plus en plus courants, il est important d'apporter des applications hautes performances sur le Web, sans compromettre la sécurité des utilisateurs », a déclaré Philippe Le Hégaret, chef de projet W3C.

L'objectif principal de WebAssembly est de permettre des applications hautes performances sur des pages Web, « mais il ne fait aucune hypothèse spécifique au Web ni ne fournit de fonctionnalités spécifiques au Web, il peut donc également être utilisé dans d'autres environnements ». WebAssembly est une norme ouverte et vise à prendre en charge n'importe quel langage sur n'importe quel système d'exploitation et, dans la pratique, tous les langages les plus populaires ont déjà au moins un certain niveau de prise en charge.

Les implémentations WebAssembly utilisent généralement une compilation en avance sur le temps (AOT) ou juste à temps (JIT), mais peuvent également utiliser un interpréteur. Alors que les premières implémentations ont été déployées dans les navigateurs Web, il existe également des implémentations hors navigateurs à usage général, notamment Wasmer, Wasmtime ou WAMR, wasm3, WAVM et bien d'autres.


Étant donné que les exécutables WebAssembly sont précompilés, il est possible d'utiliser une variété de langages de programmation pour les créer. Ceci est réalisé soit par compilation directe dans Wasm, soit par implémentation des machines virtuelles correspondantes dans Wasm. Il y a eu environ 40 langages de programmation signalés pour prendre en charge Wasm comme cible de compilation.

WebAssembly 2.0

Les premières ébauches publiques du travail sur WebAssembly 2.0 sont arrivées, la prochaine itération prévue du format d'instruction binaire est jusqu'à présent centrée sur des capacités telles que l'interaction JavaScript et l'intégration avec la plateforme Web plus large.

Le groupe de travail WebAssembly du World Wide Web Consortium (W3C) a publié le 19 avril trois projets :
  • WebAssembly Core Specification Version 2.0, décrivant la prochaine version de la norme de base ;
  • WebAssembly JavaScript Interface Version 2.0, fournissant une API JavaScript explicite pour interagir avec WebAssembly ;
  • WebAssembly Web API Verson 2.0, décrivant l'intégration de WebAssembly avec la plateforme Web plus large.

Les trois ébauches suivent le même schéma que pour WebAssembly 1.0, le W3C ayant publié fin 2019 des documents relatifs à la spécification principale, une API Web et une interface JavaScript. La spécification principale de WebAssembly 2.0 fait écho aux objectifs précédents de WebAssembly. Les objectifs de conception incluent une sémantique rapide, sûre et portable et une représentation efficace et portable.

L'API JavaScript fournit un moyen d'accéder à WebAssembly via un pont pour construire explicitement des modules à partir de JavaScript. L'API Web s'appuie sur la spécification WebAssembly et l'intégration JavaScript WebAssembly.

Parmi les propositions pour WebAssembly 2.0 figurent le SIMD à largeur fixe, les opérations de mémoire en bloc, les types de référence, la prise en charge de JavaScript BigInt vers WebAssembly i64, la prise en charge de plusieurs valeurs de retour et l'importation/exportation de variables globales mutables.

WebAssembly a toujours des propositions en cours d'élaboration, ainsi que des indications de branche, des optimisations d'appels de queue, la gestion des exceptions, une fonctionnalité de threads post-MVP, un SIMD assoupli et d'autres propositions provisoires.

Source : W3C

Et vous ?

Que pensez-vous de WebAssembly ?
Vous en êtes-vous déjà servi ? Sinon, étant donné qu'il est devenu une norme, allez-vous envisager de le faire pour vos développements Web ?
Que pensez-vous des objectifs de WebAssembly 2.0 ?

Voir aussi :

Wasmer : un runtime open source pour l'exécution de WebAssembly sur un serveur, tout en prenant en charge l'API Wasm-C
Découvrez Warp, un terminal de ligne de commande basé sur Rust qui se veut moderne et rapide, connecté au cloud et adapté au travail d'équipe

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

Avatar de genthial
Membre éprouvé https://www.developpez.com
Le 22/04/2022 à 8:35
Un langage proche de l'assembleur qui peut s'exécuter partout en étant presque aussi efficace que le natif ? Ce ne serait pas Java ?
Java était pensé au départ comme le langage du net, avec des applets qui pouvaient s'exécuter dans un navigateur.
Ça n'a bien pris parce qu'à l'époque le lancement de la JVM ralentissait pas mal le navigateur, mais aujourd'hui ?
2  0 
Avatar de nhugodot
Membre habitué https://www.developpez.com
Le 28/04/2022 à 13:18
Il semble qu'après la VM Java, puis celle de JS, on va sur une VM universelle (multi-langage), sorte de PC virtuel, avec si j'ai bien compris une collaboration inter-langages (enfin on pourrait faire un programme -une app, pardon...- avec des bouts de codes de différents langages! Fini le "aaah en PHP ou JS y'a plus de libs-), et avec ou sans la cible Web (voir WASI, le "NodeJS" ou Electron de WASM?).

Bref tout devient enfin agnostique: autant la plateforme dessous (CPU, OS) qu'au-dessus (HTML ou pas, canvas natif au pixel près, 3D, ligne de commande, API...) avec WASM/I.
(Enfin la révolution du code que le génial Alan Kay attendait...?
https://lnkd.in/eDkz4TZR )

Flutter (devant React dorénavant) permet effectivement aussi de cibler le web en HTML ou WASM, selon le use case...
(les gars se sont même amuser à porter Netscape sur WASM, donc de faire tourner un navigateur web dans...un navigateur web! )

On va enfin pouvoir développer des apps "internet" sans HTML... comme sur Windows/Android etc., "natives distantes"? Parce que le Web n'avait pas été fait pour des apps mais pour des documents...

Faire une app orientée doc, ok, mais sinon...

Quel "DOM", quel pendant à HTML, quel "navigateur d'applications" pourrait-on faire ainsi? (Y'a bien un "navigateur de jeux vidéos", Steam ou autre moteur 3D...)?

Can't wait to "browse the apps"... (ras le bol de les télécharger)
0  0 
Avatar de damthemad
Membre actif https://www.developpez.com
Le 28/04/2022 à 8:54
Il me semble que cet article donne une vision erronée de ce qu'est wasm.
De ce que j'avais lu il y a quelques années sur le sujet, ce n'est en aucun cas un bytecode exprimés dans un jeu d'instruction virtuel mais un AST.
IL n'y a pas de machine virtuelle côté navigateur qui va exécuter un jeu d'instruction.
Un AST est une phase intermédiaire de la compilation. En gros, la première phase qui est dépendante du langage source produit un AST qui est un représentation abstraite du programme (par abstraite, on entend indépendante du langage et de la plateforme d'exécution). C'est pourquoi on on peut avoir n langages qui produisent du wasm.
Ensuite cet AST est consommé dans une seconde phase pour produire un binaire dans l'architecture cible (par architecture, entendez jeu d'instructions, qu'il soit virtuel comme pour une jvm ou réel comme pout x86 etc.). C'est ce qui permet au code wasm de tourner sur n'importe quelle architecture processeur
La phase de compilation finale se fait côté client
Donc le navigateur ou autre client wasm, consomme un AST et produit un binaire natif.
Et le développeur code dans un langage quelconque dès lors qu'il permet de cracher un format wasm en sortie.
0  1