Wasm est le nouveau CGI

• Wasm peut être vu non pas comme le protocole CGI, mais comme le prochain modèle applicatif qui changera l’unité d’exécution et le mode de déploiement des applications web, comme l’avait fait cgi-bin
• CGI, FastCGI, Rack/WSGI et le serverless ont tous repensé le traitement des requêtes et l’administration des serveurs, avec un objectif commun : rendre les applications haute performance plus faciles à créer et à maintenir
• Les modules Wasm s’exécutent dans un runtime hôte et peuvent réduire le coût de démarrage tout en conservant un état d’exécution propre grâce à la mémoire isolée et aux snapshots
• L’absence de threads natifs, l’impossibilité du JIT, le coût des copies de données, ainsi que le manque de maturité des Interface Types et du module linking constituent les principales limites du modèle d’exécution serveur basé sur Wasm
• Si les fonctions serverless et edge sont combinées à un environnement d’exécution Wasm, elles peuvent réduire les coûts de cold start et d’isolation, tout en permettant d’assembler plus légèrement des modules de plusieurs langages

---

Du CGI au serverless : l’évolution du modèle des applications web

• Le cœur du CGI résidait moins dans le protocole Common Gateway Interface lui-même que dans le modèle applicatif consistant à invoquer via une URL un script ou un exécutable placé dans le dossier cgi-bin
• Cette approche a constitué l’un des premiers modèles d’application web, transformant le web d’une archive de documents en un réseau d’applications interactives
• Comme elle lançait un nouveau processus à chaque requête, le coût de démarrage du processus et du parsing des scripts est devenu, selon les standards actuels, un goulet d’étranglement important

FastCGI et l’évolution des serveurs web par langage

• FastCGI a introduit un modèle dans lequel des processus de longue durée traitent les requêtes CGI afin de réduire les problèmes de performance du CGI
  • Le serveur web ne lance plus un nouveau processus à chaque requête, mais communique avec un ou plusieurs processus persistants
  • Les applications CGI existantes reposaient sur l’hypothèse que le processus se terminait après chaque requête, ce qui rendait les fuites de ressources fréquentes dans un environnement persistant
• Par la suite, les serveurs web liés à un langage se sont imposés comme pratique courante, et les applications se sont construites autour du modèle requête/réponse
  • Il était courant de les placer derrière des serveurs web riches en fonctionnalités et éprouvés comme Apache ou nginx, afin d’isoler l’application des requêtes lentes et des détails du protocole HTTP
  • Les implémentations serveur utilisaient diverses stratégies de gestion des processus : fork par requête, threads OS ou propres au langage, modèles événementiels ou réacteurs
• L’interface Rack de la communauté Ruby a aussi influencé les serveurs d’applications Flask en Python et la spécification WSGI
  • En simplifiant, une requête se compose d’une méthode HTTP, d’une table de hachage d’en-têtes, et d’une chaîne d’octets d’entrée ou d’un flux
  • Une réponse se compose d’un code d’état, d’un objet d’en-têtes, et d’une chaîne d’octets de réponse ou d’un flux

Autoscaling cloud et compromis du serverless

• Dans les modèles basés sur des serveurs physiques ou virtuels, il fallait gérer directement le nombre de serveurs en cours d’exécution
  • En cas de trafic élevé, les serveurs applicatifs pouvaient ralentir
  • En cas de trafic faible, de nombreuses machines pouvaient rester inactives
• L’autoscaling du cloud permet d’ajuster le nombre de serveurs applicatifs selon le CPU, la charge mémoire ou l’heure de la journée
  • L’ajout d’une nouvelle machine peut prendre 2 à 20 minutes selon l’application et sa configuration
  • L’extension dépend aussi des ressources disponibles dans la région de cloud hosting
