WebAssembly est-il viable en dehors du navigateur ?
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 que presque tous les langages de programmation puissent le prendre en charge, quel que soit le type de processeur utilisé, et il présente plusieurs caractéristiques de sécurité que le navigateur exploite pour empêcher tout accès non autorisé aux données ou aux ressources système de l’utilisateur. Ces caractéristiques se révèlent extrêmement utiles en dehors du navigateur, notamment pour exécuter du code de façon isolée ou ultra-portable.
L'histoire de POSIX sur Unix
Par défaut, WebAssembly n’a accès à aucune ressource du système sur lequel il s’exécute. Il manipule uniquement des zéros et des uns, c’est pourquoi vous verrez Wasm surtout utilisé pour des tâches intensives en calcul, comme le décodage vidéo ou la retouche d’image, plutôt que pour le développement d’applications complètes. Il est assez simple d’autoriser votre sandbox WebAssembly à accéder à des fonctions externes, telles que l’heure actuelle ou des données stockées dans un fichier, mais les API employées varient généralement selon l’application.
Les systèmes Unix ont connu une évolution semblable à celle de WebAssembly hors navigateur. De nombreuses applications cherchaient à accéder aux ressources système courantes, comme le réseau et les systèmes de fichiers, mais chaque système d’exploitation avait sa propre méthode. C’est pour cette raison que POSIX est devenu la norme pour une interface portable des systèmes d’exploitation : tous les systèmes de type Unix pouvaient adopter cette interface pour uniformiser la communication entre les programmes et le système. Ainsi, les programmes conçus pour un système Unix pouvaient être portés facilement vers un autre.
Découvrez WASI, l'interface système WebAssembly
Pour offrir un moyen standard aux programmes WebAssembly de communiquer avec un système d’exploitation, nous avons créé WASI, l’Interface Système WebAssembly. WASI tire largement son inspiration d’un projet nommé CloudABI, lui-même inspiré par POSIX. Cela ouvre un champ des possibles qui permet à WebAssembly de s’imposer au-delà du navigateur : vous profitez de toute la sécurité et de l’isolation du sandboxing propres à WebAssembly, associées à des API adaptées pour accéder aux ressources système commune, sans sacrifier l’isolation. Une technologie proche nous vient naturellement à l’esprit : les conteneurs. Toute discussion sur ce sujet doit absolument citer l’un des articles les plus marquants et partagés sur WASI, signé Solomon Hykes, cofondateur de Docker :
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.
WebAssembly côté serveur en production
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.
Croissance en dehors du navigateur
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 » .