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 !

Google, Microsoft et Mozilla proposent une démonstration fonctionnelle de WebAssembly,
Le projet ambitionne de devenir le code binaire du web

Le , par Stéphane le calme

61PARTAGES

11  0 
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

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

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
7  0 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 25/03/2016 à 4:08
Citation Envoyé par p3ga5e Voir le message
Mais bien sûr laissons la question d’interopérabilité de côté et laissons le champ libre à Unity l’utilisation des WebAssembly a leurs fin personnel !
WebASM est une initiative de Mozilla, Microsoft et Google.

Unity n'est qu'un des logiciels à l'utiliser et ne contrôle en rien cette techno, pas plus qu'ils ne contrôlent javascript. Même chose pour emscripten qui n'a pas été développé par Unity.
5  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 20/03/2016 à 13:05
ça ne remets pas en cause le javascript interprété
c'est un complément.

de toute façon aujourd'hui déjà on utilise des grunt, glup, sencha app build avec Javascript.
si demain les outils du genre produise un code rapide et optimisé
ça ne changera pas fondamentalement les méthodes de travail.

sauf peut être pour ceux qui mélange allègrement dans un langage serveur la production de HTML, CSS, JS, l'accès au donné, et le code métier dans un même code php asp ou jsp.

A+JYT
4  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 DonQuiche
Expert confirmé https://www.developpez.com
Le 19/03/2016 à 5:39
Citation Envoyé par gstratege Voir le message
J'ai pas compris, c'est un langage ?
Oui et non. Tu pourrais l'utiliser directement mais c'est plus un outil pour des langages. Ça ressemble à de l'assembleur (mais pile d'opérandes plutôt que registres) ou au bytecode java (mais plus bas niveau).

* Flux d'instructions basé sur une pile d'opérandes ("add" dépile les deux opérandes en haut de la pile puis empile la somme des deux). Pas d'expressions.

* Fonctions, variables locales, flux de contrôle (loop, goto, if, else), quatre types seulement (i32, f32, i64, f64), interruptions/traps (pour exceptions & co).

* Gestion directe de la mémoire via pointeurs.

* Peut accéder aux API du navigateur. Plus tard pourra manipuler les objets JS et créer des objets qui seront gérés par le ramasse-miettes de JS.

* Sécurité basée sur l'isolation : chaque page repose dans un processus dédié avec des droits restreints. La sécurité repose sur le processeur (empêche l'accès à la mémoire des autres processus et au matériel) et l'OS (qui vérifie les droits du processus lorsque celui-ci appelle une de ses fonctions, par exemple pour ouvrir un fichier).

L'OS du futur est un navigateur.

Citation Envoyé par 23JFK Voir le message
"ce projet ambitionne de simuler un processeur virtuel, capable d’exécuter des programmes à une vitesse proche du code natif." Un clone Java quoi.
Non, le bytecode java est de plus haut niveau : Java ne fournit pas d'accès direct à la mémoire et il impose à la place son système de types et un ramasse-miettes. Webasm est plus proche d'un assembleur, sauf que les registres sont remplacés par une pile d'opérandes.
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 21/03/2016 à 14:48
Sans doute, mais ça fait déjà des années que les développeurs pros JavaScript passent par la case transpilation, que ce soit Babel, des langages alternatifs comme CoffeeScript ou simplement les tâches de bundle/minification. Je n'ai pas l'impression que ce soit encore un blocage aujourd'hui.

Il se peut aussi que JavaScript va partir dans 2 directions différentes, l'une basique pour les petits scripts à trois francs six sous, et l'autre sous une forme compilée/ultra-outillée dans la lignée des TypeScript/JSX etc... On verra bien, dans tous les cas ça ouvre la concurrence des langages sur le web client tout en boostant les perfs et réduisant le trafic, donc c'est une excellente chose.
2  0 
Avatar de nhugodot
Membre régulier https://www.developpez.com
Le 02/03/2017 à 8:47
Un grand merci à l'explication complète!

J'ajoute que le code WebAssembly état binaire, compressé, il est plus petit donc rapide de charger une page web type SPA, lourde, webapp, et que ça va alléger notre 4G (ou 3G en Inde low cost par exemple)

Que cela permet aussi d'être sécurisé car un pirate interceptant la communication ne pourra lire le code comme il peut le faire avec tout script (donc dont JavaScript /ES) et injecter du code (vers le navigateur ou le serveur) (ai je bien compris?)

Bref, plus rapide, plus sécurisé, on a tout gagné.

Liberté:

Et bien sûr, on va voir enfin poindre sans doute du Ruby PHP et Python POUR NAVIGATEUR, à la place de JS... Tous les frameworks vont pouvoir devenir full-stack enfin: vu le plaisir et la facilité de Ruby, l'écosystème PHP, ou l'universalité de Python, versus la Javascript fatigue, ça va drôlement changer les choses, et on pourra enfin faire un site web avec son language préféré.

Manque une brique dans cet écosystème néanmoins: les apps smartphones:

en mobile, on veut une app plus qu'une page web (idiot mais ok...), et le dev d'apps se faisant en natif Swift pour iOS ou Java pour Android, avec néanmoins une alternative type JS via React Native de Facebook (ce que nous faisons chez nous, merci FB!) qui ensuite et porté sur iOS ou Android (ou Web tout court...), quid de WebAssembly ici sur les apps?
Je vois un futur de WebApps en progressive web apps (très belle techno balbutiante!) donc bien sur le moteur web... Webkit... aïe, Apple fait encore des siennes et n'est pas partie prenante de WebAssembly (fuck la pomme, grrrr...) et son Safari ne le supportera pas. On revient avec le problème: comment faire du natif iOS sans Swift (ni Objective-C), sans JS (que Safari, lui, supporte...)? Ah mais je me trompe peut-être, Safari est sur Webkit et donc ... ça marcherait? J''ai un doute...

Un dernier point: WASM vs Java et les IoT:

Java était "code once, run anywhere" grâce à sa JVM sur donc un "CPU virtuel idéal". Ok ok... Mais là nous avons donc une autre techno assez similaire, en tout cas qui vise aussi à l'universalité (run anywhere) MAIS qui casse le gros problème de Java: Java lui-même (et ces mossieurs d'Oracle...): on peut ENFIN coder en tout language, et viser cette machine virtuelle (WebAssembly) universelle (on peut sûrement la porter ailleurs que sur un navigateur Web, tiens! Un embedded device? Automobile, GPS, etc.?)
Il serait intéressant de faire un comparatif de performance non pas JS versus WASM mais WASM versus Java JVM!!! En avez vous? Kill java...? ;-)
Avec les IoT qui déboulent (et leur non sécurité..., et leurs réseaux lents type SigFox à 3-5 SMS par jour, leur micro CPU lent, faible mémoire, etc.) WASM pourrait être un bon remplaçant à Java (qui a été d'ailleurs exactement fait pour ça, des micro-programmes téléchargeables! Je faisais des apps java sur SIM 16K envoyées par bouts de code par SMS en 98... c'est dire! Minitel était un superordinateur à côté...)

Les années 20 (2020... ;D) vont être prometteuses...
2  0 
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  0 
Avatar de pol2095
Membre régulier 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.
6  4 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web