Aperçu de WebAssembly

WebAssembly ouvre le terrain de jeu en permettant à toutes les langues disposant du bon outillage – pas seulement de JavaScript – d'être exécutées dans le navigateur. Voyez pourquoi c'est quelque chose que vous devriez commencer à explorer.

Qu'est-ce que WebAssembly?

WebAssembly est l'un de ces mots à la mode qui commence à faire son chemin. Avant de conclure que c’est l’un de ces sujets à la mode qu'il faut ignorer – ou que cela va changer votre vie – nous allons expliquer exactement ce que c'est, ce que ce n'est pas et pourquoi vous devriez commencer être excité à ce sujet. Pour commencer, nous allons commencer par la définition formelle de webassembly.org :

WebAssembly (abrégé en Wasm) est un format d'instruction binaire pour une machine virtuelle à pile. Il est conçu comme une cible portable pour la compilation de langages de haut niveau tels que C / C ++ / Rust, permettant un déploiement sur le Web pour les applications client et serveur.

En pratique, la meilleure façon de penser à WebAssembly est qu'il s'agisse d'un package. format pour le code qui a été compilé dans un format portable qui peut être utilisé par le code frontal ou principal. À l'heure actuelle, quelques compilateurs peuvent transformer votre code de langage de choix en WebAssembly.

La partie vraiment intéressante de tout cela est, si vous pensez que JavaScript est le langage des navigateurs Web, WebAssembly s'ouvre. place le champ de jeu et permet à n'importe quel langage (avec le bon outillage) d'être exécuté dans le navigateur Web.

Reasons to Be Excited

Le véritable avantage provient de la capacité de WebAssembly à effectuer une compilation en streaming. Comme il a été conçu pour le Web, il peut commencer à compiler dès que les données sont reçues sur le client sans attendre la totalité du fichier. Il s'agit d'une amélioration significative par rapport au fonctionnement de JavaScript, qui doit attendre que le fichier entier soit reçu avant de commencer. Au fur et à mesure que la taille de votre fichier JavaScript augmente, la page ralentit de deux manières: plus le téléchargement du fichier est long, plus il est long que le fichier JavaScript doit être analysé, ce qui augmente le temps de First Meaningful Paint (FMP). La compilation en streaming vous permet de contourner ces deux pièges traditionnels de JavaScript. La capacité de diffusion en continu de WebAssemby est un énorme changeur de jeu pour les temps de peinture des pages et le temps nécessaire pour les interactions. La page restituée s'affiche alors que le téléchargement du fichier est en cours.

WebAssembly est ouvert à tous les langages pouvant être compilés jusqu'à l'assembly partagé, ce qui peut ouvrir la porte à la réutilisation de code entre les services frontend et backend. bases de code. La possibilité d’avoir une seule langue pour le front-end et le back-end était jadis l’un des grands piliers de Node, qui peut être ouvert à toutes les langues. Bien sûr, cela dépend fortement de l’outillage permettant de compiler les langues jusqu’à WebAssembly (par exemple, Blazor Yew ).

En plus du partage de code entre les équipes, WebAssembly. partage l'espace mémoire avec le moteur JavaScript pour permettre l'exportation / l'importation de fonctions dans les bases de code. Cela semble être une note de côté, mais c'est énorme . Je pense que cela permettra une plus grande adoption car le code peut être migré un peu à la fois sans effectuer de changement important au sein de l'équipe.

Pièges potentiels

Comme pour toute bonne technologie, il convient de garder à l'esprit certains compromis. lorsque vous commencez à l'intégrer à votre pile technologique.

L'une des principales fonctionnalités de WebAssembly est sa performance. Bien que les performances globales tendent à être plus rapides que JavaScript, la comparaison fonction à fonction montre que JavaScript est toujours comparable dans certains tests de performance, de sorte que votre kilométrage peut varier. Lors de la comparaison du temps d'exécution d'une fonction, il est prévu que WebAssembly sera environ 20-30% plus rapide que JavaScript, ce qui n'est pas aussi impressionnant que cela puisse paraître, car JavaScript est fortement optimisé. À l'heure actuelle, les performances de WebAssembly en matière de performances sont à peu près égales, voire un peu moins bonnes que JavaScript, ce qui a permis de réduire à néant mes espoirs dans ce domaine.

