Pourquoi les frameworks WebAssembly sont l’avenir du Web –

WebAssembly est une nouvelle façon d’exécuter du code sur le Web. Avec d’énormes entreprises de technologie derrière elle, il est sur le point de révolutionner la façon dont nous écrivons des applications Web, mais présente ses propres bizarreries et limites. Les frameworks WASM sont-ils un concurrent viable des bibliothèques JavaScript comme React ?

Qu’est-ce que WebAssembly ?

WebAssembly, ou WASM, est le deuxième langage de programmation universel que tous les navigateurs Web peuvent comprendre et exécuter. Cependant, vous n’allez pas écrire vous-même des scripts dans WebAssembly – c’est un langage d’assemblage de bas niveau, conçu pour être très proche du code machine compilé et très proche des performances natives.

La magie de WebAssembly est qu’il est suffisamment bas pour qu’il s’agisse en fait d’un cible de compilation. Tout langage raisonnablement rapide doit passer par un compilateur à un moment donné, même les langages compilés JIT comme JavaScript, et cela signifie généralement la compilation en code machine x86 ou ARM pour s’exécuter sur des processeurs modernes.

Cependant, vous pouvez également compiler dans un format différent ; généralement, cela finit par être un langage de «niveau inférieur» qui est plus proche du code machine éventuel. Par exemple, Java compile en bytecode Java qui est envoyé au runtime JVM, et C# compile en Microsoft Intermediary Language (MSIL) qui est envoyé au runtime .NET. Vous pouvez même « transpiler » des langages, d’un langage de haut niveau à un autre, le plus souvent des extensions comme TypeScript vers JavaScript, mais aussi d’autres plus étranges auxquelles vous ne vous attendriez pas, comme Python vers JavaScript, bien que cela soit généralement désordonné et bourré de bugs.

WASM n’est qu’un langage intermédiaire facile à compiler. En fait, c’est presque exactement le même concept que le bytecode Java et C# MSIL. Ces deux formats facilitent l’exécution du même code sur plusieurs plates-formes, en utilisant le même format exécuté sur des environnements d’exécution spécifiques conçus pour chaque plate-forme.

Cela signifie en pratique que JavaScript n’est plus le seul langage que vous pouvez exécuter sur le Web. Les navigateurs Web peuvent désormais exécuter n’importe quel langage, si ce langage dispose d’un compilateur WebAssembly.

Même les langages de bureau traditionnels comme C++ et Rust peuvent être compilés en WASM avec une relative facilité ; AutoDesk a pu porter sa base de code C/C++ vieille de 35 ans sur WASM en quelques mois, et Google a porté Google Earth, tous deux restituant des scènes 3D complexes et fonctionnant à des performances quasi natives. Le moteur de jeu Unity peut également fonctionner dans WASM.

WASM fonctionne actuellement dans 94% des navigateurs d’utilisateurs, avec la prise en charge d’IE, du navigateur UC et d’Opera Mini étant les principaux éléments qui le freinent, comme d’habitude. Cependant, il est soutenu par des développeurs de Mozilla, Microsoft, Google et Apple, et sa prise en charge dans les navigateurs modernes évolue rapidement. Comme la plupart des normes Web, il est actuellement géré par l’organisation de normalisation W3C.

JavaScript n’est plus la seule option

Super, alors qu’est-ce que cela signifie pour tout le monde ? Eh bien, bien que l’exécution de DOOM 3 dans un navigateur Web soit certainement une démo intéressante, cela ne change pas vraiment la donne.

Jusqu’à présent, JavaScript était votre seul choix pour rendre vos pages Web interactives. Que vous l’aimiez ou que vous le détestiez, il n’a jamais été conçu pour être utilisé comme il l’est aujourd’hui. Il s’agissait d’un langage de script conçu pour effectuer des tâches triviales telles que l’animation de menus déroulants, et il a été piraté pendant plus de 25 ans pour exécuter des charges de travail modernes. Ce n’est que grâce à l’utilisation de moteurs JS de pointe et d’optimisations de compilation JIT qu’il peut même être comparé aux vitesses natives.

Et ainsi, à mesure que les pages Web devenaient des applications Web complètes, les infrastructures clientes JavaScript telles que React, Vue et Angular se sont développées pour répondre à la demande. Bien sûr, il existe toujours des frameworks côté serveur – vous lisez ceci à partir de WordPress, un framework PHP – mais les frameworks clients offrent d’énormes augmentations de performances. Avec un framework client, le DOM est mis à jour automatiquement après avoir appuyé sur un bouton ou interagi avec l’application. Même les frameworks rendus par le serveur en temps réel doivent faire une demande réseau pour changer quoi que ce soit, et dans le pire des cas, doivent actualiser la page entière.

L’innovation dont le Web a vraiment besoin est de véritables concurrents de frameworks comme React, écrits dans des langages qui ne sont pas JavaScript.