• Le calcul serverless combinant Amazon Lambda et API Gateway a créé un modèle où l’on gère des fonctions plutôt que des serveurs
  • Il garantit, pour chaque requête, un processus unique, un CPU isolé et une mémoire isolée
  • Les processus peuvent être réutilisés pendant plusieurs heures au maximum, mais sont suspendus ou supprimés lorsqu’ils ne servent plus
  • AWS peut augmenter ou réduire la capacité en quelques secondes selon le volume de requêtes
• Le serverless implique des compromis clairs
  • En raison du coût de création de nouveaux processus, certaines requêtes subissent un cold start lorsque la concurrence augmente
  • Comme le processus peut être suspendu après la réponse, il devient difficile de maintenir des connexions TCP persistantes entre les requêtes
  • Les API de base de données basées sur HTTP sont populaires dans le modèle serverless, car elles tolèrent de nombreuses connexions et montent ou descendent facilement en charge avec les fonctions
• Le fait de fournir un CPU et une mémoire dédiés à chaque requête peut être un avantage ou un inconvénient selon la charge de travail
  • Certaines charges réduisent ainsi la complexité de gestion des ressources, ainsi que les préoccupations de coût et de scalabilité
  • D’autres sont plus efficaces lorsqu’un seul processus traite de nombreuses requêtes ou exploite la mémoire partagée pour le batch et le cache
  • L’article cite à la fois un cas où une application web fondée sur un CMS a réduit ses coûts de 90 % en passant au serverless, et un autre où un service d’analyse d’événements a réduit ses coûts de 90 % en revenant à un modèle basé sur serveurs

Le modèle d’exécution de Wasm sur le serveur

• Wasm a d’abord été développé pour exécuter du code haute performance dans le navigateur, en lien avec des tentatives comme asm.js
• WebAssembly est un format binaire d’instructions pour une machine virtuelle à pile, conçu comme cible de compilation portable pour plusieurs langages de programmation
  • Il permet le déploiement d’applications côté client et côté serveur sur le web
  • Il a été conçu pour être encodé dans un format binaire efficace en taille et en temps de chargement
  • Il vise une exécution proche du natif en s’appuyant sur les capacités matérielles communes à différentes plateformes
• Aujourd’hui, plusieurs langages peuvent être compilés en instructions Wasm et exécutés aussi bien dans le navigateur que sur le serveur
• Le modèle d’isolation et de sécurité exigé par le navigateur est également utile pour les applications serveur
  • Il permet d’isoler du code non fiable dans une forme bien plus légère qu’une VM ou qu’un conteneur Docker
• Des environnements serverless basés sur V8 comme Node.js, Cloudflare Workers et Deno tirent parti des capacités d’exécution Wasm accumulées dans les navigateurs
• Il existe aussi des environnements nativement Wasm comme Fastly, Shopify ou Suborbital

Modules, hôte, mémoire et snapshots

• Un module Wasm étant un ensemble d’instructions pour machine virtuelle, il a besoin d’un runtime pour s’exécuter
  • Le runtime compile le Wasm générique pour l’architecture locale et fournit l’environnement d’exécution
  • Certains environnements offrent une interface proche de l’API POSIX d’un système Linux
  • D’autres n’exposent que certaines fonctions du système hôte et exécutent les fonctions exportées du module
• Un programme WebAssembly est composé de modules, et la VM qui exécute le module est appelée host
  • Le module est l’unité de déploiement, de chargement et de compilation
  • Il regroupe des définitions de types, de fonctions, de tables, de mémoire et de valeurs globales
  • Il peut déclarer des imports et des exports, ainsi que fournir une initialisation sous forme de segments de données, de segments d’éléments et de fonction start
• Les « memories » de Wasm sont représentées comme un tableau continu d’octets, alloué par l’hôte au moment de l’instanciation
  • Chaque module invité bénéficie d’une isolation mémoire
  • Cette mémoire fonctionne comme la RAM de la machine virtuelle
  • Elle peut être fournie vide ou préremplie via des segments de données
