Perry face aux alternatives
Comment Perry se compare aux autres façons de livrer du TypeScript : runtimes, compilateurs et frameworks UI multiplateformes. Honnête, sourcé, avec des chiffres mesurés là où ils existent.
Perry vs Bun
Bun est un runtime JavaScript/TypeScript tout-en-un, accompagné d'un bundler, d'un gestionnaire de paquets et d'un test runner, capable également de produire des exécutables monofichiers en regroupant son runtime avec votre code. Perry emprunte une voie différente : il compile TypeScript directement en code machine natif via LLVM — pas de moteur JavaScript dans le binaire, pas de runtime, juste un petit exécutable natif. Bun et Perry se recoupent sur la sortie TS-vers-binaire mais divergent sur la question de savoir s'il faut un moteur JavaScript dans ce binaire.
Perry vs Deno
Deno est un runtime JavaScript et TypeScript moderne bâti sur V8, avec un support TypeScript de premier ordre, un modèle de sécurité fondé sur des permissions et une commande `deno compile` qui produit un exécutable unique en regroupant V8 avec votre application. Perry compile TypeScript directement en code machine natif — pas de V8 dans la sortie, pas de couche runtime, juste un petit binaire natif.
Perry vs Static Hermes
Static Hermes (`shermes`) est l'effort de recherche de Meta visant à compiler ahead-of-time un sous-ensemble de JavaScript/TypeScript fortement typé via le moteur Hermes, principalement destiné à React Native. Perry est un autre pari sur la même idée générale — TypeScript compilé en natif — mais bâti indépendamment en Rust sur LLVM, avec un compilateur fonctionnel, plus de 25 widgets UI natifs et 10 cibles de compilation livrées dès aujourd'hui. À la mi-2026, `shermes` doit encore être compilé depuis les sources — la suite de benchmarks de Perry l'a essayé comme pair et n'a trouvé aucune voie d'installation propre via les gestionnaires de paquets standards — et le moteur Hermes V1, devenu le moteur par défaut de React Native début 2026, n'inclut explicitement pas les fonctionnalités de compilation statique.
Perry vs Electron
Electron permet de construire des applications desktop multiplateformes en utilisant les technologies du web (HTML/CSS/JS) en regroupant Chromium et Node.js avec votre application. Perry compile TypeScript directement en code machine natif et rend l'UI à travers de vrais widgets de plateforme — AppKit, UIKit, GTK4, Win32, JNI. La promesse d'Electron est la réutilisation des technos web ; celle de Perry est de petits binaires natifs avec une UI native depuis TypeScript.
Perry vs Tauri
Tauri est un framework pour construire des applications desktop (et de plus en plus mobiles) multiplateformes avec un backend Rust et un frontend qui s'exécute dans la webview intégrée du système d'exploitation — WebView2 sur Windows, WKWebView sur macOS, WebKitGTK sur Linux. Les applications Tauri sont nettement plus petites qu'Electron parce que la webview de l'OS n'est pas embarquée. Perry emprunte une voie différente : aucune webview, aucun rendu HTML, juste du TypeScript compilé en code machine natif qui pilote de vrais widgets de plateforme.
Perry vs React Native
React Native vous permet d'écrire du JavaScript/TypeScript qui pilote l'UI native sur iOS et Android — les composants UI se mappent vers les widgets de plateforme via un pont JS-vers-natif (ou, dans la New Architecture, une couche JSI / Fabric ayant la même forme conceptuelle). Perry adopte une approche différente : TypeScript est compilé ahead-of-time en code machine natif, et l'UI native fait partie du binaire compilé, pas d'un pont à l'exécution.
Alternatives à Electron pour TypeScript
Quatre voies réalistes pour les applications desktop TypeScript en 2026 : Electron, Tauri, les binaires monofichiers de Bun, et les widgets natifs de Perry. Taille du binaire, mémoire, stack UI et langage comparés honnêtement.