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 !
Avec la Bytecode Alliance, le WebAssembly va s’affranchir du seul webCrédits : SeventyFour/iStock

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. 

15 commentaires
Avatar de Overnumerousness INpactien
Avatar de OvernumerousnessOvernumerousness- 13/11/19 à 09:27:42

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 ?

Avatar de RN INpactien
Avatar de RNRN- 13/11/19 à 09:51:14
Édité par Vincent_H le 21/11/2019 à 10:40
Avatar de Toorist INpactien
Avatar de TooristToorist- 13/11/19 à 09:51:14

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

Édité par Toorist le 13/11/2019 à 09:51
Avatar de Overnumerousness INpactien
Avatar de OvernumerousnessOvernumerousness- 13/11/19 à 09:58:59

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

Avatar de sergekaramazov Abonné
Avatar de sergekaramazovsergekaramazov- 13/11/19 à 10:01:56

J'ai l'impression que c'est toi le petit malin :mdr:

Avatar de Toorist INpactien
Avatar de TooristToorist- 13/11/19 à 10:04:31

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.

Avatar de Paraplegix Abonné
Avatar de ParaplegixParaplegix- 13/11/19 à 10:23:44

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

Édité par Paraplegix le 13/11/2019 à 10:25
Avatar de jotak Abonné
Avatar de jotakjotak- 13/11/19 à 12:02:22

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.

Avatar de Uther Abonné
Avatar de UtherUther- 13/11/19 à 14:46:22

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

Édité par Uther le 13/11/2019 à 14:47
Avatar de brice.wernet Abonné
Avatar de brice.wernetbrice.wernet- 13/11/19 à 15:08:17

jotak a écrit :

. Par contre si Apple/Google/Microsoft ne suivent pas, ça risque d'être un gros problème. 
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" doc du serveur éblouissant (me rappelant une démo Azure dont on pouvait automatiser la config grâce à "coquillage puissant" :chinois: )

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...
 
Bref, pas convaincu pour le moment.

Il n'est plus possible de commenter cette actualité.
Page 1 / 2