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.
Commentaires (15)
#1
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 ?
#2
#3
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 ».
#4
J’ai l’impression que c’est toi le petit malin
" />
#5
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.
#6
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).
#7
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.
#8
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. 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 …)
#9
#10
#11
#12
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.
#13
#14
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…