WebAssembly étant une technologie relativement nouvelle, quelques exploits de sécurité sont probablement attendus. être trouvé. Par exemple, il existe déjà des articles sur l'exploitation de la vérification de type et du flux de contrôle dans WebAssembly. De plus, WebAssembly s'exécutant dans un bac à sable, il était sujet aux exploits du processeur Spectre et Meltdown mais il a été atténué par certains correctifs de navigateur. De nouveaux exploits apparaîtront à l'avenir.

De même, si vous prenez en charge des clients d'entreprise utilisant IE ou d'autres navigateurs plus anciens, vous devez vous éloigner de WebAssembly. Il n'est toujours pas pris en charge dans IE. Certains travaux préliminaires sur les polyfills visant à combler cette lacune dans IE et les anciens navigateurs pour accélérer l'adoption, ont été ralentis en raison de l'adoption rapide par les navigateurs de la norme existante.

Une autre chose à garder à l'esprit est que WebAssembly est toujours le code client, vous devez donc le garder en sécurité et le désinfecter. Bien que compilé, vous devez éviter de placer des secrets de serveur ou d’utilisateur à l’intérieur de WebAssembly.

Bon point de départ

Si vous vous demandez où et comment commencer à utiliser WebAssembly dans votre application Web actuelle, Trois zones de votre système qui constitueraient d'excellents points de départ.

La première zone concerne la surface comprise entre votre code frontal et votre code arrière. C’est une excellente occasion de scinder tout code partagé dans sa propre bibliothèque pour qu’il soit hébergé en tant que .wasm sur votre CDN ou utilisé dans votre processus backend. Pour certaines applications React / Angular, il est assez courant d’avoir un code partagé entre le front-end et le back-end. Pour les applications de commerce électronique, la tarification est toujours calculée deux fois, une fois pour le client en tant qu'aperçu et une seconde fois par le serveur pour vérifier que la tarification correspond à ce que l'utilisateur a vu sur le client. Idéalement, ce code serait écrit une seule fois et ne serait utilisé que lorsque le langage le nécessiterait, ce qui en ferait un excellent candidat pour WebAssembly.

Le deuxième point de départ serait le point de départ d’un nouveau regard sur un projet existant. Par exemple, en tant que développeur .NET, si vous souhaitez progresser vers une application d'une page (SPA) sans reformer votre équipe sur Angular ou React, vous pouvez commencer à utiliser WebAssembly pour vous aider à atteindre cet objectif. via le framework Blazor. Imaginez créer un SPA avec tous les modèles et outils de .NET avec tous les avantages d'une page hébergée de manière statique en tant que produit final.

Pour le troisième domaine, démarrez de nouveaux projets Web axés sur la manipulation d'images, la visualisation de données ou tout ce qui est hautement interactif (jeux, graphiques), il est intéressant de commencer par WebAssembly. Unity pousse WebAssembly à devenir le groupe par défaut pour ses clients en raison de ses performances (démarrage et exécution), et il n'y a aucune raison pour que vous ne le fassiez pas aussi bien.

Enveloppant

Alors, si vous abandonnez tout ce que vous êtes faire aujourd'hui et commencer la migration vers WebAssembly? Non pas encore. Certaines personnes envisagent d'utiliser WebAssembly avec certains de nos frameworks frontend préférés au moment où nous parlons, et c'est là que vous constaterez le plus grand gain de performances dans un proche avenir. C'est à ce moment-là que je vais commencer à être enthousiasmé par WebAssembly.

Est-ce quelque chose que vous devriez commencer à explorer? Absolument. Je pense que WebAssembly donnera aux applications Web un gain de performances supérieur à celui de la micro-optimisation des tailles de bundles. De plus, cela pourrait même donner à la concurrence du rendu côté serveur (SSR) le moyen de servir les pages plus rapidement.

Resté à l'écoute. Je suppose que nous en apprendrons davantage sur WebAssembly et sur les améliorations apportées à ses fonctionnalités bientôt.