• Grâce à ce mode d’isolation, un module peut être suspendu et sa mémoire enregistrée sous forme de segments de données
  • Il s’agit d’un concept proche du snapshot de machine virtuelle
  • Plusieurs copies d’un module suspendu peuvent ensuite être lancées
• Wizer instancie un module Wasm, exécute les fonctions d’initialisation, puis réécrit le binaire Wasm en enregistrant l’état de l’instance
  • Il initialise directement l’état des valeurs globales
  • Il enregistre les zones mémoire non nulles
  • Il supprime les segments de données existants et les remplace par des segments correspondant aux zones mémoire enregistrées
• Cette approche permet d’obtenir une exécution propre, comme avec un nouveau processus, sans payer le coût de démarrage d’un nouveau processus
  • C’est proche d’un CGI sans les inconvénients du CGI
  • En termes plus actuels, c’est proche d’un serverless sans cold start

Contraintes et avantages de Wasm

• Dans sa configuration native, Wasm ne dispose pas de threads
  • Les opérations bloquantes doivent être déplacées vers des méthodes de l’hôte
  • L’hôte peut fournir des wrappers pour lire et écrire sur les fichiers ou les interfaces réseau, suspendre le module ou proposer des gestionnaires de callback
  • Il est possible de construire un modèle réacteur ou bloquant, mais avant l’adoption de la thread proposal, la conception de l’environnement d’exécution reste déterminante
• Pour des raisons de sécurité, la génération dynamique de code Wasm n’est pas autorisée, ce qui rend la compilation JIT impossible
  • Le runtime ne peut pas manipuler le code lui-même comme une adresse
  • Des environnements d’exécution comme V8 ou CRuby, dont les performances dépendent du JIT, ne peuvent pas fonctionner dans une VM Wasm ou doivent renoncer au JIT
  • Une approche dite « pre-jit », consistant à produire à l’étape de build un runtime optimisé pour les scripts, a été proposée mais reste peu utilisée
• Comme l’interface de base entre module Wasm et hôte est la mémoire, les transferts de données peuvent nécessiter des copies
  • Il est possible de partager des blocs mémoire, mais cela dépend du modèle mémoire du runtime et du fait que cela soit recommandé ou non
  • Dans la plupart des runtimes, la communication zero-copy entre un module et les opérations d’I/O est considérée comme difficile
  • Le transfert de données en streaming vers et depuis un module Wasm peut être plus lent qu’un traitement directement côté hôte
• La VM Wasm offre un contrôle poussé de l’usage des ressources
  • Certains runtimes peuvent imposer une limite CPU en comptant le nombre d’instructions, comme avec le concept de fuel de Wasmtime
  • La VM peut limiter la mémoire et le temps réel écoulé
• Les Interface Types et le module linking peuvent réduire la taille des modules et améliorer la vitesse d’I/O ainsi que l’ergonomie
  • Les Interface Types sont utilisables, mais ne constituent pas encore un standard ratifié
  • Le module linking dispose de prototypes fonctionnels, mais pas encore d’approche standard
  • Wizer peut actuellement entrer en conflit avec le module linking ; il existe des approches personnalisées pour le résoudre, mais aucun vainqueur clair ne s’est imposé
  • Les Interface Types visent à permettre à des objets neutres vis-à-vis du langage de traverser la frontière mémoire de Wasm sans coûteux encodage/décodage
  • Aujourd’hui, l’approche courante consiste à copier du JSON en mémoire à l’aller comme au retour
• Les modules Wasm n’ont par défaut accès qu’à ce qui leur est explicitement fourni, ce qui donne au modèle de sécurité une surface petite et claire
  • Exécuter du code Wasm non fiable est généralement considéré comme relativement sûr
  • La surface d’attaque de la VM est plus réduite que celle de Docker ou d’autres modèles d’isolation
  • Comme les instructions traduites s’exécutent sur le matériel hôte, des attaques temporelles restent possibles, mais des mesures d’atténuation existent
  • Wasm peut aussi être compilé en binaire natif, mais la surface d’attaque devient alors plus grande

