En bref, oui.
WebAssembly (Wasm) est devenu une technologie dominante qui a pris d'assaut le développement Web. Des premières démos techniques, comme le jeu populaire Doom fonctionnant entièrement dans le navigateur , aux grandes applications héritées comme Photoshop offrant une expérience complète de type bureau sur une page Web classique, WebAssembly offre des expériences complètement nouvelles dans un programme familier déjà installé sur chaque ordinateur personnel dans le monde.
Wasm a été conçu pour permettre à presque tous les langages de programmation de le prendre en charge, quel que soit le type de processeur de l'ordinateur de l'utilisateur, et il possède plusieurs propriétés de sécurité favorables que le navigateur utilise pour empêcher accès non autorisé aux données ou aux ressources système d'un utilisateur. Il s’avère que ces propriétés sont incroyablement utiles en dehors du navigateur, en particulier lorsque vous souhaitez exécuter du code de manière isolée ou ultra-portable.
WebAssembly, par défaut, n’a accès à aucune ressource du système sur lequel il s’exécute. Il s’agit simplement d’une pure manipulation de zéros et de uns, c’est pourquoi nous avons vu Wasm utilisé principalement pour des tâches de calcul lourdes, comme le décodage de vidéos ou la manipulation d’images, plutôt que pour le développement d’applications à grande échelle. Il est relativement facile de donner à votre sandbox WebAssembly l’accès à des fonctionnalités externes, comme des informations sur l’heure actuelle ou des données stockées dans un fichier, mais les API exactement utilisées ont tendance à varier d’une application à l’autre.
Les systèmes Unix ont connu quelque chose de similaire à ce qui se passe avec WebAssembly en dehors du navigateur. De nombreuses applications souhaitaient accéder aux ressources système communes, telles que les réseaux et les systèmes de fichiers, mais chaque système d’exploitation avait une manière légèrement différente de le faire. Pour cette raison, POSIX a été lancé en tant qu'interface standard de système d'exploitation portable : tous les systèmes de type Unix pouvaient adopter cette interface pour standardiser la manière dont les programmes communiquaient avec le système d'exploitation. Cela a également permis aux programmes conçus pour fonctionner sur un système de type Unix d'être facilement portés pour fonctionner sur un autre.
Pour fournir un moyen standard aux programmes WebAssembly de communiquer avec un système d'exploitation, WASI, l'interface système WebAssembly, est né. WASI s’inspire largement d’un projet appelé CloudABI, lui-même inspiré de POSIX. Cela a ouvert un monde d’opportunités pour WebAssembly de briller en dehors du navigateur : les utilisateurs disposaient désormais de toutes les propriétés de sécurité et de sandboxing de WebAssembly combinées à des API intelligentes pour accéder aux ressources système communes sans perdre complètement le sandboxing. Naturellement, une technologie similaire vient à l’esprit : les conteneurs. Aucune discussion sur ce sujet n'est considérée comme complète sans une référence à l'un des articles les plus profonds et partagés sur WASI par le cofondateur de Docker, Solomon Hykes :
C’est une déclaration assez éloquente. WebAssembly fournit un moyen portable de conditionner du code qui peut être exécuté en toute sécurité sur n'importe quelle plate-forme à des vitesses proches de celles natives, avec l'avantage supplémentaire par rapport aux conteneurs qu'aucun système d'exploitation n'a besoin d'être présent. La plupart des conteneurs produits par les développeurs disposent d'un système d'exploitation Linux dans lequel les programmes s'exécutent, ce qui donne des tailles de conteneurs souvent de plusieurs centaines de mégaoctets ou de plusieurs gigaoctets. Les binaires WebAssembly sont du code pur, avec des tailles souvent en kilo-octets ou en mégaoctets à un chiffre. Il semble fou d’imaginer un monde où, au lieu de déployer des conteneurs partout, les développeurs déploient WebAssembly, mais cette réalité se concrétise déjà, avec plusieurs projets activement développés pour exécuter Wasm sur Kubernetes.
Un certain nombre d’entreprises bénéficient déjà de Wasm côté serveur en production. Cloudflare et Fastly disposent tous deux de réseaux de calcul de pointe massifs qui permettent aux clients de déployer du code partout dans le monde, aussi près que possible des utilisateurs. Les deux ont stratégiquement choisi WebAssembly pour avoir des binaires petits et ultra-portables avec des temps de démarrage rapides et une multi-location solide. Une jeune entreprise, Cosmonic, utilise un réseau intelligent pour permettre aux composants WebAssembly de communiquer de manière transparente entre eux, peu importe où ils s'exécutent, qu'il s'agisse d'un petit appareil dans la paume de votre main ou d'une machine fonctionnant à l'autre bout du monde. Un autre parvenu, Fermyon, utilise WebAssembly pour augmenter massivement la densité de charge de travail du serveur. Le résultat est une réduction drastique des coûts des serveurs et une informatique plus écologique pour la planète.
Pour résumer, WebAssembly, bien qu’initialement développé pour l’informatique dans le navigateur, a continué à montrer une grande viabilité en dehors du navigateur. Sa conception, prenant en charge différents langages de programmation et mettant l'accent sur la sécurité, en fait un excellent choix pour exécuter du code de manière isolée et atteindre la portabilité. L’introduction de WASI a permis à WebAssembly côté serveur de prospérer, permettant aux organisations de tirer parti de Wasm et de fournir de meilleurs produits tout en étant nettement plus rentables. Le potentiel de WebAssembly en dehors du navigateur n’est pas seulement une idée, mais une réalité croissante pour l’industrie.
Pour en savoir plus, consultez notre article de blog précédent, « Pourquoi vous devriez vous soucier de WebAssembly ».
Regardez ou écoutez également notre podcast « WebAssembly Unleashed » .