Alors que tout le code frontend du Web est écrit en JavaScript, le code backend ne l’est souvent pas. Dans les charges de travail de centre de données hautes performances, il est souvent avantageux d’utiliser des langages de bureau appropriés tels que C#, C++, Rust et Go. Après tout, ceux-ci peuvent littéralement vous faire économiser de l’argent en nécessitant moins de serveurs pour répondre à la même demande.

Cependant, cela vous coûte également de l’argent en temps de développement, car vous devez maintenant gérer l’interopérabilité entre votre backend C# et votre frontend JavaScript. Le simple fait de ne pas pouvoir partager le code, les modèles et les bibliothèques peut augmenter la complexité de votre développement jusqu’à 2 fois ce qu’elle serait avec un système unifié. Cette seule raison est la raison pour laquelle les backends de serveur NodeJS sont si populaires, même s’ils sonnaient comme une idée terrible il y a 20 ans.

Avoir la possibilité d’écrire du code C#, C++, Rust et Go qui s’exécute sur le serveur et cliente ouvrirait la porte à de nombreuses autres options et supprimerait presque entièrement le besoin de JavaScript en tant que langage de programmation. Dans le framework client WASM Blazor, l’utilisation de JavaScript est réservée à l’interopérabilité avec les packages clients existants et aux scripts de base.

Comment fonctionnent les frameworks client WASM ?

Étant donné que WebAssembly n’est qu’un moyen d’exécuter du code dans une sorte d’« environnement WebAssembly », vous pouvez le considérer comme l’exécution d’un conteneur Docker. Par exemple, le framework Blazor de Microsoft (de loin le framework client WASM le plus populaire à ce jour) a deux modes de fonctionnement :

• Blazor Server, qui exécute tout le traitement et le rendu sur le serveur, et envoie des mises à jour au DOM HTML via un WebSocket, et
• Blazor WebAssembly, qui fait exactement la même chose, sauf que maintenant le traitement et le rendu sont effectués sur le client, via un runtime .NET compilé pour WASM.

Dans ce dernier cas, la connexion WebSocket est remplacée par un lien direct vers le DOM, via JavaScript car WebAssembly n’a actuellement aucun moyen de modifier le DOM directement sans appeler les API JS. Dans tous les cas, vous avez également besoin de JavaScript pour « amorcer » l’application WASM, afin que JS ne disparaisse pas de sitôt.

Au-delà de cela, les frameworks client WASM fonctionnent en général comme tout autre framework, et les détails exacts dépendront de l’implémentation.

Par exemple, Blazor conserve un état interne et déclenche un nouveau rendu de l’application lorsqu’un bouton est cliqué ou qu’une saisie est effectuée. Il construit un nouveau code HTML à l’aide du code C# exécuté sur WASM, puis envoie ce code HTML aux API JavaScript pour l’appliquer au DOM. Faire cela sur WebAssembly enlève la charge de traitement du serveur et rend le client rapide et réactif. Même l’accès DOM via JavaScript est un peu plus lent, il est toujours plus rapide que l’alternative – l’accès DOM sur Internet.

Combien plus vite parlons-nous?

La question « à quel point WASM est-il plus rapide ? » est difficile à cerner. C’est clairement plus rapide dans l’ensemble, cela ne fait aucun doute, mais dans certains cas, c’est plus compliqué que cela.

L’accès au DOM est toujours un problème car il doit être effectué via JavaScript, il sera donc aussi lent que JavaScript. Cependant, cela sera bientôt corrigé. Parfois, JavaScript peut être plus rapide dans des benchmarks spécifiques avec lesquels le compilateur WASM peut avoir du mal, simplement en raison du fait que JS a 25 ans d’itération du compilateur derrière lui.

Pour les applications hautes performances nécessitant beaucoup de puissance de traitement, comme les jeux et les applications, WASM est généralement de 1,5 à 2 fois plus rapide. Mais c’est peut-être la même vitesse. Il peut également être 20% plus lent que JavaScript. Il peut également être 10 fois plus rapide pour certaines fonctions. Il existe des références montrant tous ces résultats, donc la seule chose que l’on puisse dire avec certitude est que votre kilométrage variera.

Par rapport au code natif, il est susceptible d’être toujours plus lent que le langage à partir duquel il est compilé. Ainsi, même si cela va probablement être rapide, il y a beaucoup de mises en garde, et vous ne devriez pas utiliser WASM dans l’espoir d’obtenir des performances natives sur le Web.

Cela étant dit, WASM n’a pas besoin de performances folles pour être révolutionnaire. Il doit juste fonctionner, ne pas être lent et prendre en charge de nombreuses langues.

Quels frameworks fonctionnent actuellement ?

Le plus important est de loin Blazor, développé par Microsoft. C’est le premier framework client WASM soutenu par une grande entreprise, et sera probablement le catalyseur pour que WASM obtienne enfin l’adoption grand public qu’il mérite.

