Compiler TypeScript directement en code machine LLVM, le compilateur natif « Perry »
(github.com/PerryTS)Le paradigme de développement TypeScript traditionnel reposait jusqu’ici sur une évidence : transpiler du code TS, qui reste une abstraction de haut niveau, en JavaScript, puis l’exécuter sur des moteurs d’exécution JIT lourds comme V8 ou JavaScriptCore (Node.js, Bun, Deno, etc.).
Apparu récemment dans l’écosystème open source, Perry est un compilateur Native-First basé sur Rust qui vise à supprimer entièrement ce modèle d’exécution traditionnel pour compiler directement du code TypeScript en binaire natif autonome.
💡 Architecture clé et caractéristiques
-
No Runtime (zéro runtime) : sans couche intermédiaire lourde comme le moteur V8, Electron ou la JVM, il parse le code TS avec SWC et le construit directement en code machine pour la plateforme cible via l’infrastructure LLVM.
-
Build cross-platform à partir d’une source unique : un seul codebase TypeScript permet de générer des binaires pour macOS, iOS, Android, Linux et Windows.
-
True TypeScript Support : contrairement à AssemblyScript, qui est un « langage séparé proche de TS », Perry vise la prise en charge complète de l’écosystème TypeScript fondé sur le Strict Mode.
-
Compatibilité avec des frameworks UI ultra-légers : il met en avant des binaires de seulement quelques Mo et un cold start quasi instantané, proche de 0 ms. En plus de l’intégration avec des GUI natives de plateforme comme SwiftUI, GTK4 et WinUI, il permet aussi d’écrire en JSX via son propre renderer React.
🛠️ État du développement et limites (avec retours de Hacker News)
Comme il s’agit d’un projet récemment très commenté sur HN et ailleurs, les défis à relever avant un niveau production sont aussi clairement identifiés.
-
Limites liées aux caractéristiques dynamiques de JS : les styles JavaScript dynamiques, comme l’injection à l’exécution de champs ou méthodes arbitraires dans un objet ou la modification du prototype, ne sont pas pris en charge en raison de la nature de la compilation statique ; le projet fonctionne sur la base d’un sous-ensemble strict et déterministe de TS.
-
Émulation des modules intégrés de Node.js : actuellement, les bibliothèques standard HTTP de Node.js sont reproduites à l’identique à partir de l’écosystème Rust, notamment avec hyper, rustls et tokio. Certains modules comme Fastify compilent déjà avec succès et le projet progresse rapidement, mais une compatibilité à 100 % avec des bibliothèques plus complexes de l’écosystème, comme Express et ses imports dynamiques imbriqués, reste encore un défi en phase alpha.
# 사용법은 극도로 심플합니다
$ perry compile src/main.ts -o myapp
$ ./myapp # 의존성 없는 순수 네이티브 바이너리 실행
Dans sa volonté d’étendre TypeScript, jusque-là cantonné à l’écosystème web, vers la programmation système et les applications natives ultra-légères, c’est un projet que suivront avec intérêt celles et ceux qui s’intéressent aux architectures système haute performance ou aux pipelines de compilation LLVM.
GitHub: https://github.com/PerryTS/perry
7 commentaires
Je vous soutiens.
Approche intéressante. Le simple fait de supprimer le runtime est déjà une belle réussite !
On dirait bien, oui. Mais honnêtement, j’ai quand même l’impression que la sécurité mémoire risque d’être un vrai problème.
Et puis, s’il n’y a pas besoin de lookup dynamique, est-ce qu’il y a vraiment une raison de développer en script dès le départ ?
« Perry » sonne plutôt bien.
Intéressant.
L’idée ou l’approche me paraît vraiment excellente.
On dirait que la syntaxe React est aussi prise en charge, et comme il ne semble pas encore y avoir de support pour les décorateurs et ce genre de choses, j’ai l’impression que, pour l’instant, c’est davantage quelque chose à tenter sur un nouveau projet que pour migrer un programme existant.
Si, comme le prévoit la roadmap, on arrive à un niveau où la migration devient possible sans coût particulier, le build multiplateforme avec un seul langage pourrait devenir plus propre qu’aujourd’hui, et beaucoup des goulots d’étranglement de performance liés aux builds multiplateformes réalisés jusqu’ici en JavaScript pourraient aussi disparaître.
Cela dit, j’ai le sentiment que garantir la compatibilité et des résultats identiques sur plusieurs plateformes sera extrêmement difficile, et, à mon humble avis, la maintenance ne sera pas simple même à l’ère de la grande IA ; mis à part le fait que le créateur risque d’en baver énormément, ça reste vraiment très prometteur.
Intéressant.