État de WebAssembly en 2023: Rust est le langage le plus utilisé

Les utilisateurs veulent une meilleure intégration hors navigateur, les threads et le garbage collection sont en phase de finalisation

Le 19 octobre 2023 à 15:07, par Jade Emy

10PARTAGES

WebAssembly, abrégé wasm, est un standard du World Wide Web pour le développement d’applications. Il est conçu pour remplacer JavaScript avec des performances supérieures. Le standard consiste en un bytecode, sa représentation textuelle et un environnement d'exécution dans un bac à sable compatible avec JavaScript. Il peut être exécuté dans un navigateur Web et en dehors. WebAssembly est standardisé dans le cadre du World Wide Web Consortium.

L'enquête sur l'état de WebAssembly en 2023 est terminée, les résultats sont arrivés ... et ils sont fascinants ! Voici les grandes lignes :

L'utilisation de Rust et de JavaScript continue d'augmenter, mais des changements plus notables se produisent un peu plus bas - avec Swift et Zig qui voient une augmentation significative de l'adoption.
En ce qui concerne les langages que les développeurs "désirent", avec Zig, Kotlin et C#, on constate que le désir dépasse l'utilisation actuelle.
WebAssembly est encore le plus souvent utilisé pour le développement d'applications web, mais le serverless continue d'augmenter, tout comme l'utilisation de WebAssembly en tant qu'environnement plugin.
Les threads, le garbage collection et la relativement nouvelle proposition de modèle de composant sont les développements de WebAssembly qui intéressent le plus les gens.
En revanche, avec WASI, ce sont les propositions d'E/S (par exemple HTTP, système de fichiers) qui retiennent le plus l'attention.
Nous assistons potentiellement à une certaine impatience de la part de la communauté, la satisfaction à l'égard de l'évolution de WASI étant nettement inférieure à celle exprimée à l'égard de l'évolution de WebAssembly.
De nombreuses personnes interrogées ont indiqué qu'elles attendaient de WebAssembly qu'il tienne la promesse "écrire une fois et exécuter n'importe où" qui avait été faite à l'origine par Java.

Vous souhaitez en savoir plus ? Lisez la suite...

Langage

La première question explorait les langages utilisés par les utilisateurs en posant la question suivante : quels langages utilisez-vous, ou avez-vous essayé d'utiliser, lors du développement d'applications utilisant WebAssembly ?

Pour la troisième année consécutive, Rust est le langage le plus utilisé pour WebAssembly. Rust a toujours été un bon choix pour WebAssembly ; c'est un langage moderne de niveau système qui a une grande popularité (le Stack Overflow a révélé que c'est le langage le plus désiré sept années de suite), il se trouve aussi être un langage populaire pour créer des runtimes et des plates-formes WebAssembly.

JavaScript est le deuxième langage le plus utilisé, ce qui est assez remarquable si l'on considère qu'il n'est pas possible de compiler JavaScript en WebAssembly. Pour exécuter du code JavaScript, le moteur d'exécution est compilé en WebAssembly, et votre code s'exécute dans l'interpréteur hébergé par WebAssembly. Cette approche, qui peut sembler inefficace, est étonnamment pratique et de plus en plus populaire. Vous n'obtiendrez peut-être pas d'avantage en termes de vitesse, mais vous bénéficierez des avantages de WebAssembly en termes de sécurité et d'isolation.

Le graphique suivant montre les tendances à long terme, en comparant les résultats des trois dernières enquêtes, avec le pourcentage de personnes utilisant chaque langage (fréquemment ou parfois) - à l'exclusion de ceux dont le taux d'utilisation est inférieur à 10 %.

L'utilisation de Rust et de JavaScript augmente, mais des changements plus notables se produisent un peu plus loin. Swift et Zig ont tous deux connu une augmentation significative de leur adoption.

Swift est un ajout relativement récent à l'écosystème WebAssembly, qui a commencé il y a quelques années avec une demande de pull sur le repo Swift d'Apple pour ajouter une cible wasm. Cependant, malgré de nombreux commits sur plusieurs années, cette PR n'a pas été fusionnée. Il semble que la communauté ne soit pas découragée et qu'elle maintienne son propre fork.