Blazor WASM n’a qu’un an, avec Blazor Server sorti il ​​y a 3 ans, mais ce qui est bien avec Blazor, c’est qu’il ne s’agit que d’une extension d’ASP.NET, un framework Web vieux de 20 ans que Microsoft améliore constamment. Vous pouvez utiliser de nombreuses bibliothèques frontales déjà écrites pour ASP.NET, et ce sera probablement le seul framework soutenu par un gestionnaire de packages Web rivalisant avec NPM.

Ce n’est pas non plus un projet parallèle : Microsoft a poussé Blazor bien plus qu’un simple framework Web ; c’est leur prochain modèle de programmation d’applications. Ils travaillent sur Blazor Desktop, sorti fin 2021, qui fonctionne un peu comme Electron pour exécuter les mêmes applications Web Blazor sur le bureau. Ils s’en soucient clairement beaucoup, ce qui est une excellente nouvelle pour WASM en général.

Si vous souhaitez en savoir plus, vous pouvez lire nos guides sur ce qu’est Blazor et comment commencer à l’utiliser.

L’autre framework prêt pour la production est Yew, construit sur Rust, un langage moderne similaire au C++, sauf avec la sécurité de la mémoire en raison de la façon étrange dont il gère les références. Yew est rapide, prend en charge un modèle basé sur des composants comme React et est interopérable avec les API JS.

asm-dom est une bibliothèque écrite pour C++, qui ne fait que connecter du code C++ au DOM. Évidemment, vous devrez apporter votre propre framework ici, mais la plupart des développeurs assez fous pour écrire des applications Web en C++ le feront probablement de toute façon. Il prend également en charge le retour à asm.js, une première version de ce que WebAssembly essayait d’être. Il s’agit essentiellement d’un sous-ensemble de JavaScript limité à l’utilisation d’entiers (c’est-à-dire uniquement d’octets, pas d’objets), ce qui facilite la transpilation du code C++, car c’est essentiellement tout le code C++ utilisé à la fin de la journée. Avoir ce support n’est pas très utile car il y a très peu d’environnements qui ne prendront pas en charge WASM mais prendront en charge asm.js.

Vugu est un framework écrit en Go, prend en charge les composants et est calqué sur la syntaxe Vue, mais reste expérimental. Il y a aussi Vecty, qui est également un framework Go populaire.

L’avenir du WebAssembly

Tout cela s’est concentré sur les frameworks Web clients utilisant WASM pour manipuler le DOM et créer des applications. Mais, vous pouvez également simplement porter des applications de bureau entières sur le Web. C’est ce que fait Uno : utilise WASM pour exécuter des applications de plateforme Windows universelle (UWP) directement dans un conteneur Web, ce qui présente également l’avantage supplémentaire d’être complètement multiplateforme. C’est en fait un peu étrange à quel point cela fonctionne bien, et on a vraiment l’impression d’utiliser une application Windows native. Vous pouvez le vérifier vous-même dans leur galerie.

L’écosystème WASM est bien plus que cela. Si vous souhaitez en savoir plus, vous devriez lire la compilation awesome-wasm sur GitHub, qui répertorie un tas de projets populaires.

Le plus notable que nous n’avons pas mentionné ici est WASI, un moyen d’exécuter WebAssembly de manière portable sur n’importe quel système à l’aide d’une interface système standardisée. Alors que WASM devient de plus en plus performant, WASI pourrait s’avérer être un moyen viable d’exécuter n’importe quel type de code sur n’importe quel type de système, de la même manière que Docker fonctionne mais sans restriction sur le système d’exploitation. En fait, Solomon Hykes, le créateur de Docker, l’a approuvé sans réserve :

Si WASM+WASI avait existé en 2008, nous n’aurions pas eu besoin de créer Docker. C’est à quel point c’est important. L’assemblage Web sur le serveur est l’avenir de l’informatique. Une interface système standardisée était le chaînon manquant. Espérons que WASI soit à la hauteur ! https://t.co/wnXQg4kwa4

– Salomon Hykes (@solomonstre) 27 mars 2019

WebAssembly n’a que quelques années. Il a encore beaucoup de place pour grandir et continue de prendre de la vitesse. Il n’est pas déraisonnable que dans cinq ans, des frameworks comme Blazor et Yew soient aussi courants que React, Angular et Vue.

Cela pourrait être considéré comme une fragmentation de l’écosystème Web, mais WASM est multiplateforme. WAPM, un gestionnaire de packages WASM, peut devenir le moyen idéal pour partager des bibliothèques entre des frameworks de différents langages.

Dans tous les cas, les frameworks Web fonctionnant sur WebAssembly ont un potentiel énorme, et avec le soutien personnel de Microsoft, nous sommes convaincus qu’ils sont l’avenir du Web.