Connexion
Abonnez-vous

Avec la Bytecode Alliance, le WebAssembly va s’affranchir du seul web

Avec la Bytecode Alliance, le WebAssembly va s’affranchir du seul web

Le 13 novembre 2019 à 09h14

Le WebAssembly est pour rappel un bytecode, c’est-à-dire un langage intermédiaire, précompilé et généré initialement à partir du JavaScript. Standardisé en 2017, le format binaire a rapidement fait des émules, puisque les développeurs pouvaient aussi bien utiliser du C++ ou du Rust.

Au vu des possibilités, plusieurs entreprises se sont rassemblées pour élargir ses horizons. Intel, Mozilla, Red Hat et Fastly forment ainsi la Bytecode Alliance, dans l’idée de créer un runtime multiplateforme pouvant donc servir dans les applications natives pour ordinateurs, appareils mobiles ou même environnements serveur.

L’Alliance n’est pas la première à vouloir créer un tel runtime, mais elle va concentrer les efforts pour proposer des outils pensés d’emblée pour la sécurité. « WebAssembly change le web, mais nous pensons qu’il peut jouer un rôle plus grand dans l’écosystème logiciel alors qu’il continue de s’étendre hors des navigateurs », estime Luke Wagner, ingénieur chez Mozilla.

Pour démontrer son implication et aller plus loin qu’une simple annonce, l’Alliance fournit déjà plusieurs outils. Wasmtime est par exemple un runtime indépendant pouvant servir de CLI ou embarqué dans d’autres systèmes. Lucet est aussi un runtime, mais spécifique, davantage taillé pour les CDN (content delivery network) et centré sur la compilation AOT et autres techniques pour réduire la latence.

Les outils fournis sont tous open source et disposent de leur dépôt GitHub. L’Alliance fournira avec le temps d’autres projets, au fur et à mesure que ses activités se déploieront et que d’autres acteurs rejoindront la formation.

Les ambitions sont grandes, puisque le WebAssembly a dans l’absolu la capacité de devenir un très sérieux concurrent à des langages comme Java ou C#, avec à terme la possibilité d’un code unique capable de s’exécuter partout.

Ce qui explique d’ailleurs que d’importantes entreprises ne soient pas présentes dans cette Bytecode Alliance : Apple, Google et Microsoft. Avec Mozilla, elles étaient pourtant les quatre piliers du WebAssembly lors de sa présentation en juin 2015.

Pourquoi ? Parce que le langage sort du cadre « prévu » et pourrait venir mettre des bâtons dans les roues de ces sociétés. Microsoft a par exemple sa propre approche du multiplateforme open source avec son .NET Core, même si ce dernier vise plus volontiers les environnements serveur pour l’instant.

Google ne jure que par les technologies classiques du web et pousse largement Kotlin pour le développement des applications mobiles sur Android. Quant à Apple, WebAssembly vient se heurter à ses investissements dans son propre langage Swift, lui aussi open source.

Si l’Alliance réussit son pari, les outils nécessaires au développement d’applications pour ces plateformes arriveront cependant vite. 

Le 13 novembre 2019 à 09h14

Commentaires (14)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Une brève intéressante, mais qui mérite relecture…



Comme signalé avec l’outil, c’est Kotlin* et pas Kotlyn.



Aussi, il faut corriger la phrase « Quant à Apple*, WebAssembly vient se heurter à ses investissements dans son propre langage Swift » (Apple et pas Google).



Enfin, le WebAssembly ne concurrence pas le Java ou  le C#, mais plutôt leurs plateformes de développement. Personne ne veut coder en WebAssembly.



D’ailleurs, y en a-t-il ici qui utilise WebAssembly  dans leur travail ? Je ne vois pas souvent passer d’actualités sur le sujet.



Et avant de concurrencer sérieusement les environnements Java/Kotlin ou C#, il va falloir se doter d’une large bibliothèque d’outils. Quelqu’un sait si cette alliance peut se baser sur les bibliothèques prévues pour javascript ?

votre avatar







tnetennba a écrit :



Comme signalé avec l’outil, c’est Kotlin* et pas Kotlyn.



Aussi, il faut corriger la phrase « Quant à Apple*, WebAssembly vient se heurter à ses investissements dans son propre langage Swift » (Apple et pas Google).







Tu sais, l’intérêt de faire des signalements est justement de ne pas faire de commentaires dessus qui n’ont aucun intérêt sur la pertinence de l’article ou du débat sur le sujet.



idem pour @RN


votre avatar

Faux.