Fonctions edge et exécution de fonctions basée sur Wasm

• Si les environnements d’exécution Wasm et les outils de développement se généralisent, même les langages de script pourraient être poussés à adopter des runtimes Wasm et des approches de pré-amorçage (preboot) comme Wizer
• En théorie, une application pourrait reprendre pour chaque requête à partir d’une copie snapshotée, et s’exécuter ainsi plus vite que dans les modèles actuels
• Même un CLI local écrit en Ruby pourrait être distribué comme module Wasm snapshoté et relié à un runtime Ruby Wasm, afin d’obtenir des temps de démarrage proches d’un utilitaire C++ et d’être limité à l’intérieur du répertoire du projet
• Le premier grand changement consisterait à déplacer les fonctions vers l’edge, au plus près des utilisateurs
  • Le calcul serait effectué près de l’utilisateur plutôt qu’à proximité de la base de données
  • Vercel Edge Functions est cité comme exemple basé sur V8, tout en partageant plusieurs de ces principes
  • next-auth peut contrôler l’accès à des pages pré-rendues à partir de jetons de connexion JWT
  • Il devient possible de fournir du contenu personnalisé dynamique composé à partir de données mises en cache sur le CDN
• Un autre changement serait de remplacer, dans les applications serverless, les fonctions fondées sur des processus par des fonctions fondées sur Wasm
  • Suborbital permet de créer directement un environnement d’exécution de fonctions basé sur Wasm, et propose aussi d’enchaîner des fonctions Wasm sous forme de workflows
  • Beaucoup de plateformes d’exécution recommandent un module unique par requête et semblent ne pas exploiter pleinement les possibilités de mémoire partagée ou d’appels rapides entre plusieurs modules
  • Si les Interface Types se standardisent, un modèle de données middleware similaire à Rack pourrait émerger
• Wasm peut aussi s’exécuter à l’intérieur d’une fonction Lambda
  • Il devient alors possible d’utiliser des versions snapshotées de l’application sur une infrastructure existante
  • Cette combinaison est intéressante, mais présentée comme un mélange technologique susceptible de disparaître à terme

La direction du prochain modèle d’application web

• Wasm est présenté comme une technologie capable d’améliorer les performances, de faciliter une sécurité de niveau processus et de réduire les coûts de build et d’exécution des fonctions serverless
• Il peut exécuter presque tous les langages, et le module linking ainsi que les Interface Types peuvent fortement réduire la latence entre fonctions
• L’argument central en faveur de Wasm comme nouveau CGI est que, lorsque les contraintes du système changent, des choses auparavant impossibles deviennent possibles

[GN⁺]

Avis sur Hacker News

