Discussion :

[Stéphane le calme]

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

[gstratege]

J'ai pas compris, c'est un langage ?

[bouye]

WebAssembly or wasm is an experimental efficient low-level programming language for in-browser client-side scripting, which is currently in development. Its initial aim is to support compilation from C/C++,[1] though other source languages are also intended to be supported. WebAssembly is a portable abstract syntax tree[2] which is designed to be faster to parse than JavaScript, as well as faster to execute.[1] The initial implementation of WebAssembly support in browsers will be based on asm.js[3] and PNaCl.[4] After the minimum viable product (MVP) release, there are plans to support garbage collection[5] which would make WebAssembly a compilation target for garbage collected programming languages like Java and C#. The team working on WebAssembly includes people from Mozilla, Google, Microsoft, and Apple (who respectively control the four major browsers, Firefox, Chrome, Microsoft Edge, and Safari).[4]

Si j'ai bien saisi un langage de script "allégé" et simplifié qui peut être généré à partir du C ou du C++ (pour le moment).

[Gugelhupf]

Je pense qu'il s'agit d'un bytecode standard pour les navigateurs, l'objectif étant sur le long terme d'utiliser le langage qu'on souhaite en front (alternatives à JS).

Autres avantages que j'y vois :

• Réseau moins surchargé (binaire vs texte JS)
• Chargement plus rapide (pas d'interprétation et parsage de langage lisible par un humain).
• Meilleure entente entre les éditeurs de navigateur, plus de chance d'avoir un web plus standard.

[23JFK]

"ce projet ambitionne de simuler un processeur virtuel, capable d’exécuter des programmes à une vitesse proche du code natif." Un clone Java quoi.

[marsupial]

"ce projet ambitionne de simuler un processeur virtuel, capable d’exécuter des programmes à une vitesse proche du code natif." Un clone Java quoi.

Mais o combien efficace.
Fantastique news !

edit : virtualiser tous mes tests dans un navigateur

[DonQuiche]

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.

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

[Uther]

J'ai pas compris, c'est un langage ?

Plutôt un bytecode. Les développeurs travailleront dans le langage de leur choix qui sera compilé en WebAssembly.
Personne ne programmera directement en WebAssembly. Il y aura certes une représentation textuelle, mais c'est juste une commodité qui servira pour les fabricants des outils qui manipulent le WebAssembly(compilateur, débogueur, ...) ou ceux qui voudraient faire du reverse engineering.

"ce projet ambitionne de simuler un processeur virtuel, capable d’exécuter des programmes à une vitesse proche du code natif." Un clone Java quoi.

Oui et non, c'est certes un bytecode comme Java, mais il n'est pas pensé pour un langage particulier. Il vise a être compilable directement en code natif, en évitant les coûts caché comme un GC.

En fait actuellement, c'est plus un asm.js sans la lourdeur induite par la syntaxe JavaScript.

[sekaijin]

lorsqu'on utilise un langage compilé en général la compilation consiste à produire un code exécutable
du code binaire machine.

avec l'avènement de la machine virtuelle java on a largement abordé la compilation jusqu'au code intermédiaire ByteCode
L'idée étant que la JVM s'exécutant sur différent processeurs la phase finale de la compilation consistant à traduire le ByteCode en langage machine était fait par la JVM elle même au moment de l'exécution (JIT)

ce principe à été repris par de nombreux langage interprété. au détail près que l'interprète analyse lui-même le code source et fait appel au JIT compiler pour l'exécuter.
c'est le cas je Javascript

Mais entre temps les progrès des processeurs a fait que l'émulation d'un autre processeur est devenu performante au point que les temps d'exécution sur de tels processeurs virtuels sont quasi équivalent à de vrai processeurs.
plutôt qu'une machine virtuelle basé sur un ByteCode envisager d'embarquer un processeur virtuel est devenue pertinent.
et comme pour tout processeur il existe un langage bien plus proche du langage machine qu'un code intermédiaire d'un compilateur. il s'agit de l'assembleur.

la solution est donc de faire des compilateur pour les langages désiré qui produisent code machine spécifique au processeur virtuel.
embarquer un processeur virtuel dans la plateforme cible.

A+JYT

[DonQuiche]

Mais il n'est pas question d'émulation.

Webasm est fonctionnellement équivalent aux représentations intermédiaires (IR) utilisées par GCC et à peu près tous les compilateurs modernes. Ils commencent par transformer le code source en une représentation intermédiaire typée et universelle, puis ils transforment celle-ci en instructions spécifiques au processeur cible.

Le code webasm sera bel et bien compilé. Sa compilation sera extrêmement rapide, équivalente à la dernière étape de la compilation d'un code C/C++ ou JS. Or les navigateurs incluent déjà cette dernière étape, et d'autres qui ne sont pas nécessaires pour webasm.

[Uther]

Mais entre temps les progrès des processeurs a fait que l'émulation d'un autre processeur est devenu performante au point que les temps d'exécution sur de tels processeurs virtuels sont quasi équivalent à de vrai processeurs.
plutôt qu'une machine virtuelle basé sur un ByteCode envisager d'embarquer un processeur virtuel est devenue pertinent.
et comme pour tout processeur il existe un langage bien plus proche du langage machine qu'un code intermédiaire d'un compilateur. il s'agit de l'assembleur.

Visiblement il y a une confusion entre émulation et virtualisation. La virtualisation permet d'avoir des performances très bonnes, d'autant plus quand le processeur fournit les outils pour aider à la supporter, mais les VM virtualisées utilisent directement le processeur : elles ne l'émulent pas.

Si on veut utiliser dans une VM un type de processeur différent de l'hote, on doit faire de la vraie émulation et là, les performances s'effondrent. Ça dépend de la complexité de la machine émulée et de la fidélité souhaité, mais il y a généralement un ou plusieurs ordres de grandeur d’écart.

[sekaijin]

Sorry

je me suis très mal exprimé en parlant d'émulation
ce que je voulais dire c'est que les machines virtuelles comme la JVM implémentent une abstraction d'une machine qui est assez éloignée de la machine physique.
le travail pour exécuter de façon efficace un ByteCode sur un processeur réel est important.

Aujourd'hui tout en concernant l'idée d'une machine universelle comme on cherchait à le faire avec la JVM
on sait faire des machine virtuelles plus proche de ce qu'est un simple processeur.
du coup il n'est plus nécessaire de s'arrêter au niveau du code intermédiaire (comme l'est approximativement le ByteCode jvm)
mais on peut compiler jusqu'à un niveau beaucoup plus proche d'un processeur.

La compilation WebAssembly consiste à aller aussi loin que possible dans ce sens pour que la machine virtuelle n'est que le stric minimum à faire pour exécuter le code sur les divers processeurs supportés.

A vouloir trop vulgarisé on fini par dire des choses contraires à ce qu'on cherche à dire.
A+JYT

[TiranusKBX]

C'est bien beau cette évolution mais ça vas devenir coton à mettre à jour les site si l'on doit passer par une case compilation en plus.
De plus je vois mal les serveurs web faire cette compilation, ce n'est pas le but d'un serveur web que de compiler 56 langages différents.
Alors quelle solution ?

[Uther]

C'est le développeur qui compilera le fichier WebAssembly. Ça donnera un fichier compilé qui sera utilisé dans les pages html via la balise <script> de la même manière qu'un fichier JavaScript externe.

Les outils de déploiement classiques devraient pourvoir le gérer sans problème. Après tout Il y a déjà pas mal d'outils qui reposent sur des fichiers compilés (Flash, GWT, TypeScript, CoffeScript, ...)

[TiranusKBX]

@Uther j'ai pas forcément envie de sortir visual studio pour ça
mais si il se mettait à avoir un module php pour ça ce serait le rêve, mais bon ...

[sekaijin]

ç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

[SylvainPV]

Tout le monde répète que ça ne va pas tuer JavaScript, que les technos pourront cohabiter, mais j'ai quand même un sérieux doute là-dessus. Si le JavaScript a comme surnom l'assembleur du web, c'est qu'il y a un sacré paquet de langages et extensions de langages qui compilent en JS : https://github.com/jashkenas/coffees...-compile-to-js

Maintenant qu'on a officialisé cette idée d' "assembleur du web" avec WebAssembly, et que cela se traduit par des gains de performance et de taille de bundles, qu'est-ce qui nous retient en JavaScript ? Même pour quelqu'un qui comme moi adore le langage JavaScript en tant que tel, je vois un intérêt à utiliser une compilation wasm pour coder en un SuperJS (marque déposée ) qui aplanit le support des dernières normes (ES6, ES+) entre navigateurs et se débarasse de quelques mauvais côtés du langage (var, new, ASI...)

[Uther]

Le but est bien en effet de retirer à JavaScript son statut d'assembleur du Web, parce qu'il n'a clairement pas été conçu pour ça mais de garder son rôle de script.
Personnellement, j'ai beau détester JavaScript au plus au point, je dois reconnaitre que comme son nom l'indique il est correct pour faire du travail de script. Je ne vais pas rajouter une étape de compilation pour des petits bout de script simples.

[SylvainPV]

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.

[tralloc]

Salut la compagnie.

Je suis les news sur le sujet depuis un petit moment.
J'ai l'impression qu'une nouvelle ère pour le web va s'ouvrir et je m'en réjouis. J'irais même à avancer que c'est une révolution extraordinaire.

Par contre sur le côté pratique, j'ai fais quelques tests avec asm.js, j'ai trouvé ça assez galère. J'espère que des outils vont rapidement arriver pour changer tout ça.
Des questions sans réponses me sont restées... Comment interragir avec le DOM, les canvas...

La petite démo qui était faite avec asm.js permettait de compiler, ça créait un canvas et je n'avais pas l'impression de pouvoir faire beaucoup d'autres choses.
(remarque faite par un dév java qui n'a pas l'habitude de compiler à la main)