WASM, la nouvelle technologie CGI

Wasm est le nouveau CGI

• Rôle de Wasm : Wasm (WebAssembly) se prépare à apporter une nouvelle évolution au modèle des applications web. L’accent est mis sur la possibilité de créer et maintenir plus facilement des applications hautes performances.
• Anciens modèles d’applications web : CGI a fait passer le web d’une archive de documents à un réseau d’applications. FastCGI a été développé pour résoudre les problèmes de performance, avant d’évoluer ensuite vers le serverless computing.
• Serverless computing : Le serverless computing, comme Amazon Lambda, amène à gérer des « fonctions » plutôt que des serveurs. Cela offre l’avantage de pouvoir monter rapidement en charge selon le volume de requêtes.

Wasm côté serveur

• Extensibilité de Wasm : Wasm peut s’exécuter non seulement dans le navigateur, mais aussi sur le serveur, ce qui fournit un modèle d’isolation plus léger pour les applications côté serveur.
• Environnement d’exécution Wasm : Les modules Wasm s’exécutent dans une machine virtuelle et peuvent être compilés depuis divers langages. Cela peut contribuer à améliorer les performances dans les environnements serverless.

Les compromis de Wasm

• Threads et compilation JIT : Wasm ne prend pas en charge les threads nativement, et la compilation JIT n’est pas possible. Cela peut avoir un impact sur les performances.
• Interface mémoire : Le déplacement des données entre un module Wasm et l’hôte peut nécessiter des copies, ce qui peut affecter les performances.

Perspectives d’avenir

• Évolution de Wasm : À mesure que les environnements d’exécution Wasm et les outils de développement progressent, les langages de script disposeront eux aussi d’un runtime Wasm. Cela pourrait améliorer de manière significative la vitesse d’exécution des applications.
• Edge computing : Wasm permet d’effectuer des traitements au plus près des utilisateurs grâce à l’edge computing, ce qui améliore les performances.

# Le résumé de GN⁺

• Wasm porte une nouvelle évolution du modèle des applications web, en facilitant la création et la maintenance d’applications hautes performances.
• La combinaison du serverless computing et de Wasm réduit la complexité de la gestion des serveurs et offre l’avantage de pouvoir monter rapidement en charge selon le volume de requêtes.
• Wasm peut s’exécuter non seulement dans le navigateur, mais aussi sur le serveur, fournissant ainsi un modèle d’isolation plus léger pour les applications côté serveur.
• Les progrès de Wasm pourraient permettre aux langages de script de disposer d’un runtime Wasm, améliorant nettement la vitesse d’exécution des applications.
• Grâce à l’edge computing, il devient possible d’effectuer les traitements au plus près des utilisateurs, ce qui améliore les performances.

[GN⁺]

Commentaires sur Hacker News

• Amazon a lancé l’ère du serverless computing avec Lambda. Google App Engine est sorti 6 ans avant Lambda.

• Il est difficile de comprendre la différence entre WASM et des technologies précédentes comme les Java Applets, ActiveX, Silverlight et Macromedia Flash. Je pensais qu’on avait retenu la leçon sur l’exécution de code compilé tiers non fiable dans un navigateur web.

• La compilation JIT est impossible, car la génération dynamique de code WASM n’est pas autorisée pour des raisons de sécurité. C’est pourtant une fonctionnalité essentielle pour faire proprement des choses comme le hot reloading du code.

• Les arguments de sécurité ne me paraissent pas crédibles. On peut faire du hot reload de JS ou générer du code à l’exécution, et on peut recharger dynamiquement un runtime WASM tout en conservant la mémoire, mais l’expérience utilisateur serait médiocre.

• Je n’ai pas trouvé de raison technique qui rende cela impossible. Si c’est une mesure de sécurité, elle serait facile à contourner.

• Le bytecode WASM est conceptuellement similaire à .NET IL, au bytecode Java et à d’autres formats conçus pour la compilation JIT.

• Je pense que le projet WASM manque d’une direction claire et d’une véritable volonté de réussir. Il lui manque encore des fonctionnalités de base.

  • Cela inclut le hot reload, un threading non bricolé, une interface native avec le DOM, la prise en charge d’API graphiques/de calcul à faible overhead, et un accès audio bas niveau.

• WASM remplace la VM d’un langage spécifique par une VM généraliste. Cela permet d’exécuter presque tout via un compilateur ou un interpréteur.

  • Il est généralement implémenté comme une partie du moteur JavaScript, dont il hérite du sandboxing et de l’accès aux API. La standardisation est en cours.

• WASM est présenté comme un remplaçant de JavaScript, de Docker, de Java, de CGI, etc. C’est donc tout à la fois.

• Je pense que WASM devrait pouvoir être hébergé et déployé aussi facilement qu’une application PHP. Ce n’est probablement pas encore le cas.

• Cela rappelle une vieille loi du logiciel : toute application suffisamment grosse et ancienne finit par réimplémenter toute la pile logicielle sur laquelle elle s’exécute.

• La grande promesse de WASM côté serveur est d’offrir une plateforme éternelle qui n’exige pas de mises à jour régulières.

  • Devoir mettre à jour et redéployer une application AWS Lambda chaque fois qu’une version de Node.js ou de Python n’est plus prise en charge est un vrai problème.

• Je pense que le local-first est l’avenir. Les applications s’exécutent principalement dans le navigateur de l’utilisateur et n’ont presque pas besoin de l’aide du serveur.

  • Des applications comme Figma, Linear et Superhuman utilisent déjà ce modèle avec succès.

• WASM peut réussir dans le navigateur de l’utilisateur. Microsoft l’utilise pour C#/Blazor.

• J’ai l’impression qu’on est en train de réinventer la JVM et tout son écosystème.

• Je pense que WASM va évoluer vers le remplacement du code exécutant les fonctions lambda dans le cloud.

  • WASM est traditionnellement perçu comme quelque chose qui s’exécute sur la plateforme hôte, mais ce n’est pas une nécessité.

  • Grâce à ses propriétés de sandbox, WASM peut s’exécuter en dehors du système d’exploitation ou en ring0.