Alors que Swift et Rust sont tous deux des langages assez récents (2014 et 2015 respectivement), Zig est encore plus jeune, ayant émergé en 2016, ce qui le rend un an plus vieux que WebAssembly (qui a eu sa première version MVP en 2017).

Cette année, une nouvelle question a été ajoutée à l'enquête : quelle est votre relation professionnelle avec WebAssembly ? Dans le but de séparer les réponses des personnes qui développent activement des outils ou des plateformes WebAssembly de celles qui sont simplement des utilisateurs finaux. En séparant ces deux groupes, nous constatons les préférences linguistiques suivantes :

Comme prévu, les développeurs d'outils ont une forte préférence pour Rust, et aiment également programmer WebAssembly directement en utilisant WAT (WebAssembly Text Format). Il y a également une forte préférence pour Go et Python.

La question suivante de l'enquête explorait le degré d'intérêt de chaque langage en posant la question suivante : quels langages souhaitez-vous utiliser à l'avenir pour développer des applications qui utilisent WebAssembly ?

Une fois de plus, Rust arrive en tête, reflétant les résultats de l'enquête annuelle de Stack Overflow, avec JavasScript en deuxième position. Cependant, Zig, qui n'est pas souvent utilisé, est le troisième langage le plus désiré.

En traçant le delta pour chaque langage, entre le nombre de réponses "fréquemment utilisé" et "vouloir utiliser beaucoup", pour la désirabilité, nous pouvons voir quels sont les langages qui ont la plus grande différence entre la désirabilité et l'utilisation :

À une extrémité du spectre, Zig, Kotlin et C#, nous voyons que la désirabilité dépasse l'utilisation actuelle, tandis qu'à l'autre extrémité, les gens préféreraient utiliser moins de C++, JavaScript et WAT.

Temps d'exécution

Etant donné que l'utilisation de WebAssembly en dehors des navigateurs est en augmentation, il est intéressant d'explorer quels sont les moteurs d'exécution que les gens utilisent, ou dont ils sont simplement conscients, l'enquête demandait simplement quels étaient ceux dont vous avez entendu parler ou que vous avez utilisés ?

wasmtime, de Bytecode Alliance, est le plus utilisé, suivi de wasmer, développé par une start-up. Wazero est un nouvel ajout à la liste, un moteur d'exécution récemment publié et construit en Go.

Applications pratiques de WebAssembly

L'enquête demandait quelles étaient les applications pratiques de WebAssembly en ce moment ?, en permettant aux personnes de sélectionner plusieurs options et d'ajouter leurs propres suggestions. Voici toutes les réponses, la catégorie "Autre" comprenant toutes les réponses uniques :

Le développement d'applications web est toujours en tête, mais l'écart se réduit. Le graphique suivant montre les tendances d'une année sur l'autre :

Les applications sans serveur continuent de se développer, mais l'évolution la plus notable est sans doute l'utilisation de WebAssembly en tant qu'environnement d'extension. Voici quelques exemples concrets :

Zellij est un espace de travail terminal axé sur le développement qui dispose d'un modèle de plugin WebAssembly.
Microsoft Flight Simulator vous permet d'écrire des modules complémentaires sous forme de modules Wasm.
Envoy et Istio ont une API de plugin Wasm
Lapce, un nouvel IDE écrit en Rust, dispose d'un système de plugins basé sur WASI.

Dans chaque cas, la plateforme (terminal, éditeur, simulateur de vol, proxy) bénéficie du fait que les utilisateurs finaux peuvent étendre les fonctionnalités, en utilisant un large éventail de langages de programmation, dans un environnement sûr et isolé. En d'autres termes, si quelqu'un écrit un plugin qui se comporte mal, ou qui a simplement de mauvaises performances, l'impact sur la plateforme elle-même est minimisé.

On a également demandé aux personnes interrogées quel était l'état d'avancement de l'adoption de WebAssembly au sein de leur organisation ?

Le graphique ci-dessus montre que 41 % des personnes interrogées utilisent WebAssembly en production, et que 28 % d'entre elles le pilotent ou prévoient de l'utiliser au cours de l'année à venir.

