Jaws – un compilateur qui précompile JavaScript en WASM

 (github.com/drogus)
2 points par GN⁺ 2024-11-11 | 1 commentaires | Partager sur WhatsApp
  • Outil qui compile JavaScript en WebAssembly, similaire à porffor par sa capacité à générer des binaires WASM autonomes. Écrit en Rust
  • Outil expérimental, pas encore prêt pour un usage en production, avec de nombreuses fonctionnalités du langage et types intégrés manquants ou incomplets
  • L’objectif est d’atteindre une prise en charge à 100 % du langage.

Pourquoi Jawsm ?

  • Le projet Jawsm a démarré pendant le travail sur Crowst, un outil de stress test pour exécuter des scénarios WebAssembly.
  • Seul le code compilé de Rust vers WASM est pris en charge, mais Rust n’est pas un langage largement utilisé.
  • Exécuter un langage de script au-dessus de WASM n’est pas idéal aujourd’hui. Il faut soit embarquer un interpréteur, soit utiliser une variante du langage cible.
  • Le projet estime qu’avec les propositions WASM modernes, il est possible d’implémenter 100 % des fonctionnalités de JavaScript sans interpréteur compilé.

Ce qui fonctionne

  • L’objectif est d’implémenter 100 % du langage, avec une attention particulière portée à la sémantique.
  • Quatre éléments sont particulièrement difficiles à implémenter : les scopes/closures, try/catch, async/await et les générateurs.
  • Actuellement, Jawsm implémente la compilation de code utilisant des closures, try/catch, une API Promise limitée ainsi que async.
  • Fonctionnalités qui marchent : déclaration et affectation de variables, while, littéraux de chaînes, nombres et opérateurs de base, booléens et opérateurs booléens de base, littéraux de tableaux, littéraux d’objets, mot-clé new.

Exigences côté hôte

  • Jawsm est construit sur des propositions WASM récentes, ce qui rend les binaires générés peu portables entre les différents runtimes.
  • L’implémentation est pensée en gardant WASIp2 à l’esprit, et utilise V8 avec des polyfills JavaScript pour les fonctionnalités WASIp2.
  • Un script run.js permet d’exécuter les binaires générés par Jawsm.

Utilisation

  • Il vaut mieux ne pas l’utiliser sauf si vous contribuez au projet.
  • Après avoir cloné le dépôt, vous pouvez utiliser le script execute.sh pour générer un fichier WAT, le compiler en binaire, puis l’exécuter avec Node.js.
  • Rust cargo, la dernière version de wasm-tools, et Node.js v23.0.0 ou supérieur sont requis.

Prochaines étapes

  • Le plan est d’abord de terminer les fonctionnalités les plus difficiles à implémenter ; les prochaines sont les générateurs et la prise en charge du mot-clé await.
  • Le projet aimerait utiliser la proposition de stack switching, mais simule actuellement la persistance via une transformation CPS.
  • Ensuite viendront l’implémentation de la syntaxe ainsi que des types intégrés et des API.

Principe de fonctionnement

  • Le projet transforme la syntaxe JavaScript en instructions WASM, en s’appuyant sur les propositions WASM GC, gestion des exceptions et optimisation des tail calls.
  • Du code WASM supplémentaire est généré pour simuler les scopes et closures de JavaScript dans WASM.

À lire aussi

1 commentaires

 
GN⁺ 2024-11-11
Avis Hacker News

  • Utilisation astucieuse de la nouvelle proposition WASM GC. Les compilateurs JS -> WASM existants embarquaient tout le moteur JS, mais ce projet essaie de mapper directement les structures JS sur les primitives de WASM.

    • Par le passé, j’ai créé un compilateur embarqué ARM presque proche de TypeScript. Certaines techniques pourraient être utiles.

  • J’aime écrire en Rust, mais ce n’est pas un langage largement utilisé. Rust reçoit beaucoup d’attention ces temps-ci et semble être utilisé à divers endroits.

  • Je suis convaincu qu’il sera possible de couvrir 100 % de la spécification JavaScript. Les idées, questions ou critiques sont les bienvenues.

    • Je me demande s’il y a des résultats pour test262_runner.rb. Ce serait bien de montrer cette progression dans le README. Excellent projet.

  • J’ai lu le README.md du projet, mais je ne suis pas certain de l’usage prévu. Je me demande comment le code WASM généré interagit avec le runtime. Je me demande si l’outil est destiné à être compatible avec les navigateurs et autres runtimes WASM, ou seulement avec le runtime lié au projet.

    • Je me demande comment il réagit lorsqu’il rencontre des API Web dans le code JavaScript ou des identifiants globaux définis uniquement dans certains environnements. Si ce n’est pas destiné à cet environnement, je me demande comment les E/S doivent être gérées lorsqu’on l’utilise.

  • L’exécution de JS sans runtime de navigateur approche. perforr, jaws ou un autre projet finira par réussir.

  • Je me demande comment sont gérés les décalages d’encodage des chaînes et les utilitaires associés. WASM prend en charge l’UTF-8 et JS l’UTF-16 (potentiellement mal formé).

  • J’aime beaucoup cette approche. Construire directement pour WASM, plutôt que d’essayer de générer directement du binaire, signifie qu’on peut s’appuyer sur WASM GC et sur le support asynchrone attendu dans une partie de WASI 0.3.

  • Certains appellent cela un compilateur. Excellent travail.

  • Je me demande si ce code s’exécute plus vite que le même code exécuté en JS, ou si c’est plutôt pour l’interopérabilité avec d’autres langages.