• Je ne vois pas bien en quoi WASM diffère d’anciennes technologies comme les applets Java, ActiveX, Silverlight ou Macromedia Flash.
  Je pensais qu’on avait déjà tiré les leçons de l’exécution, dans le navigateur, de code compilé tiers non fiable, et cela ressemble à une architecture qui transfère les coûts de calcul du serveur vers le client au nom de l’amélioration de l’expérience utilisateur.

  • Java et Flash n’ont pas tenu leur promesse d’un sandbox incassable capable « d’exécuter n’importe quoi en toute sécurité ».
    Leurs implémentations comportaient de nombreuses vulnérabilités et elles ont fini par devenir, de fait, inutilisables dans les navigateurs ; les autres technologies ne semblaient même pas avoir fait cette promesse au départ.
    JavaScript, lui, a réellement tenu cette promesse, et les navigateurs d’aujourd’hui exécutent le JavaScript téléchargé depuis n’importe quel domaine sans demander à l’utilisateur s’il lui fait confiance.
    WASM repose sur le moteur JavaScript et fournit des garanties de sécurité similaires ; il n’est donc pas fondamentalement différent du bytecode JVM. La différence concrète, c’est que WASM a prouvé sa sûreté, contrairement à la JVM.
    Aujourd’hui, Google Chrome est suffisamment sûr pour que des milliards de personnes puissent exécuter du WASM malveillant sans que leur téléphone soit compromis, et l’on peut reprendre ce moteur côté serveur pour exécuter les scripts de plusieurs utilisateurs dans un sandbox robuste tout en partageant les ressources.
    L’alternative est la virtualisation : on peut compiler le code en un bloc WASM et l’exécuter sur un gros serveur WASM, ou bien empaqueter un binaire amd64 avec un noyau Linux réduit et le lancer dans une VM.
    Pour l’instant, il est difficile de dire qu’une approche l’emporte clairement ; chacune a ses avantages et ses inconvénients.
  • Contrairement à ActiveX, Silverlight et Flash, WASM est un standard ouvert élaboré par plusieurs acteurs du secteur, avec plusieurs implémentations ; rien que cela le rend déjà bien meilleur que les alternatives.
    Contrairement à la JVM, WASM fournit une mémoire linéaire et n’a pas de ramasse-miettes par défaut, ce qui en fait une meilleure cible de compilation pour un éventail plus large de langages, par exemple C/C++ via Emscripten ou Rust.
    WASM est du bytecode, et la plupart des implémentations partagent probablement beaucoup de choses avec le moteur JavaScript hôte et son runtime.
    Le déplacement des coûts de calcul entre client et serveur fait partie d’un mouvement ancien de l’industrie entre clients lourds et clients légers, et ce pendule continuera de balancer.
  • Wasm présente de gros avantages par rapport aux anciennes technologies.
    Il existe une spécification de validation que le bytecode Wasm doit respecter, et ce sous-ensemble validé rend intrinsèquement impossibles de nombreuses vulnérabilités de sécurité observées dans les technologies du passé.
    Des attaques comme Heartbleed ou Rowhammer, qui s’appuient sur des dysfonctionnements matériels, peuvent rester possibles, mais on ne peut pas, par exemple, tromper la VM pour qu’elle interprète un nombre comme un pointeur et référence de la mémoire en dehors de sa propre mémoire Wasm.
    Le bytecode Wasm est relativement très simple à convertir en code machine, si bien qu’une implémentation peut être plus petite et plus rapide qu’avec une VM.
    Il ne appartient à aucune entreprise en particulier, dispose d’une spécification publique bien rédigée que tout le monde peut utiliser, et a été adopté comme standard du Web, sans nécessiter d’extension de navigateur.
    Le calcul côté client existe déjà avec JavaScript, et le code Wasm peut être efficace d’une manière impossible avec JavaScript, ce qui renforce encore cet aspect.
  • Les applets Java et ActiveX avaient un accès moins médié au système d’exploitation sous-jacent.
    Les applets étaient médiées dans une certaine mesure, ActiveX quasiment pas du tout, et la « plateforme extérieure » de WASM est grosso modo le runtime JavaScript, tandis que celle des applets ressemble plutôt à execve(2).
  • Cet article traite de WASM côté serveur, ce qui est différent de la question du transfert des coûts de calcul du serveur vers le client.
    WASM peut servir à cela, mais ce n’est pas toujours le cas, et les différences comme un meilleur sandboxing et une meilleure isolation ont déjà été bien couvertes par d’autres réponses.

• Dire qu’« Amazon a ouvert l’ère du calcul serverless avec Lambda » est discutable : Google App Engine est sorti en 2008, soit six ans avant Lambda.

  • Il y avait aussi Heroku et cette génération de PaaS.
    Ces produits existaient déjà depuis plusieurs années et avaient déjà un nom ; je ne sais pas très bien pourquoi le terme « serverless » est apparu, ni d’où il vient.
    App Engine proposait aussi des batch workers et des web workers, tout comme Heroku.
    Les deux produits sont antérieurs à Docker, donc c’est peut-être pour cela que les gens les perçoivent différemment, mais il ne me semble pas que Lambda ait été lancé avec Docker dès le départ.

