WebAssembly, qui ambitionne de devenir le code binaire du web, franchit une nouvelle étape. La technologie est en cours de test chez Apple, Google, Microsoft et Mozilla, certains proposant même des préversions aux développeurs intéressés.
WebAssembly est un projet commun des quatre entreprises pour s’occuper des problèmes de JavaScript. Comme nous l’indiquions ce matin, le langage de script est devenu omniprésent, au point d’être utilisé dans la conception de logiciels classiques. On le trouve évidemment surtout dans les pages web, où il permet de créer des services complets. Se pose alors la question des performances.
Gommer les problèmes du JavaScript
De nombreux travaux ont été menés sur les dernières années pour accélérer le traitement du JavaScript. C’est le cas des optimisations réalisées par Google sur le moteur V8, d’asm.js chez Mozilla, de Chakra chez Microsoft et ainsi de suite, chacun y allant de sa machine virtuelle ou de composants divers. Comment du coup garder les avantages de JavaScript, tout en gommant ses défauts, en particulier la sécurité et les performances ?
Apple, Google, Microsoft et Mozilla ont proposé en juin de l’année dernière leur solution : un bytecode, autrement dit un code intermédiaire, à mi-chemin entre le script et l’assembleur. Les développeurs Java et .NET notamment connaissent bien ce code, qui consiste en fait à prémâcher le travail du compilateur en lui fournissant un code précompilé. Les avantages proposés étaient multiples : performances, sécurité, une taille réduite des fichiers, un parsing très rapide du code via des types de variables très simples, etc.
Une première démonstration fonctionnelle
Lors de l’annonce cependant, l’ensemble du projet en était à un stade peu avancé, malgré les efforts manifestes des quatre entreprises. Évidemment, le travail a avancé, et ils sont prêts désormais pour une démonstration et des préversions de certains navigateurs. C’est Mozilla qui a ouvert le bal des annonces, via l’ingénieur Luke Wagner : « Je suis très heureux d’annoncer que WebAssembly a franchi une étape importante : il y a désormais de multiples implémentations expérimentales dans les navigateurs, toutes interopérables ».
Wagner indique que la route est encore longue mais que la synchronisation des éditeurs permet de présenter un résultat beaucoup plus probant au public. Même écho chez Microsoft, à travers Limin Zhu, responsable du développement du moteur Chakra : « 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 ».
Un travail sur les performances avant tout
Du côté de chez Google, le message est peu ou prou le même : les performances sont clairement supérieures. Le responsable Seth Thompson explique par ailleurs que la prise en charge de WebAssembly se fait en aménageant une compatibilité dans la machine virtuelle V8, notamment en réutilisant 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 ».
Pour autant, même si la démonstration fournie est fonctionnelle, les travaux nécessaires sont encore nombreux, sans parler des outils à fournir aux développeurs. Thomson en donne d’ailleurs une idée : « 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 ».
Chez Mozilla, les ambitions sont les mêmes. Le support de WebAssembly sera donc ajouté plus tard aux outils de développement de Firefox, notamment le débogueur et le profileur. Parmi les améliorations envisagées, l’éditeur souhaite également réduire le temps de lancement à froid et la préparation d’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.
Le succès passe par la séduction des développeurs web
Il est évident que WebAssembly pourrait jouer un grand rôle dans le développement web au cours des prochaines années. Le succès de la technologie passe cependant par une interopérabilité totale (ce qui est évidemment l’un des objectifs) et par des outils adaptés aux développeurs. La question du support par les navigateurs ne se pose évidemment pas, les sociétés travaillant sur le projet représentant tous les plus utilisés.
Actuellement, si l’on souhaite tester WebAssembly, il n’existe qu’un moyen de le faire : se rendre sur la nouvelle page mise en ligne sur le dépôt GitHub officiel. De là, on pourra récupérer une préversion de Chrome ou de Firefox compatible, puis revenir sur la page afin d’y lancer la démo, Angry Bots (basé sur le moteur Unity). Cette dernière est un jeu où l’on contrôle au clavier (déplacements) et à la souris (tir et visée) un personnage dans un complexe futuriste, rempli de robots meurtriers. Notez qu’on peut la lancer également en asm.js classique pour mesurer l’écart significatif des temps de chargement.
Pour ceux qui le souhaitent d’ailleurs, la page est à garder dans les favoris pour vérifier le statut général du projet. Signalons également que Microsoft dispose également d’une version compatible de son navigateur Edge, mais uniquement en interne pour l’instant. Du côté d’Apple, pas d’annonce particulière, mais la page consacrée au statut des technologies supportées par Webkit indique bien que WebAssembly est en développement.
Commentaires (54)
#1
un format binaire ça ouvre des perspectives intéressantes pour les auteurs de virus …
#2
L’informatique, le domaine où on réinvente les trucs tous les 5 ou 10 ans, parfois plus. 
" />
En l’occurrence, on réinvente la compilation JIT de Java et le bytecode, à l’époque où on pensait que le Java allait être utilisé de plus en plus pour rendre le Web plus riche (client riche) via les applets Java.
#3
Ah oui mais la attention c’est google/MS/Mozilla qui sont derrière ! c’est beaucoup mieux
" />
#4
Bienvenu dans le Web fermé….
#5
Et le bytecode Flash !
#6
Le JAVA ce n’est pas du JIT il me semble. Par contre il me semble bien qu’il y en avait au début de C#.
#7
C’est la suite logique de la convergence full web. J’espère que ce sera en opt-out par défaut, mais bon faut pas rêver
" />
#8
#9
Attention, ce n’a rien à voir avec du bytecode/code intermédiaire.
Mais plutôt la possibilité d’avoir du javascript sous format binaire plutôt que text, les données d’AST sous format binaire en quelque sorte.
Donc on ne peut pas le comparer à du CIL, ABC, Java bytecode, etc.
Le format prévoit un format text pour pouvoir le lire en clair
http://www.2ality.com/2015/06/web-assembly.html
#10
C’est ni plus ni moins dangereux que du javascript. C’est juste le format qui change.
#11
Si ca a la meme syntax que le JS, alors non merci, je trouve le JS degeulasse
#12
#13
#14
#15
Je ne vois pas en quoi le WebAssembly résoudrait un “problème” du JS. Le fait que le JS soit compilé à la volée n’est pas un “problème”, c’est juste un choix qui a été fait pour ce langage, avec son lot d’avantages et d’inconvénients.
D’ailleurs, dire que le JS n’est pas performant c’est soit faire preuve de mauvaise foi (comme les gens qui ne prennent pas la peine de s’y intéresser le font bien souvent), ou ne rien comprendre au langage (enfin vu le nombre de gens qui confondent l’API du DOM avec le JS…).
Peu importe l’avis que l’on a sur le WebAssembly, dire que c’est une solution aux problèmes du JS n’est pas vrai. Le JS a des problèmes réels qui n’ont rien à voir avec sa compilation en temps réel (puisqu’il est principalement question de ça, outre le fait que ce ne soit pas un langage de bas niveau) comme les variables globales, ou l’eval, pour les plus connus.
Donc non, le WebAssembly n’est pas là pour faire ce que fait déjà l’ecmascript.
#16
#17
#18
… et au final, ils ont trouvé LA solution:
l’assembleur.
#19
#20
#21
Le kiff serait un byte code qui contient le code pour toutes les archi, seules les parties spécifiques auraient besoin d’être dupliquées (SSE, NEON, ASM,…).
Et d’avoir a cote des outils permettant de filtrer ce big binaire pour en extraire que la version demandée par l’utilisateur final.
Ha ben en fait Apple fait déjà ca, leur byte code contient les versions 32 et 64 bits alors que le store peux n’envoyer que la bonne version au device a l’installation.
Toutes les app devraient être comme ca, c’est super pour nous les développeurs qui pourrions ainsi utiliser plusieurs languages car leur byte code seraient compatibles.
#22
Ben en fait la convergence est plutôt vers les applications compilées du coup.
#23
Si ça peut ouvrir la voie à des toolchains permettant de créer des pages web avec autre chose que cette immondice de JS, sans avoir recours à des plugins, why not.
#24
#25
J’adore l’évolution actuelle : Des ordinateurs ultra-puissants dont les programmes natifs sont d’une efficacité redoutable, mais pour en faire quel usage réellement ?
Pour exécuter des web-app dont le rapport performance/consommation est encore plus mauvais qu’une alimentation no-name de mauvaise qualité…
Je ne fais rien :
0xEB, 0xFE (jmp -2)
#26
S’ils pouvaient aussi penser à envoyer le HTML en précompilé, ça gagnerait en taille, performance, etc.
Peut-être dans 10 ans.
Le web a techniquement été très mal pensé à la base, sans utilisé l’existant, tout est à refaire. Le javascript qui cherche à devenir du java en est un exemple.
#27
C’est pas vraiment qu’il a été mal pensé mais qu’il a été pensé pour les besoins de l’époque (il y a plus de 25 ans) : présentation de document avec beaucoup de texte, très peu de mise en forme.
Aujourd’hui le web ce n’est plus du texte mais de vraies application complètes. Si Tim Berners-Lee avait deviné ce que deviendrait le HTML, il l’aurait certainement fait bien différemment.
#28
Qui compilera le wasm ? Le navigateur à la volée, ou les développeurs des sites web ?
#29
Flash est mort
" />
Vive Flash WebAssembly !
#30
Le Bitcode de Apple est bien un bytecode, voir section Bitcode https://developer.apple.com/library/tvos/documentation/IDEs/Conceptual/AppDistri…
C’est obligatoire d’envoyer les app sur l’AppStore sous ce format pour TvOS, WatchOS et surement bientot iOS.
#31
#32
Comment du coup garder les avantages de JavaScript, tout en gommant ses
défauts, en particulier la sécurité et les performances ?
En quoi WebAssembly apporte-t-il plus de sécurité ?
#33
C’est horrible comme assembleur, cpu full
" />
#34
Les développeurs
" />
#35
#36
#37
Après avoir essayé la version standard (asm.js standalone) du petit jeu dispo sur la page en question, franchement je vois pas où sont les problèmes de performance…
#38
#39
C’est un problème idéologique, pas technique.
Tu ne pourra jamais forcer les gens à adhérer à des principes via des contraintes techniques.
#40
Merci. 
" /> C’est bien ce qui me semblait à première vue.
#41
Si je comprends bien, ça pourrait permettre de créer facilement un interpréteur forth. Dès qu’il y aura une toolchain pour le C, on pourra adapter un des nombreux forth libres qui existent. On pourra alors charger un source forth et l’interpréter. et tout ça sans plugin. Un programme forth, c’est tout petit et hyper rapide. Et l’intérpréteur forth aussi c’est tout petit (et rapide bien sûr sinon le forth serait lent). Ça permettrait de coder les parties les plus lentes.
il y a aussi des forth objets mais j’ai jamais tâté de ces trucs-là, alors je ne peux pas dire.
Mais déjà coder un jeu en forth pour un navigateur, ça ce serait un truc bien geek qui me plairait bien !!!
#42
#43
Pas besoin de WebAssembly pour ça, c’est déjà faisable complètement faisable avec asm.js.
#44
#45
Uther, seul entre tous pour relever le niveau :)
#46
Enfin ! A mort Javascript! Et intégrons un nouveau bytecode qui permet de rassembler les avantages du Javascript (accès direct à la structure de la page par exemple et portabilité) et ceux de Java/Silverlight (performance correctes et conso mémoire gérable)
Du multithread! Des SIMD! Et j’espère un bytecode type de celui de Java, vérifiable au chargement pour éviter les dépassements de pile.
Je suis vraiment ravi de cette nouvelle. Presque autant que si on m’avait dit qu’un nouveau processeur permettait d’adresser le cache en indexé pour exécuter du Java quasi natif…
#47
Merci c’était exactement le fond de ma pensée
" />
#48
@Uther oui, asm.js doit permettre ça, mais il n’est pas déployé partout et il est plus lent. Mais en effet, ça donne déjà les moyens d’essayer. Mais le travail fait coté compilation sera sans doute à refaire après pour le jour où webassembly sera prêt.
#49
asm.js est du Javascript : il marchera donc partout avec des performances certes variables. Il faut noter que asm.js est maintenant supporté de manière optimale par 3 des 4 principaux moteurs JavaScript moderne et pas trop mal WebKit.
asm.js est déjà obtenu en compilant du code C. Vu qu’il reposent tous les deux sur les mêmes API Web la conversion de l’un à l’autre devrait être triviale. WebAssembly, c’est globalement asm.js débarrasé de la couche de compatibilité JavaScript.
#50
Ou je veux en venir ?
Je dis simplement que le fait que ce soit un format texte ou binaire n’a aucune impact sur la question de l’open-source.
Si les gens veulent faire du fermé dans un format texte il y a et y aura toujours plein de solution, tu ne pourra jamais mettre en place un socle technique qui forcera les gens a faire du code ouvert par défaut.
C’est purement une question idéologique : si tu veux faire de l’open source en WebAssembly ou autre format binaire tu peux, de même que l’inverse.
Taper sur une représentation binaire en disant que c’est “limite” c’est juste passer à côté de la vrai question.
#51
#52
#53
+100
en meme temps quand tu vois les usines a gaz pour afficher une page web toute simple…je faisais du web en asp/php3 au debut des années 2000, y’avait des limites ok mais bon les sites étaient performants…et les pages pesaient pas 10Mo pour 3boutons !!!
maintenant avec leur framework j2ee and co, utilisés pour tout et surtout n’importe quoi, maitrisés par peu de gens et utilisés par bcp, développés sans un minimum de reflexion sur l’archi pour la partie web et le mpd de la base oracle derrière, on obtient des applis horribles a maintenir et avec des perfs a chier…quand tu vois que le serveur websphere rame a mort derriere et que tu mets 3 min a afficher ta page web avec 4 boutons et une grille de donnée…ca fait rigoler quand on te sort que c du high tech ;)
enfin bon l’avantage c que la ou il fallait un dev web debut 2000, il t’en faut 10 maintenant pour le meme genre de site :)
bon site performant : google/amazon, chartre graphique bien penséé, site réactif et fonctionnel
site a chier : sncf ? transilien.com nouvelle mouture ?
c dommage que les gens se posent plus la question dans le bon ordre : “quels sont les technos et outils les mieux adaptés pour répondre au besoin de mon client” alors que la c plutot “j’adore asp.net et j2ee donc on va utiliser ca :)”
je dis asp.net car c’est juste une partie de ce que peut faire la plateforme .net meme si les “décideurs” et meme certains devs ont réduits ca au c# et asp.net :/
#54