Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

WebAssembly, le format binaire du web créé par Apple, Google, Microsoft et Mozilla

Les développeurs Java et .NET s’écrient : « Ah ! »
Internet 4 min
WebAssembly, le format binaire du web créé par Apple, Google, Microsoft et Mozilla

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.

106 commentaires
Avatar de LostSoul Abonné
Avatar de LostSoulLostSoul- 19/06/15 à 15:32:39

Like !

Avatar de ILPlais INpactien
Avatar de ILPlaisILPlais- 19/06/15 à 15:35:49

J'espère que ça ne sera pas un remake des applets Java ou d'ActiveX :roll:

Avatar de otto INpactien
Avatar de ottootto- 19/06/15 à 15:37:54

C'est très bien pour les perfs... par contre plus moyen de regarder le code source...
 

Avatar de zempa INpactien
Avatar de zempazempa- 19/06/15 à 15:41:59

ILPlais a écrit :

J'espère que ça ne sera pas un remake des applets Java ou d'ActiveX :roll:

si j'ai bien compris, l'idée n'est pas de faire des applets java-like ou des ActiveX-like mais de remplacer le code javascript par un pseudo binaire.
 
Comme tous les langages de script, on doit nécessairement passer par une première phase de parsing qui peut prendre beaucoup de temps pour ensuite interpréter le code.
 
Ce qui est envisagé est de "pre-compiler" le code pour que celui-ci soit directement interprété.
 
Il ne s'agit donc pas d'étendre les possibilités mais juste d'optimiser le poids et le temps d'exécution du javascript.

Édité par zempa le 19/06/2015 à 15:44
Avatar de porecreat Abonné
Avatar de porecreatporecreat- 19/06/15 à 15:42:06

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.

Avatar de wagaf Abonné
Avatar de wagafwagaf- 19/06/15 à 15:43:54

Aujourd'hui le code JS/Dart etc. est déjà "compilé" en JS  illisible.

Avatar de zogG INpactien
Avatar de zogGzogG- 19/06/15 à 15:45:13

Le js sera toujours dispo pour assurer la compatibilité avec "le reste du web".

Avatar de Firefly' Abonné
Avatar de Firefly'Firefly'- 19/06/15 à 15:46:01

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

otto a écrit :

C'est très bien pour les perfs... par contre plus moyen de regarder le code source...
 

Tu peu déjà pas voir le code des applications que tu utilise, et le js est souvent obfusqué .. et puis il suffira d'utiliser un navigateur qui as pas cette fonction ( ou la désactiver si dispo ) pour que le serveur te renvoie un js classique 
 
 edit : grillé :p

Édité par Firefly' le 19/06/2015 à 15:48
Avatar de maxxyme INpactien
Avatar de maxxymemaxxyme- 19/06/15 à 15:48:39

C'est "offusqué" le terme il me semble... ;)

Avatar de Naneday INpactien
Avatar de NanedayNaneday- 19/06/15 à 15:52:20

N'ont ils pas appris des erreur d'ActiveX, Java Applet, Flash etc ?

L'ouverture de OS au web, et ca sent pas bon

Édité par Naneday le 19/06/2015 à 15:52
Il n'est plus possible de commenter cette actualité.
Page 1 / 11