• Dire que « pour des raisons de sécurité, la génération dynamique de code Wasm n’est pas autorisée, donc la compilation JIT est impossible » ne me semble pas exact.
  Pour permettre des choses comme un hot reload propre du code, c’est presque une fonctionnalité essentielle.
  L’argument de sécurité me paraît fragile.
  JS peut faire du hot reload en cours d’exécution, voire une génération de code plus radicale, sans casser la sécurité ; et en rechargeant dynamiquement tout le runtime Wasm tout en préservant la mémoire, on pourrait aussi simuler de la génération de code ou du hot reload, mais l’expérience utilisateur serait grossière.
  Je ne vois pas de raison pour laquelle ce serait techniquement impossible, et si c’est une mesure de sécurité, elle semble trop facile à contourner.
  Le bytecode WASM est conceptuellement très proche de choses comme le .NET IL ou le bytecode Java, conçues avec la compilation JIT à l’esprit.
  Je n’aime pas beaucoup WASM : j’ai l’impression que c’est un projet qui manque d’une direction forte et de la volonté de réussir au bon moment.
  Le nom suggère de « l’assembleur pour le Web », autrement dit du langage machine pour un CPU virtuel, mais en réalité c’est une représentation intermédiaire pour backends de compilateurs, avec aussi des fonctionnalités de haut niveau prévues comme la prise en charge du garbage collection, ce qui rend le concept flou.
  Il manque encore des fonctionnalités de base comme le hot reload mentionné plus haut, un threading qui ne relève pas du bricolage, une intégration directe avec le DOM sans JavaScript, des API graphiques/de calcul à faible overhead, ou un accès audio bas niveau.
  Il est difficile d’y faire tourner de grosses applications multimédias sans compromis importants.

  • Cette phrase est correcte.
    Wasm ne peut pas marquer la mémoire comme exécutable et sépare de fait le code et la mémoire, un peu comme dans une architecture Harvard.
    En plus, il n’est pas possible de sauter vers une position arbitraire du code, et il n’existe même pas d’instruction de saut de ce type.
    Ici, JIT signifie compiler et exécuter du code natif pendant l’exécution, ce qui constitue une grosse faiblesse de sécurité dans un navigateur ou une sandbox Wasm.
    C’est ancré dans la conception et dans le jeu d’instructions, ce n’est donc pas quelque chose qui se contourne facilement ; on peut en lire davantage sur https://webassembly.org/docs/security/.
    Wasm ressemble aussi au .NET IL ou au bytecode Java dans le sens où c’est le moteur qui se charge du JIT, mais donner à l’utilisateur le droit de produire du code natif en dehors du runtime et de sauter dedans est dangereux.
  • Les navigateurs utilisent clairement une certaine forme de JIT pour WASM.
    C’est pourquoi, comme avec le JIT, on peut voir un léger « à-coup de préchauffage » lors de la première exécution de code WASM, même si cela s’est beaucoup amélioré ces dernières années.
    Je crois aussi qu’on peut créer dynamiquement des blocs WASM dans le navigateur, les instancier et les exécuter.
    Je ne sais pas si c’est possible dans d’autres runtimes WASM, et même dans le navigateur il faut passer par JavaScript, mais dès qu’on veut accéder à une « API Web », il le faut de toute façon.

