Mozilla, Microsoft et Google veulent booster le Web avec un nouveau format binaire,
WebAssembly représente-t-il une menace pour JavaScript ?

Le , 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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de - https://www.developpez.com
le 18/06/2015 à 21:48
W3C a une balise spécifique pour accéder à cette fonctionnalité ou sa n'a rien à voir?

EDIT:Les vieux navigateurs n'y auront donc pas accès. Les tablettes et smartphones auront donc une date d'expiration...
Avatar de Kimojasan Kimojasan - Membre à l'essai https://www.developpez.com
le 18/06/2015 à 22:18
Super 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 !!
Avatar de Metalman Metalman - Membre expert https://www.developpez.com
le 18/06/2015 à 22:47
1) 20% d'accélération sur du lent... c'est pas grand chose quoi.

2)
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.
Alors là il va y avoir un GROS souci :
- soit on va envoyer du binaire et du texte == "script"/"programme" plus gros qu'un simple script en taille + qui va m'assurer que le texte correspond au binaire ? (on va ajouter de la signature électronique à un script qui sera dans une page HTTPS elle-même chiffrée ? ça va pas alourdir un "poil" ?)
- soit on va envoyer un script qui sera compilé == ....attendez, on va extraire, compiler, et exécuter, et vous voulez me faire croire que ça va être speed ?

3) Donc maintenant internet pourra exécuter "automatiquement" du binaire illisible quand on visitera une page ? Il me semble qu'une certaine catégorie d'utilisateurs peu gentils seront EXTREMEMENT contents de cette avancée révolutionnaire.
Avatar de Kimojasan Kimojasan - Membre à l'essai https://www.developpez.com
le 18/06/2015 à 22:59
@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 sandbox
Avatar de Paul TOTH Paul TOTH - Expert éminent sénior https://www.developpez.com
le 18/06/2015 à 23:52
il 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 Flash
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 19/06/2015 à 0:29
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.
Avatar de Mrsky Mrsky - Membre éprouvé https://www.developpez.com
le 19/06/2015 à 7:30
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 !
Avatar de bilgetz bilgetz - Membre averti https://www.developpez.com
le 19/06/2015 à 8:34
Je suis d'accord avec la plupart des commentaire d'ici.
Si les 3 plus gros navigateur le supporte et respecte tous les 3 le même standard, ça peut se développer.
C'est un peu ce qui as tuer Typescript et dart les autre navigateur ne le supporte pas et la conversion vers javascript n'est jamais plus performante que d’écrire directement en JS.

Le seul gros probleme va être safari avec les iTruc, si il ne s'aligne pas çà risque de tuer dans l’œuf l'initiative.
Avatar de Zefling Zefling - Membre expert https://www.developpez.com
le 19/06/2015 à 9:08
Citation Envoyé par bilgetz Voir le message
Je suis d'accord avec la plupart des commentaire d'ici.
Si les 3 plus gros navigateur le supporte et respecte tous les 3 le même standard, ça peut se développer.
C'est un peu ce qui as tuer Typescript et dart les autre navigateur ne le supporte pas et la conversion vers javascript n'est jamais plus performante que d’écrire directement en JS.

Le seul gros probleme va être safari avec les iTruc, si il ne s'aligne pas çà risque de tuer dans l’œuf l'initiative.
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.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 19/06/2015 à 10:37
Citation Envoyé par MikeRowSoft Voir le message
EDIT:Les vieux navigateurs n'y auront donc pas accès. Les tablettes et smartphones auront donc une date d'expiration...
A priori ça sera transpilable vers javascript donc, ça gardera une compatibilité avec les anciens navigateurs.

Citation Envoyé par Metalman Voir le message
1) 20% d'accélération sur du lent... c'est pas grand chose quoi.

2) Alors là il va y avoir un GROS souci :
- soit on va envoyer du binaire et du texte == "script"/"programme" plus gros qu'un simple script en taille + qui va m'assurer que le texte correspond au binaire ? (on va ajouter de la signature électronique à un script qui sera dans une page HTTPS elle-même chiffrée ? ça va pas alourdir un "poil" ?)
- soit on va envoyer un script qui sera compilé == ....attendez, on va extraire, compiler, et exécuter, et vous voulez me faire croire que ça va être speed ?

3) Donc maintenant internet pourra exécuter "automatiquement" du binaire illisible quand on visitera une page ? Il me semble qu'une certaine catégorie d'utilisateurs peu gentils seront EXTREMEMENT contents de cette avancée révolutionnaire.
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.

Citation Envoyé par bilgetz Voir le message
Je suis d'accord avec la plupart des commentaire d'ici.
C'est un peu ce qui as tuer Typescript et dart les autre navigateur ne le supporte pas et la conversion vers javascript n'est jamais plus performante que d’écrire directement en JS.
Justement non. En compilant en asm.js on arrive généralement à de meilleures performances qu'avec un Javascript codé de manière idiomatique.

Citation Envoyé par Zefling Voir le message
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.
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é.
Contacter le responsable de la rubrique Accueil