L'enquête s'est également penchée sur les besoins de WebAssembly pour favoriser son adoption :

Le "besoin" le plus fréquemment cité était une meilleure intégration hors navigateur, par le biais de l'interface WASI (WebAssembly System Interface). La spécification WebAssembly ne définit aucun point d'intégration hôte, qu'il s'agisse de la manière d'accéder au DOM ou d'échanger des données avec le système d'exécution hôte (par exemple, transmettre des valeurs à JavaScript dans le navigateur). WASI comble cette lacune, mais n'apporte pas encore de réponse complète.

Un meilleur support de débogage est tout proche, et deviendra de plus en plus important au fur et à mesure que les gens développeront des solutions plus complexes avec WebAssembly. Pour une bonne vue d'ensemble des options, consultez cet article de blog de l'équipe Shopify.

Fonctionnalités, fonctionnalités, fonctionnalités

WebAssembly (géré par le W3C) et WASI (géré par une sous-organisation du groupe communautaire WebAssembly du W3C) sont tous deux en constante évolution, avec un arriéré de nouvelles fonctionnalités qui suivent le processus standard de proposition en 5 phases.

En ce qui concerne les propositions de WebAssembly, voici celles qui sont les plus demandées :

Les threads, le garbage collection et la gestion des exceptions figuraient tous en tête des résultats de l'année dernière, et tous trois sont en phase d'implémentation (phase 3) ou de normalisation (phase 4) dans le cycle de vie de la proposition. Cela signifie qu'ils sont prêts à être utilisés et proches de la finalisation.

Le modèle de composant est une proposition beaucoup plus précoce (phase 1), dont l'ambition est de faciliter la composition de modules wasm, écrits dans n'importe quel langage, au moment de l'exécution. Si les détails vous intéressent, je vous recommande cette vidéo de Luge Wagner, qui dirige la proposition.

En ce qui concerne les propositions WASI, voici celles qui sont les plus souhaitées :

Les quatre propositions les plus importantes sont toutes liées aux E/S, tout simplement parce que la création d'un moyen standard pour les modules WebAssembly de communiquer avec le monde extérieur est une priorité.

Enfin, nous avons demandé aux participants s'ils étaient satisfaits de l'évolution de WebAssembly et de WASI : Un grand nombre de personnes ne sont pas satisfaites ! Ce n'est pas du tout surprenant, car il n'est pas facile et il faut du temps pour faire évoluer de manière ouverte et transparente des spécifications qui intéressent un si grand nombre de parties prenantes. Ce qui est probablement plus remarquable, c'est que, d'une manière générale, les gens sont moins satisfaits de l'évolution de la WASI.

On peut souligner un point important : ce résultat ne doit pas être utilisé comme une critique directe des efforts fantastiques déployés par les groupes WASI et WebAssembly. Le manque de satisfaction quant à l'évolution de WASI pourrait simplement être le reflet de l'enthousiasme des gens pour cette technologie, ce qui n'est pas une mauvaise chose.

Au début de l'année, Wasmer a annoncé WASIX, sa tentative d'accélérer WASI (ou les concepts qu'il représente), qui a reçu un accueil mitigé.

Et enfin

On a demandé aux gens quelle était la chose qui les enthousiasmait le plus à propos de WebAssembly ? Près de la moitié des personnes interrogées ont fait part de leurs réflexions. Voici un résumé par ChatGPT des thèmes principaux :

La portabilité et la possibilité d'exécuter le code sur différentes plates-formes
Interopérabilité entre différents langages et le web
Performance et efficacité natives
Accès au code et aux bibliothèques existants
Le potentiel de nouveaux langages et outils
Sécurité et capacités de sandboxing
la possibilité de remplacer les conteneurs et d'exécuter des piles complexes dans le navigateur
la possibilité d'un format binaire universel
La possibilité d'écrire une fois et d'exécuter n'importe où
Amélioration des performances et de la vitesse
Le modèle des composants et la possibilité de réutiliser le code
la réduction ou l'élimination de la dépendance à l'égard de JavaScript
Plus de flexibilité et de choix dans la sélection du langage
la possibilité d'un système de modules d'extension (plugins)
Possibilité d'exécuter des applications complexes dans le navigateur