• WASM consiste à remplacer une VM dédiée à un langage particulier, comme la VM JavaScript, par une VM généraliste utilisable partout où une VM JavaScript est utilisée.
  Bien sûr, cela ne se limite pas à ces endroits-là.
  Généraliste signifie qu’avec un compilateur ou un interpréteur, on peut exécuter à peu près n’importe quoi, y compris JavaScript.
  Comme il est généralement implémenté comme une partie du moteur JavaScript, il hérite de nombreuses caractéristiques comme le sandboxing et l’accès aux API correspondantes.
  La standardisation de cet accès est encore en cours, mais à terme, ce qui n’est aujourd’hui possible qu’en JavaScript devrait aussi devenir possible en WASM, ainsi que beaucoup d’autres choses difficiles ou impossibles en JavaScript.
  Cela pourrait aussi s’exécuter plus vite et plus fluidement.
  L’essentiel de WASM est de supprimer beaucoup de contraintes qui existaient dans les environnements où JavaScript est populaire.
  JavaScript est un langage qui divise, et il passerait ainsi du statut d’unique option à celui d’une option parmi d’autres.
  WASM a été décrit comme un remplaçant de JavaScript, de Docker, de Java et de CGI ; en bref, il est tout cela, et plus encore.

  • Je n’ai pas de problème avec JavaScript lui-même, mais je pense que le problème vient de l’écosystème qui sert à déployer du JS sur le Web.
    Il y a trop d’outils qui font des choses similaires, avec des frontières floues.
    Même quand on finit par tout faire fonctionner, cela me semble personnellement fragile, et intimidant pour quelqu’un qui n’en fait pas professionnellement.
    Aujourd’hui, quand je dois construire quelque chose pour le Web, j’utilise leptos : l’expérience développeur est bien meilleure et, même si ce n’est pas encore en 1.x, cela me paraît plus stable que d’enchaîner cinq outils pour transpiler, obfusquer, minifier et packager des bundles JS.

• En lisant cet article, je repense à une loi logicielle qu’on citait souvent autrefois.
  Toute application suffisamment grande et survivant assez longtemps finit par réimplémenter toute la pile logicielle sur laquelle elle tourne, jusqu’au système d’exploitation, et elle le réimplémente mal.
  Je ne sais pas vraiment d’où ça vient, mais c’est souvent assez juste.

  • La version spirituelle est connue sous le nom de 10e loi de Greenspun.
    « Tout programme C ou Fortran suffisamment complexe contient une implémentation ad hoc, informellement spécifiée, boguée et lente de la moitié de Common Lisp. »
    Le motif plus général s’appelle l’Inner-Platform Effect.

• Si l’on élargit le postulat du titre, pour que WASM devienne le véritable successeur de cette lignée, il faudrait que ce soit aussi simple que de mettre en ligne et déployer une application PHP sur une pile LAMP chez n’importe quel hébergeur.
  Pour l’instant, cela ne semble pas aussi simple que l’expérience de déploiement PHP.

  • WASM s’exécute dans le navigateur.
    Je ne vois pas ce que vous vous attendez à voir changer côté hébergement.

• Je vois les choses autrement
  Je pense que l’avenir est local-first
  C’est un modèle où l’application s’exécute en grande partie dans le navigateur de l’utilisateur, avec très peu d’aide du serveur
  Des apps comme Figma, Linear ou Superhuman utilisent ce modèle avec beaucoup de succès, et Stackblitz aussi dans une certaine mesure
  Si une app aussi complexe que Figma peut s’exécuter presque entièrement dans le navigateur de l’utilisateur, j’estime que la plupart des apps le peuvent aussi
  Côté serveur, le rôle consiste surtout à synchroniser les données entre différentes instances lorsque l’utilisateur utilise l’app depuis plusieurs endroits
  Des outils comme Electric-SQL sont en cours de création, mais ils ne sont pas encore mûrs ; quand ces bibliothèques arriveront à maturité, ce domaine connaîtra une forte croissance
  Le serverless sert surtout à faire gagner de l’argent à des entreprises comme Amazon et Azure, et finira comme CGI
  WASM peut aussi réussir, mais probablement surtout dans le navigateur de l’utilisateur
  Microsoft utilise WASM pour C#/Blazor, mais je ne pense pas que dotnet dans le navigateur devienne aussi rapide que JavaScript, donc je ne crois pas que ce soit la bonne approche

  • CGI donnait du pouvoir aux utilisateurs et aux petits sites
    Personne n’en parle simplement parce que ça ne peut pas passer à l’échelle jusqu’à 1 000 milliards d’impressions publicitaires par seconde
    Chaque fois que quelqu’un écrit une fonction serverless, cela ajoute 10 pieds au yacht de Bezos
  • C’est discutable de qualifier Figma de local-first
    Si vous êtes hors ligne ou dans un endroit où le Wi-Fi est instable, vous ne pouvez pas charger vos designs ; et, sauf changement récent, si vous modifiez puis fermez le navigateur alors que le Wi-Fi est coupé, ce n’est pas enregistré
  • Donc, en gros, l’avenir consisterait à revenir à la manière dont on lançait les applications avant l’ère du Web
  • Je suis favorable au développement d’applications côté client, mais je ne pense pas qu’elles doivent forcément s’exécuter dans un navigateur ou un sandbox, ni être achetées via un app store
    Et ce n’est pas du tout une idée nouvelle
  • dotnet dans le navigateur n’est peut-être pas aussi rapide que JavaScript, mais les deux seront suffisamment rapides
    Nous développons Blazor WASM, et côté performances, dotnet n’est pas un problème

