Mozilla, Microsoft et Google veulent booster le Web avec un nouveau format binaire

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

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 ?

:fleche: Que pensez-vous de ce projet ? JavaScript a du souci à se faire ?

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

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 !!

1) 20% d'accélération sur du lent... c'est pas grand chose quoi.

2)

Citation:

---

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.

@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

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 :D

:fleche: 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 :mouarf: )

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.

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 !

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.

Citation:

---

Envoyé par bilgetz

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.

Citation:

---

Envoyé par MikeRowSoft

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

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

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

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

Citation:

---

Envoyé par Uther

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 un truc peut être même pire que du wasm décompilé.

---

Ce genre d'offuscation ?
http://javascriptobfuscator.com/Java...bfuscator.aspx ou https://jscrambler.com/fr/

Par exemple. Et vu les spécificités de JavaScript on peut certainement faire pire.

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.

Ca va permettre de sortir Javascript de son double rôle de langage "bytecode" du web et de langage de haut niveau. Tous les langages compileront vers WASM. Ça clarifie et ça met tous les langages (Javascript, Typescript, Coffeescript, ClojureScript) à égalité.

En effet ça va sortir JavaScript de son rôle de bytecode.

Par contre ça ne met pas JavaScript vraiment à égalité avec les autres langages de script car il gardera quand même l'avantage d'être utilisable directement à l'intérieur de la page entre balises <script>, là ou les autres langages devront être compilés en wasm.

Citation:

---

Envoyé par Uther

En effet ça va sortir JavaScript de son rôle de bytecode.

Par contre ça ne met pas JavaScript vraiment à égalité avec les autres langages de script car il gardera quand même l'avantage d'être utilisable directement à l'intérieur de la page entre balises <script>, là ou les autres langages devront être compilés en wasm.

---

oh je suis à peu près certain qu'on va trouver des compilateurs wasm réalisés en Javascript qui permettront d'embarquer du CoffeeScript compilé à la volée ;) youpie !

on trouvera aussi des sites entièrement en wasm qui utiliseront DOM pour créer la page web.

enfin tout ça c'est si tous les acteurs de wasm arrivent à se mettre d'accord sur le format....

en même temps, je suis dubitatif, le format texte n'est pas réellement un frein à JavaScript, c'est à mon avis surtout sa souplesse qui pose problème, car compiler un code source on sait le faire depuis des lustres y compris en temps réel. Le format binaire réduit la taille du (byte-)code mais s'il embarque les mêmes notions high level que JavaScript il aura des performances similaires.

Citation:

---

Envoyé par Paul TOTH

oh je suis à peu près certain qu'on va trouver des compilateurs wasm réalisés en Javascript qui permettront d'embarquer du CoffeeScript compilé à la volée ;) youpie !

---

Pourquoi pas, mais ça sne serait pas franchement nouveau : ça se fait déjà en Javascript. Ça sera peut être un peu plus rapide en wasm, mais si tu es intéressé par la rapidité mieux vaut que ça soit déjà compilé sur le serveur.

Citation:

---

Envoyé par Paul TOTH

en même temps, je suis dubitatif, le format texte n'est pas réellement un frein à JavaScript, c'est à mon avis surtout sa souplesse qui pose problème, car compiler un code source on sait le faire depuis des lustres y compris en temps réel. Le format binaire réduit la taille du (byte-)code mais s'il embarque les mêmes notions high level que JavaScript il aura des performances similaires.

---

Justement, le but de ce bytecode est de rester autant que possible dans les notions de bas niveau. C'est pas pour rien que les premiers langages visés sont le C et le C++.

Citation:

---

Envoyé par bilgetz

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.

---

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

La javascript compilé sera fourni sous forme de bytecode bien sur, car pouvant tourner sur différentes architectures (X86, ARM en tête), ce qui signifie que les éditeurs doivent se mettre d'accord sur un format.
A moins qu'ils ne lancent une fondation indépendante, et connaissant l'historique de Microsoft avec les projets partagés (NT, Sybase, Java...), il n'est pas certain que le projet aboutisse.

Ensuite il faudra un outillage conséquent : déboguage, ide, etc....

Cela irait dans le sens d'une évolution.