Mozilla, Microsoft et Google veulent booster le Web avec un nouveau format binaire,
WebAssembly représente-t-il une menace pour JavaScript ?
Le 2015-06-18 18:32:15, par Hinault Romaric, Responsable .NET
Les applications Web gagnent de plus en plus en complexité. De nos jours, de nombreuses pages Web disposent de contenus riches. Les jeux sur le Web sont en train de se démocratiser. Les navigateurs doivent offrir de meilleures performances.
Les éditeurs de navigateurs ont apporté de nombreuses optimisations à leur moteur d’exécution JavaScript, afin d’améliorer les performances de ceux-ci.
Cependant, les performances des applications JavaScript demeurent toujours très en dessous des performances des applications natives.
Plusieurs solutions ont été développées par des géants du Web afin de rapprocher les performances des applications Web de celles des applications natives.
L’une des premières solutions avait été proposée par Google. Le géant de la recherche avait développé Native Client, une technologie permettant d'exécuter du code C/C++ à l'intérieur du navigateur dans un environnement protégé. Native Client avait été intégré au navigateur Chrome. Mais, les autres éditeurs n’ont pas suivi le mouvement et la solution est restée peu utilisée.
La fondation Mozilla de son côté a développé Asm.js. Une technologie qui semble plus prometteuse que Native Client. Asm.js est un sous-ensemble de JavaScript qui permet d’améliorer considérablement les performances des applications Web.
Microsoft, quant à lui, pour faire de JavaScript une plateforme idéale pour le développement de costaux projets, a développé TypeScript. TypeScript est un préprocesseur qui ajoute un typage statique et optionnel au langage JavaScript.
Il est donc clair que JavaScript a de nombreuses faiblesses. Mais, il jouit d’une popularité et des avantages qui le rendent incontournable sur le Web. Il est supporté par tous les navigateurs, il est agnostique et fonctionne sur de nombreuses architectures. De plus, les scripts JavaScript sont exécutés dans le navigateur, au sein d’un sandbox, ce qui réduit les risques liés à la sécurité.
Au lieu d’évoluer de façon dispersée, des géants de l’IT se sont mis ensemble pour tirer parti du meilleur de leurs précédents investissements pour développer une solution qui pourra bénéficier d’une large prise en charge.
C’est ainsi qu’est né le projet WebAssembly, qui est soutenu par Google, Mozilla, Microsoft et des développeurs du moteur de rendu Web Webkit.
WebAssembly est un nouveau format binaire pour la compilation d’applications pour le Web.
Selon Brendan Eich, père du langage JavaScript, WebAssembly est une évolution de Asm.js. La solution permettra de combler certaines limitations de Asm.js.
En effet, si Asm.js permet d’optimiser la vitesse d’exécution des fichiers JavaScript, le recours à un analyseur de code pose encore problème, surtout sur les terminaux mobiles. « La compression est nécessaire et permet d’économiser la bande passante, mais la décompression avant l’analyse fait mal », explique Brendan Eich, qui fait savoir qu’en plus, JavaScript dispose de quelques maladresses, même dans son sous-ensemble Asm.js.
WebAssembly (wasm) comprendra à la fois une notation binaire que les compilateurs pourront produire et une notation texte correspondante, qui sera adaptée pour un affichage dans les environnements de développement.
Compte tenu du fait que JavaScript est supporté par tous les navigateurs, les développeurs du projet ont mis sur pied polyfill. Il s’agit d’un script JavaScript qui permettra de convertir wasm en asm.js pour les navigateurs qui ne supportent pas WebAssembly. Selon des tests avec un prototype de polyfill , wasm serait de 20% plus rapide que asm.js grâce, notamment, aux optimisations au niveau de la compression du code.
Une fois que la prise en charge de WebAssembly sera effective dans tous les navigateurs, la technologie pourra diverger de JavaScript, et s’éloigner « des aspects dangereux et inappropriés du langage de script ». De nouveaux outils (compilateurs, débogueurs, etc.) seront développés pour ouvrir le Web à d’autres langages utilisés pour le développement natif.
L’ équipe en charge du projet fait savoir que l’idée n’est pas de remplacer JavaScript. Mais, d’offrir plus de possibilités pour le Web et permettre aux développeurs d’utiliser des langages adaptés pour des opérations complexes, tandis que JavaScript continuera à exceller au niveau de l’interface utilisateur.
Avec le support dont bénéficie le projet, il devrait rapidement, à terme, se retrouver dans les navigateurs populaires. Un groupe communautaire a été créé pour le projet sur le site du W3C.
Source : Billet de Brendan Eich
Et vous ?
Que pensez-vous de ce projet ? JavaScript a du souci à se faire ?
Les éditeurs de navigateurs ont apporté de nombreuses optimisations à leur moteur d’exécution JavaScript, afin d’améliorer les performances de ceux-ci.
Cependant, les performances des applications JavaScript demeurent toujours très en dessous des performances des applications natives.
Plusieurs solutions ont été développées par des géants du Web afin de rapprocher les performances des applications Web de celles des applications natives.
L’une des premières solutions avait été proposée par Google. Le géant de la recherche avait développé Native Client, une technologie permettant d'exécuter du code C/C++ à l'intérieur du navigateur dans un environnement protégé. Native Client avait été intégré au navigateur Chrome. Mais, les autres éditeurs n’ont pas suivi le mouvement et la solution est restée peu utilisée.
La fondation Mozilla de son côté a développé Asm.js. Une technologie qui semble plus prometteuse que Native Client. Asm.js est un sous-ensemble de JavaScript qui permet d’améliorer considérablement les performances des applications Web.
Microsoft, quant à lui, pour faire de JavaScript une plateforme idéale pour le développement de costaux projets, a développé TypeScript. TypeScript est un préprocesseur qui ajoute un typage statique et optionnel au langage JavaScript.
Il est donc clair que JavaScript a de nombreuses faiblesses. Mais, il jouit d’une popularité et des avantages qui le rendent incontournable sur le Web. Il est supporté par tous les navigateurs, il est agnostique et fonctionne sur de nombreuses architectures. De plus, les scripts JavaScript sont exécutés dans le navigateur, au sein d’un sandbox, ce qui réduit les risques liés à la sécurité.
Au lieu d’évoluer de façon dispersée, des géants de l’IT se sont mis ensemble pour tirer parti du meilleur de leurs précédents investissements pour développer une solution qui pourra bénéficier d’une large prise en charge.
C’est ainsi qu’est né le projet WebAssembly, qui est soutenu par Google, Mozilla, Microsoft et des développeurs du moteur de rendu Web Webkit.
WebAssembly est un nouveau format binaire pour la compilation d’applications pour le Web.
Selon Brendan Eich, père du langage JavaScript, WebAssembly est une évolution de Asm.js. La solution permettra de combler certaines limitations de Asm.js.
En effet, si Asm.js permet d’optimiser la vitesse d’exécution des fichiers JavaScript, le recours à un analyseur de code pose encore problème, surtout sur les terminaux mobiles. « La compression est nécessaire et permet d’économiser la bande passante, mais la décompression avant l’analyse fait mal », explique Brendan Eich, qui fait savoir qu’en plus, JavaScript dispose de quelques maladresses, même dans son sous-ensemble Asm.js.
WebAssembly (wasm) comprendra à la fois une notation binaire que les compilateurs pourront produire et une notation texte correspondante, qui sera adaptée pour un affichage dans les environnements de développement.
Compte tenu du fait que JavaScript est supporté par tous les navigateurs, les développeurs du projet ont mis sur pied polyfill. Il s’agit d’un script JavaScript qui permettra de convertir wasm en asm.js pour les navigateurs qui ne supportent pas WebAssembly. Selon des tests avec un prototype de polyfill , wasm serait de 20% plus rapide que asm.js grâce, notamment, aux optimisations au niveau de la compression du code.
Une fois que la prise en charge de WebAssembly sera effective dans tous les navigateurs, la technologie pourra diverger de JavaScript, et s’éloigner « des aspects dangereux et inappropriés du langage de script ». De nouveaux outils (compilateurs, débogueurs, etc.) seront développés pour ouvrir le Web à d’autres langages utilisés pour le développement natif.
L’ équipe en charge du projet fait savoir que l’idée n’est pas de remplacer JavaScript. Mais, d’offrir plus de possibilités pour le Web et permettre aux développeurs d’utiliser des langages adaptés pour des opérations complexes, tandis que JavaScript continuera à exceller au niveau de l’interface utilisateur.
Avec le support dont bénéficie le projet, il devrait rapidement, à terme, se retrouver dans les navigateurs populaires. Un groupe communautaire a été créé pour le projet sur le site du W3C.
Source : Billet de Brendan Eich
Et vous ?
-
SylvainPVRédacteur/Modérateur
Que pensez-vous de ce projet ? JavaScript a du souci à se faire ?
Non, comme Eich l'a lui-même expliqué, WebAssembly est destiné à remplacer JavaScript dans son rôle de langage assembleur du web, car ce n'est pas la vocation d'un langage haut niveau comme JS. Plus tard, les langages divergeront pour s'améliorer dans leurs domaines respectifs. JavaScript continuera à être un langage à part entière, avec son écosystème et sa communauté. La différence majeure, c'est que les gens auront désormais le choix du langage. Mais certains préfèreront toujours le JS (si si)
C'est une excellente nouvelle pour deux raisons: déjà parce qu'elle ouvre la voie à une transpilation généralisée de logiciels vers un usage web (ce qu'avait prédit Gary Bernhardt dans son talk très amusant "The Birth and Death of JavaScript") ; et secondement, parce qu'on a réussi à mettre Google, Mozilla, Microsoft autour d'une même table pour plancher ensemble sur un nouveau standard ouvert. Vous l'aviez vu venir ça ? On parle quand même des boites qui ont fait chacun dans leur coin TypeScript, Dart et asm. Un très bon présage, vraiment. Si cela devient une réalité, le Web va radicalement évoluer. J'ai hâte de voir ça.le 19/06/2015 à 0:29 -
KimojasanMembre à l'essai@Metalman, les 20% sont comparé à du asm, pas à du pure javascript. Asm est au alentour 2 ou 3x moins rapide que du c....20% de 100%, c'est pas si mal, et c'est qu'un début. Sur le web on parle d'autre ordre de grandeur, mais je m'y attarderais pas, c'est beaucoup trop tôt.
Pour ce qui est du code source, je pense qu'il sera délivré à la demande, lors qu'un click droit -> view source, ou lors de débogage, ceci dit il sera toujours accessible, et ça pourra en repousser certains.
Pour ton troisième points, ça ne sera pas du binaire mais du "bytecode", et celui ci sera toujours, comme le js, exécuté dans une sandboxle 18/06/2015 à 22:59 -
youtpout978Expert confirméJ'ai envie de dire enfin ...
Je ne pense pas être le seul qui attendait une telle alternative, enfin 3 des plus gros acteurs du web se mettent à travailler main dans la main au lieu de faire chacun leur tambouille de leur côté pour nous pondre une alternative au JS.
Après ce que je trouvé bête c'est qu'on veuille tout mettre dans le web, le navigateur se rapproche d'un OS avec les problèmes que ça implique.le 19/06/2015 à 14:53 -
KimojasanMembre à l'essaiSuper nouvelle, je suis pressé dans apprendre plus ...
Il semblerait que dans un premier temps, les langages cible soit le c et c++, mais on parle aussi de go, c# et rust.
Une nouvelle qui risque à l'avenir de bouleverser l'écosystème logiciel applicatif... à suivre de très près !!le 18/06/2015 à 22:18 -
Paul TOTHExpert éminent sénioril existe déjà depuis longtemps un format binaire très compact dont l'exécution ne pose pas les mêmes problèmes d'analyse que Javascript...c'est AVM2, pour ... ActionScript Virtual Machine 2, également connu sous le nom de Flashle 18/06/2015 à 23:52
-
UtherExpert éminent séniorA priori ça sera transpilable vers javascript donc, ça gardera une compatibilité avec les anciens navigateurs.
1) Sauf que c'est mesuré par rapport à asm.js qui permet déjà d'avoir des performances qui se rapprochent du natif.
2) Tu as mal compris : le navigateur recevra uniquement la version compilée en wasm.
La représentation textuelle ne sera qu'une norme pour afficher le bytecode wasm de manière intelligible pour les développeurs qui voudraient travailler directement dessus.
C'est le même principe que pour le bytecode de la JVM ou le LLVM-IR qui ont leur propre représentation textuelle, ou même que l'assembleur qui est une représentation textuelle du langage machine.
3) Ça ne changera pas grand chose. Actuellement si tu veux cacher ton code, tu peux déjà utiliser du JavaScript obfusqué et minifié, et tu auras certainement un résultat bien plus complexe a comprendre que du wasm qui devrait être a peu près lisible sous forme textuelle.
Justement non. En compilant en asm.js on arrive généralement à de meilleures performances qu'avec un Javascript codé de manière idiomatique.
Pour Safari lui même, j'en doute. Il n'ont pas intérêt à s'opposer à l'intégralité du monde du web.
Par contre ça ne me surprendrait pas qu'il l’empêchent dans le composant web de leurs applications iOS qui est déjà passablement bridé.le 19/06/2015 à 10:37 -
Frédéric LatourMembre actifTypescript n'a pas été tué, loin de là. Le projet est très actif:
- Angular 2 (google) s'appuie sur typescript.
- Les développeurs du framework alternatif Aurelia étaient en discussion pour basculer sur typescript.
- Le support de React est dans le pipeline.
- Webstorm utilise les fichiers de définition de definitelyTyped pour améliorer l'intellisense.
- Sa relative facilité d'intégration et son adoption par certains poids lourds font qu'il est adopté par de nombreux développeurs aujourd'hui.
La transpilation de typescript en javascript n'a pas d'impact sur les performances d'exécution.
Je ne suis pas certain que Javascript ait du souci à se faire. Avec ECMAScript 6 et 7, c'est un langage moderne qui est en train d'émerger.le 25/06/2015 à 20:49 -
De nous jours les navigateurs sont déjà des supports applicatifs très important, un gain significatif de performances ne peut qu'amplifier cette tendance en élargissant le champ des possibles. Bonne nouvelle donc !le 19/06/2015 à 7:30
-
ZeflingExpert confirméDes dévs de Webkit étant dans la boucle, il faudra voir si Apple décide volontairement de retire cela de leur prochaine évo de Safari.le 19/06/2015 à 9:08
-
ZeflingExpert confirméCe genre d'offuscation ?
http://javascriptobfuscator.com/Java...bfuscator.aspx ou https://jscrambler.com/fr/le 19/06/2015 à 10:56