• En gros, il s’agit de recréer la JVM et son écosystème ?

  • Dans une certaine mesure, oui, mais WASM a été conçu avec d’autres contraintes en tête, plus adaptées lorsqu’on veut embarquer un runtime à peu près n’importe où
    Recréer X en tenant compte des leçons du passé peut parfois être une excellente idée
  • D’une certaine façon, oui, mais WASM prend en charge beaucoup plus de langages
    Par exemple, vers 2010, quand on a commencé à chercher comment faire tourner du code C/C++ dans le navigateur, compiler du C/C++ vers la JVM était pratiquement impossible
    À l’époque, les applets Java avaient encore un sens, donc cela aurait été bien si c’était possible, mais WASM n’existait pas encore ; Emscripten existait, et c’est lui qui, via asm.js, a fini par mener à la naissance de WASM
  • La JVM est excellente, mais cela ne veut pas dire que c’est la réponse définitive dans ce genre
    Pour avoir manipulé des class loaders et écrit directement de l’assembleur JVM dans des cours de langages de programmation dans les années 2000, je ne suis même pas sûr que la JVM soit le sommet du domaine
    Elle a effectivement permis un vaste écosystème, mais l’interface par laquelle la JVM touche au monde extérieur est vraiment un foutoir pesant
    Depuis plus de 20 ans, chaque fois que je tombe sur quelque chose lié à la JVM, je pousse un soupir
    Si l’on compare le packaging et l’écosystème de Rust à ceux de Python ou, pire encore, de C++, on voit bien qu’une réinvention intégrant les leçons des dernières décennies peut être une très bonne chose
  • Cela dit, WASM a un gros problème de class loader/linker
    Fusionner deux fichiers wasm en un seul et aligner correctement la fusion de la mémoire reste très difficile
    Le modèle de composants pourrait peut-être corriger cela, mais il contient tellement d’éléments inutilement lourds que l’adoption par Safari risque de prendre longtemps
  • Oui, et c’est pareil pour .Net CLR, entre autres

• Depuis longtemps, je pense que WASM ira vers un monde où il remplacera le code des fonctions Lambda dans le cloud
  WASM est traditionnellement considéré comme quelque chose qui s’exécute au-dessus d’une plateforme hôte, mais rien n’impose que ce soit le cas
  Grâce à son caractère sandboxé, WASM pourrait techniquement s’exécuter hors du système d’exploitation ou en ring0, et contourner une grande partie de l’overhead de l’OS
  Compiler vers WASM simplifie beaucoup de problèmes de déploiement du point de vue de l’utilisateur, et laisse à l’environnement d’hébergement beaucoup de marge pour optimiser
  On pourrait même imaginer du matériel sur mesure pour exécuter WASM plus rapidement

• Devoir exécuter automatiquement du code arbitraire et non fiable provenant de sources arbitraires et non fiables est une mauvaise chose, et on ne peut pas vraiment dire que cela remplisse le même rôle que CGI côté serveur