Parce que l’outil de signalement est bogué, donc je n’ai aucune garantie que les erreurs seront corrigées juste en les signalant de cette façon. Déjà vécu.



Je l’utilise quand même pour anticiper les petits malins qui disent ensuite « il y a le bouton Signaler pour cela ».

votre avatar

J’ai l’impression que c’est toi le petit malin <img data-src=" />

votre avatar

Faux quoi ?

Faux il faut montrer qu’on a vu l’erreur et il faut la pointer du doigt c’est indispensable au débat ? J’ai des doutes, tes questions (auxquelles je n’ai pas pas réponse) sont bien plus intéressante que de pointer du doigt que Kotlin ne prend pas de Y …



Et pour l’outil de signalement, je dois avoir un canal privilégié alors, j’ai toujours une réponse de Vincent quand je signale une erreur (qui doit en avoir marre de moi soit dit au passage :p )…



Bref… au final on pollue le thread, ce qui est effectivement ce qu’il faut éviter de faire juste pour des raisons qui n’ont rien à voir avec le fond de l’article.

votre avatar

J’ai toujours remonté les erreurs sur les articles via le bouton de signalement, très souvent reçu un petit remerciement pour le signalement dans l’heure.



Moi ce que je me demande surtout par rapport au web assembly c’est qu’es ce que ça pourrait donner en face de Node/Typescript pour ceux qui souhaitent faire du JS en backend et qui petit à petit s’installe au niveau des entreprises et ça fonctionne plutôt pas mal.



Pour moi le WebAssembly c’est qu’un autre runtime multiplateforme au même titre que Java Runtime/.Net Core…

A voir ce que ça donne, si ça prend bien. Il est basé sur des languages différent des autres, a voir si c’est suffisant pour pousser l’adoption (quoi que je doute que des programmeurs C++ abandonnent leur programmes compilé en langage machine pour passer par un bytecode intermédiaire).

votre avatar

J’avoue que le WebAssembly en backend j’ai encore du mal à voir l’intérêt (l’argument “une seule runtime partout” ne me paraît pas très intéressant) , par contre dans le navigateur oui ; donc je le vois plus volontiers en concurrence avec le runtime JS (qui est pété dans tous les sens). Par contre si Apple/Google/Microsoft ne suivent pas, ça risque d’être un gros problème.



Et les languages comme TypeScript qui “transpilent” en JS pourront très bien également “transpiler” en wasm d’ailleurs il y a déjà un certains nombre de projets sur les rails pour ça. Cfhttps://docs.assemblyscript.org/ par exemple.

votre avatar

Le but de WebAssembly hors du web n’est pas d’avoir un “runtime partout”. De toute façon, le runtime du navigateur et celui d’une l’application lourde seront de toute façon différents, et chaque module peut de toute façon être écrit dans un langage différent.



L’annonce originale explique longuement les intérêt de la démarche. Le principal est de fournir une isolation entre les différent des composants de l’application, un peu comme des containers en beaucoup plus léger.&nbsp; Cela permettrait de réduire les risque de faille de sécurité par import de module depuis un dépot de style npm vu que chaque module aurait une restriction des droit qui lui sont accordé (accès au fichiers, aux réseaux, à la mémoire …)

votre avatar







jotak a écrit :





. Par contre si Apple/Google/Microsoft ne suivent pas, ça risque d’être un gros problème.&nbsp;

Ms a par exemple les applis blazor pour générer du WASM côté client et avoir une appli “client riche” sous navigateur web.

