La création du runtime Edge.js par Wasmer part d’une expérience explique l’éditeur dans un blog. « Récemment, nous avons cherché à exécuter JavaScript et Node.js dans un environnement isolé via WebAssembly, tout en visant une montée en charge de millions d’instances serverless », précise-t-il. Tout en ajoutant, « nous avions besoin non seulement d'une compatibilité totale avec Node.js, mais aussi de performances optimales au démarrage et à l'exécution, comparables à celles d'autres fournisseurs serverless performants comme Workers de Cloudflare ou Deploy de Deno ». Pour cela, Wasmer avait lancé son propre serveur JS pour exécuter les applications WinterCG (WinterJS), en parallèle des offres de Cloudflare et Deno. Mais, il était confronté à des problèmes de vitesse et de compatibilité.

Il a travaillé pendant plusieurs mois pour livrer Edge.js, un runtime JavaScript qui exploite WebAssembly pour exécuter dans une sandbox les applications Node.js dédiées à l’IA ou à l’edge computing. Au lieu d’introduire des API supplémentaires, Edge.js préserve la compatibilité Node et isole les parties non sécurisées de l'exécution à l'aide de WebAssembly. En l’espèce, ces parties sont les appels systèmes et les modules natifs (lecture de fichiers, création de threads, opérations réseau, etc) qui sont isolés via Wasix, une extension de l’interface système de WebAssemby. Ce dernier a été conçu par Wasmer en 2023 pour rendre les applications Wasm plus compatibles avec Posix (portable operating system interface). et rendre l'exécution transparente d'applications plus complexes dans les environnements serveur et navigateur

À ce jour, Edge.js prend en charge les moteurs JavaScript V8 et JavaScriptCore. L'architecture est indépendante du moteur. Wasmer prévoit d'ajouter le support des moteurs QuickJS et SpiderMonke et laisse la porte ouverte à d’autres options. Actuellement, Edge.js est environ 5 % à 20 % plus lent que Node.js lorsqu'il est exécuté en mode natif, et 30 % plus lent lorsqu'il est exécuté en mode sandbox avec Wasmer. Dans certains cas, lorsque les interactions entre le code natif et Wasm sont intenses, ce qui est le cas lors des tests de performance HTTP, l'écart peut être plus important. Wasmer vise à réduire cet écart pour Edge.js 1.0 et pour les prochaines versions de Wasmer.