Apple, Google, Microsoft et Mozilla s’associent autour d’un projet commun pour accélérer largement le chargement des sites et l’exécution du code sous-jacent. Nommé « WebAssembly », il doit fournir en fait un bytecode aux navigateurs, pour des performances qui pourraient être multipliées par plus de 20.
Le JavaScript, toujours l'objet de toutes les attentions
Si le JavaScript a permis l’émergence du Web 2.0, il fait l’objet de critiques permanentes. Il a conféré au développement web des avantages indéniables, parmi lesquels son indépendance face aux architectures matérielles coté clients. Tant qu’aucune faille de sécurité ne vient gâter la situation, la présence d’une sandbox est une certaine garantie de sécurité. Heureusement d’ailleurs, puisque l’objectif du JavaScript reste d’exécuter du code capable de transformer une simple page web en un service ayant presque autant de possibilités qu’un logiciel natif.
Le langage est tellement utilisé, y compris sur le web mobile, que de nombreux éditeurs se penchent continuellement sur ses performances. Car ces dernières sont désormais un élément clé de la rapidité générale d’un site web. Améliorer ces performances passe aussi bien par des modifications dans l’écriture du code que dans la manière dont il est lu, interprété puis exécuté. Mais ce sont justement toutes ces étapes qui empêchent le JavaScript d’avoir les mêmes performances qu’un code natif.
Parmi les améliorations les plus notables de ces dernières années autour du JavaScript, on pourra notamment citer asm.js, un sous-ensemble de JavaScript conçu par Mozilla pour être exécuté très rapidement. Le TypeScript de Microsoft se destine pour sa part à ceux qui ont de vastes projets en JavaScript et qui veulent donc simplifier l’écriture via l’ajout de fonctionnalités spécifiques. Le standard ECMAScript (derrière le JavaScript) évolue également de son côté en ajoutant notamment de nouveaux types de données.
WebAssembly, un code intermédiaire lu vingt fois plus vite
La question était donc de savoir comment garder les avantages de JavaScript tout en gommant ses défauts. La réponse proposée par Microsoft, Google, Apple et Mozilla est simple : fournir un bytecode. Il s’agit d’un code intermédiaire, que les développeurs .NET et Java connaissent déjà, et qui vient se placer entre le fichier texte classique et l’assembleur. On pourrait parler vulgairement de code « prémâché » ou simplement précompilé. De fait, présenté au compilateur, il est beaucoup plus facile à lire par la machine et n’a plus besoin d’être interprété.
Le projet se nomme WebAssembly, ou « wasm », et le fait qu’il soit soutenu par les quatre plus grands éditeurs de navigateurs représente d’emblée un sérieux atout. L’idée était de rester sur le JavaScript, qui sert dans tous les cas de dénominateur commun. Par exemple, un développeur peut utiliser le TypeScript de Microsoft sans craindre que le code ne soit pas lisible puisqu’il est converti en JavaScript. Ce dernier peut être utilisé pour atteindre des API ou certaines technologies, comme WebGL, d’où l’idée d’en bâtir une amélioration, et surtout pas d’essayer de le remplacer.
Dans la pratique, un code WebAssembly est donc déjà précompilé et beaucoup plus léger à télécharger. Pour le compilateur, le code wasm présente un visage uniforme avec des types de données faciles à comprendre, comme des entiers 32 bits ou des nombres à virgule flottante. Sous cette forme, le parsing du code est vingt fois plus rapide qu’avec asm.js.
Un projet qui démarre, mais qui devrait rapidement prendre de l'ampleur
Parce que WebAssembly devra se faire une place parmi les solutions web, les quatre éditeurs prévoient donc de faciliter le travail des développeurs. Lors de la préparation du bytecode, ces derniers obtiendront donc le wasm lui-même, ainsi qu’une version texte pour le débogage. Par ailleurs, puisqu’il faudra le temps que tous les navigateurs soient à jour chez les utilisateurs, un script JavaScript (nommé « polyfill ») permettra aux développeurs de convertir le code wasm en JavaScript classique. La lecture d’un code ou de l’autre dépendra donc uniquement du navigateur et de sa compatibilité avec la nouvelle technologie.
Pour l’instant, WebAssembly en est à un stade assez peu avancé, on pourrait même dire de prototype. Pour l’instant, l’écriture du code se focalise sur les langages C et C++, mais d’autres sont prévus par la suite. En outre, aucun organisme de standardisation ne travaille encore sur ce projet, mais les quatre éditeurs impliqués attendent sans doute de progresser plus avant dans les spécifications avant de le faire passer à la moulinette du W3C notamment.
Enfin, on signalera la participation au projet commun de Brendan Eich, créateur du JavaScript, et pendant un court laps de temps PDG de Mozilla. Dans un billet sur son blog, daté de mercredi, il fait d’ailleurs le récapitulatif de la situation et explique pourquoi, en dépit des nombreux efforts faits jusqu’à présent, WebAssembly peut apporter un véritable avantage au web.
Commentaires (106)
#1
Like !
#2
J’espère que ça ne sera pas un remake des applets Java ou d’ActiveX " />
#3
C’est très bien pour les perfs… par contre plus moyen de regarder le code source…
#4
#5
Aucun risque puisqu’il ne s’agit pas d’applets et que le JS reste la base. Les changements ne concerneront que le process d’exécution (“sous le capot”), pas les fonctionnalités finales.
#6
Aujourd’hui le code JS/Dart etc. est déjà “compilé” en JS illisible.
#7
Le js sera toujours dispo pour assurer la compatibilité avec “le reste du web”.
#8
Non, tu ne pourra pas en faire plus qu’en javascript classique ( niveau api ), c’est juste qu’au lieux d’avoir interpreteur + jit, on as que du jit. Avec un bytecode déjà optimisé (hors optimisation de plateforme, laissé au jit )
Grosso modo, scope du JS, avec les perfs du java/c# ( voir mieux ? (doute) )
#9
C’est “offusqué” le terme il me semble… ;)
#10
N’ont ils pas appris des erreur d’ActiveX, Java Applet, Flash etc ?
L’ouverture de OS au web, et ca sent pas bon
#11
#12
#13
#14
J’ai apprécié ce commentaire lu ailleurs (enfin, je traduis…):
Tiens, le retour du p-code UCSD
#15
Avec l’arrivée de la 4G, le plus lourd sur une page ce sont quand même les images et les vidéos. Le temps d’exécution du javascript est du même ordre de grandeur en temps de traitement ?
#16
#17
#18
Obfusqué :)
#19
Parce qu’avant l’arrivée de la 4G ce n’était pas le cas ?
#20
Le temps de chargement est une chose, mais un site bien foutu aujourd’hui ne charge pas les données à chaque ouverture de la page, le cache est là pour ça. Par contre, le code est exécuté à chaque fois et il s’agit bien de réduire ce temps d’exécution. Tout est bon à prendre dans l’optimisation, et cette techno pourrait signifier la possibilité de faire des webapps multiplateformes qui soient enfin efficaces.
#21
Dans la même opération le code est souvent vastement optimisé, on peut alors parler de compilation.
#22
je vois pas comment ça peut faire gagner quoi que ce soit en perfs lors de l’exécution.
Ce que cette solution semble améliorer c’est juste le temps entre le moment où le code a fini de charger et le début de son exécution.
Donc ça démarrera plus vite mais ça s’exécutera pas plus vite pour autant.
#23
#24
#25
Par contre, c’est quoi cette histoire de C/C++ ? " />
#26
oups
#27
Quoi qu’il arrive c’est du code qui va modifier le page HTML, bref du javascript, donc je vois pas ce qu’adblock vient faire la dedans. Suffit de charger ton adblock après leur webassembly pour virer ce que leur code rajoutera eventuellement… comme maintenant en fait.
#28
Pas forcément. Certes, ton navigateur exécutera du Bytecode (attention, pas du code d’assembleur), mais il pourra aussi débugger en JIT (par exemple) sur les sources. Comme le fait Java et .net actuellement.
#29
#30
#31
Avec un bytecode qui est généré AOT, on doit bien pouvoir apporter plus d’optimisations que sur du code JS dont la compilation JIT doit se faire le plus rapidement possible.
#32
#33
#34
https://developers.google.com/closure/compiler/
#35
#36
[quote]Les développeurs Java et .NET s’écrient : « Ah ! »|/quote]
Ah !
Faudrait que je retrouve mes vieux post sur NXI où je disais qu’il faudrait un jour choisir si le browser était un simple viewer (de page html) ou un complexe environnement d’execution (de bytecode).
Prochaine étape: la disparition de HTML/CSS. Quel besoin de se faire chier à créer, transférer et interpréter du HTML/CSS alors qu’on peut créer son layout avec du bytecode universel ?
#37
#38
Encore un nid à failles de sécurité. Il va y avoir du RCE 0day à vendre.
Les applications supplantent peu à peu l’utilisation des sites web sur le mobile. Désormais c’est tout le web qui pourrait s’engouffrer dans cette voie. Certes, le rôle principale du navigateur reste encore le rendu, mais il devient de plus en plus un environnement d’exécution. Quelle différence avec l’actionscript compilé ou le byte-code java (applet, jnpl) ? Suis-je un vieux con nostalgique ou le web est-il en train d’y perdre son âme ? Question rhétorique : merci de ne pas répondre.
#39
Ça fait plaisir de voir un débat de cette qualité, merci à tous !
J’aurais tendance à dire wait&see, il y a des questions sous-jacentes et il faut voir ce qui sera communiqué.
Je n’ai pas non plus compris le lien avec c/c++
#40
#41
Ça c’est parce que quand tu vas sur un site t’as des requête vers tout l’univers : pubs, réseau sociaux, traceur, etc.
Celui qui m’impressionne le plus, récemment c’est Amazon qui t’affiche page pour la réécrire dernière en AJAX à l’identique… ça sert à rien.
#42
#43
En lisant les docs sur github visiblement tu vas pouvoir utiliser du C/C++ pour générer ton WebAssembly, qui va s’occuper de faire le lien entre ce que ton code veut faire et comment le navigateur peut le faire (exemple : OpenGL dans ton code > WebGL dans le navigateur etc.).
#44
Sans avoir les détails difficile de dire exactement, mais ça doit sûrement permettre à tout le monde de consulter les pages, ceux qui ont le JS ou un navigateur compatible ont les bénéfices de l’AJAX en plus.
#45
C’est un peu bizarre de s’en occuper maintenant vu que les machines sont surpuissante aujourd’hui. Et plus avec l’arrivée des SSD qui se démocratisent partout (les portable en premier).
#46
Oui, donc compilation côté serveur pour faire du wasm (en mode statique ou dynamique) parce que bien évidemment ton téléphone d’il y a un an va le supporter et sinon la lib miracle qui transforme du wasm en javascript puis un coup de JIT " />
Si les « développeurs » web viraient les trucs mal codés et consommateurs de ressources… non à la réflexion ce serait un cauchemar " />
#47
Oui, mais pourquoi ré-afficher ce qui est déjà afficher ? Je m’en suis rendu compte en voulant modifier une page à la voler. Et forcement à l’arrivée ma modif saute. " />
#48
En tant que dev tu dois savoir pourquoi : c’est plus simple et ça marche ! " />
#49
C’est plus simple de recharger à l’identique un élément déjà présent ? Il faudra que tu m’expliques en quoi c’est plus simple ? De plus, la bouffe de la bande passante pour rien, ça fait faire des calculs inutiles, ça augmente les ressources de navigateurs…
#50
Puisque tu vérifies pas si la MAJ est nécessaire… c’est plus simple. Bourin si tu préfères.
Et pour la bande passante, quoi qu’il arrive pour savoir s’il doit mettre à jour l’affichage il doit télécharger la nouvelle version pour eventuellement vérifier s’il y a des différences… donc tu as seulement la première info qui téléchargée deux fois… avec le cache et les CDN qu’Amazon doit avoir ça doit pas représenter grand chose en plus à mon avis.
#51
#52
#53
#54
#55
#56
#57
j’ai l’occasion de travailler avec une application web bien faite (une Single Page Application développée avec ext.js), et c’est très agréable.
Une appli qui n’a pas été bien conçue au niveau de l’interface utilisateur sera mauvaise, web ou pas web… Au passage si tu veux voir une appli web très avancée, tu peux jeter un coup d’oeil àhttps://portal.azure.com.
ils ont fait un boulot impressionnant au niveau de l’UX et de la navigation, et sur ce genre d’appli tu comprends aisément que le parsing de 10 Mo de javascript peut prendre du temps, particulièrement sur des terminaux mobiles.
#58
#59
#60
#61
#62
#63
#64
#65
#66
#67
#68
#69
C’est pas encore garanti : si c’est sandboxé, on peut se permettre d’autoriser les bound check sans compromettre le navigateur.
#70
#71
#72
#73
#74
1° tu peux avoir une application avec un GUI tout à fait agréable à l’utilisation, et pourtant qui est une horreur en code, donc je vois pas trop le rapport avec ce que je disais ;
2° regarde l’exemple que tu donnes (MS Azure), et dis-moi qu’il concerne davantage que 0,1% du web.
Je ne dis pas que 100% du web est codé avec les pieds … Seulement, disons, 99,5% " /> Et encore une fois, je parle de la conception au niveau technique, pas au niveau fonctionnelle ou ergonomique.
#75
#76
Et pourtant ce n’est pas tout à fait ça.
En fait le wasm sera assez bas niveau (typage,…) et sans contraintes lourde (GC,…) pour permettre d’avoir des performance proches du natif tout en étant le plus neutre possible face aux différents matériels.
Mais techniquement, contrairement à la JVM ou au CLR, il ne se présentera pas, par une suite d’instruction d’un processeur fictif , mais plutôt comme une sorte d’AST : la structure intermédiaire en forme d’arbre sur laquelle travaille le compilateur une fois qu’il a fait l’analyse syntaxique du code.
Selon ce qu’a annoncé l’équipe travaillant sur wasm, ça permettrait à la fois de gagner en taille et en vitesse de traitement.
#77
Vivement que les langages clients du web supplantent les applications proprio.
Le web est compatible avec n’importe quel device tant qu’il est capable d’afficher une page web correctement.
Il reste encore du boulot au web pour unifier les usages mobile/bureau mais tout les outils sont là, et surtout ils ont le gros avantage de ne pas dépendre (dans le meilleur des mondes) de la plateforme d’exécution ou d’un quelconque market à la con…
#78
#79
#80
#81
#82
#83
#84
#85
#86
#87
#88
#89
#90
Ils veulent faire faire du C++ aux développeurs web ??? Enfermez-les, ils sont devenus fous !!! " />
#91
Vu qu’adBlock & cie bloquent les REQUÊTES vers les pubs, tu t’en balance complètement du JS/WA…
#92
#93
Oh purée, c’est possible de savoir de quel binaire il s’agit ?
#94
#95
#96
#97
#98
#99
#100
#101
#102
#103
#104
#105