D’ailleurs, la doc est auto-traduite, ce qui rend blazor “éblouissant”&nbsp;doc du serveur éblouissant (me rappelant une démo Azure dont on pouvait automatiser la config grâce à “coquillage puissant”&nbsp;<img data-src=" /> )



Sinon, les démo un peu évoluées de Webassembly restent souvent sur un magnifique “loading, please wait…” infini.



N’oublions pas l’article selon lequel + de 50% des utilisation de webassembly servent surtout à ce que l’utilisateur ne puisse pas savoir ce qui se passe…

&nbsp;

Bref, pas convaincu pour le moment.


votre avatar







Uther a écrit :



L’annonce

originale explique longuement les intérêt de la démarche. Le principal

est de fournir une isolation entre les différent des composants de

l’application, un peu comme des containers en beaucoup plus léger.&nbsp; Cela

permettrait de réduire les risque de faille de sécurité par import de

module depuis un dépot de style npm vu que chaque module aurait une

restriction des droit qui lui sont accordé (accès au fichiers, aux

réseaux, à la mémoire …)





D’accord, je ne connaissais pas cet aspect.&nbsp; Mais là encore ça me paraît plus indiqué pour palier aux déficiences de l’écosystème JS que des languages backend (sauf node.js du coup). Même si en théorie une lib malicieuse dans n’importe quel language peut faire des dégâts, allez savoir pourquoi, j’ai l’impression que c’est surtout dans l’écosystème JS qu’on voit ces problèmes, non? Je me rappelle encore de celle-ci:https://snyk.io/blog/malicious-code-found-in-npm-package-event-stream/ qui avait fait pas mal parler.



&nbsp;





brice.wernet a écrit :



D’ailleurs, la doc est auto-traduite, ce qui rend blazor “éblouissant”&nbsp;doc du serveur éblouissant (me rappelant une démo Azure dont on pouvait automatiser la config grâce à “coquillage puissant”&nbsp;<img data-src=" /> )





&nbsp;<img data-src=" />


votre avatar







jotak a écrit :



Même si en théorie une lib malicieuse dans n’importe quel language peut faire des dégâts, allez savoir pourquoi, j’ai l’impression que c’est surtout dans l’écosystème JS qu’on voit ces problèmes, non?







C’est surtout (a mon avis) car l’écosystème JS est encore très “Jeune”, une nouvelle version dans une lib arrive très vite, d’autres librairie ne sont plus compatible, on doit en chercher une équivalente ou un “fix” d’un tiers si on est pas capable d’en assumer le développement (Fork github ect) qui du coup n’a pas forcément été fouillé ou testé, d’où la “facilité” a se retrouver avec des librairies vérolé.


votre avatar

Je ne comprends pas l’intéret de WebAssembly, les perfs de Javacsript sont déjà assez bonne (la preuve avec JS.node), quel est l’avantage à devoir compiler du code ?

Pour l’utilisateur c’est une compatibilité hasardeuse, et du code exécutable (compilé) donc potentiellement dangereux.


votre avatar







jotak a écrit :



D’accord, je ne connaissais pas cet aspect.&nbsp; Mais là encore ça me paraît plus indiqué pour palier aux déficiences de l’écosystème JS que des languages backend (sauf node.js du coup). Même si en théorie une lib malicieuse dans n’importe quel language peut faire des dégâts, allez savoir pourquoi, j’ai l’impression que c’est surtout dans l’écosystème JS qu’on voit ces problèmes, non? Je me rappelle encore de celle-ci:https://snyk.io/blog/malicious-code-found-in-npm-package-event-stream/ qui avait fait pas mal parler.





C’est un problème surtout connu en JS car node.js a démocratisé l’utilisation de dépendances et son énorme succès a attiré les convoitises des pirates, mais le problème est tout autant présent dans d’autre langage. Les faille qui découlent d’une dépendance compromise, volontairement(bibliothèque malicieuse) ou non (faille de sécurité), sont courantes dans tous les langages.

&nbsp;





fofo9012 a écrit :



Je ne comprends pas l’intéret de WebAssembly, les perfs de Javacsript sont déjà assez bonne (la preuve avec JS.node), quel est l’avantage à devoir compiler du code ?



Pour l'utilisateur c'est une compatibilité hasardeuse, et du code exécutable (compilé) donc potentiellement dangereux.







Les performances brutes de JavaScript sont clairement un cran en dessous de langages système comme le C, C++ ou Rust.

Node.js a des performances correctes tout simplement car ce qu’on lui demande est principalement contraint par le réseau, donc la puissance de calcul n’est pas un point limitant pour fournir une bonne expérience utilisateur. Mais tu vas consommer plus de ressources processeur et mémoire sur tes serveurs que si tu avais utilisé un langage système.



Au niveau compatibilté, la sécification de WebAssembly étant stricte et beaucoup plus simple que celle de JS, il n’y a pas de raison particulière de s’inquiéter.

&nbsp;&nbsp;

Au niveau sécurité, contrairement à ce que tu penses, le WebAssembly n’est pas un binaire directement exécutable mais un bytecode compilé et contrôlé par la VM. De plus il est exécuté dans un environnement contraint. Le but de la bytecode alliance est justement d’utiliser les particularités de WebAssembly pour fournir une meilleure sécurité.


votre avatar

Si les GA(FA)M n’y vont pas d’entrée, c’est compréhensible! Leur problème, c’est que si cela prends côté développeurs (il y a un moment ou devoir être polyglotte pour arroser toute plateforme, ça gave) ils vont devoir y aller. Et plus vite que le semblant de conversion de Microsoft au “cancer” open-source…

Avec la Bytecode Alliance, le WebAssembly va s’affranchir du seul web

Fermer