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.
Qu'est-ce que Bun ?
Bun est une boîte à outils JavaScript et TypeScript rapide et tout-en-un, écrite en Zig. Il exécute directement les sources `.ts` (sans étape de précompilation), utilise JavaScriptCore comme moteur JS et inclut un bundler, un gestionnaire de paquets et un test runner. `bun build --compile` regroupe le runtime Bun avec votre application dans un exécutable unique. Bun cible Linux, macOS et Windows en x64 et arm64.
Qu'est-ce que Perry ?
Perry est un compilateur TypeScript natif écrit en Rust. Il compile TypeScript directement en code machine natif via LLVM — pas de moteur JavaScript, pas de runtime, pas de JIT. La sortie est un binaire unique (environ 330 Ko pour un hello world ; ~48 Mo pour une application complète avec stdlib comme un serveur Fastify). Perry cible 10 plateformes dont macOS, iOS, iPadOS, Android, Linux, Windows, watchOS, tvOS, WebAssembly et le Web.
Côte à côte
| Fonctionnalité | Perry | Bun |
|---|---|---|
| Sortie | Code machine natif (LLVM) | Votre code + runtime Bun regroupés dans un binaire |
| Moteur JavaScript dans le binaire | Aucun par défaut ; V8 optionnel avec --enable-js-runtime (+~15 Mo) | JavaScriptCore, toujours |
| Taille du binaire hello-world | ~330 Ko | ~50–100 Mo (inclut le runtime Bun) |
| JIT | Non (compilé AOT) | Oui (JIT JavaScriptCore) |
| Cibles mobiles (iOS, Android) | Oui — UI native via UIKit/JNI | Non |
| Cibles montre / TV | watchOS, tvOS, Wear OS | Non |
| Widgets UI natifs | Plus de 25 via AppKit, UIKit, GTK4, Win32, JNI | Non (axé serveur/CLI) |
| Écosystème npm | Les paquets pur TS/JS peuvent compiler nativement ; les autres via V8 optionnel | npm complet compatible Node |
| Stabilité | Pré-1.0 (alpha) | Stable (1.x) |
| Construit en | Rust | Zig |
Là où Perry l'emporte
- +Binaires plus petits — un hello world Perry fait ~330 Ko ; un hello world Bun --compile inclut le runtime Bun et atteint plusieurs dizaines de Mo.
- +Aucun coût de moteur JavaScript. Les binaires compilés par Perry n'embarquent ni interpréteur ni JIT — votre TypeScript est l'exécutable.
- +Mobile, montre et TV. Perry compile vers iOS, iPadOS, Android, watchOS, tvOS et WebAssembly. Bun se limite au serveur/desktop.
- +UI native. Le module perry/ui de Perry compile vers de vrais widgets de plateforme (AppKit sur macOS, UIKit sur iOS, GTK4 sur Linux, Win32 sur Windows, JNI sur Android). Bun n'a pas de stratégie UI.
- +Plus rapide sur la plupart des microbenchmarks de calcul mesurés à conditions équivalentes sur M1 Max (RUNS=11, v0.5.279, 2026-04-25) : fibonacci 318 ms vs Bun 589 ms ; object_create 1 ms vs 6 ms ; nested_loops 18 ms vs 21 ms. Voir perry/benchmarks pour le tableau complet.
- +Plus rapide sur JSON validate-and-roundtrip dans le peloton à typage dynamique : la tape JSON paresseuse de Perry atterrit à 75 ms de médiane vs 259 ms pour Bun sur la même charge de 10k enregistrements.
Là où Bun l'emporte
- +Runtime mature et stable avec des versions 1.x. Perry est en pré-1.0.
- +Plus rapide sur JSON parse-and-iterate (où chaque valeur est touchée) : Bun 254 ms vs Perry 466 ms de médiane sur la même charge — la tape paresseuse de Perry ne peut pas court-circuiter quand l'itération est forcée.
- +Écosystème npm complet compatible Node prêt à l'emploi. Perry exécute un sous-ensemble nativement et bascule sur le V8 embarqué optionnel pour le reste.
- +Test runner, bundler et gestionnaire de paquets intégrés. Perry est un compilateur — l'outillage adjacent est séparé.
- +Les performances JIT à chaud peuvent dépasser l'AOT sur du code itératif avec des boucles internes chaudes ; Perry n'a pas de JIT.
- +À égalité avec Perry à la marge de bruit près sur `loop_data_dependent` (232 ms vs 235 ms) — le kernel f64 véritablement non-foldable où aucun des deux compilateurs ne peut réordonnancer. Source : perry/benchmarks RUNS=11.
Quand choisir Perry
Choisissez Perry quand la taille du binaire compte (distribution mobile, contextes embarqués, démarrages à froid rapides), quand vous voulez livrer vers mobile/montre/TV depuis un seul codebase TypeScript, quand vous voulez des widgets UI natifs, ou quand vous ne voulez pas du tout d'un moteur JavaScript dans votre artefact livré.
Quand choisir Bun
Choisissez Bun quand vous avez besoin d'un runtime stable et mature dès aujourd'hui, quand la compatibilité npm complète n'est pas négociable, quand vous voulez un outil unique pour runtime + bundler + gestionnaire de paquets + test runner, ou quand les performances JIT à chaud sur des charges longues comptent plus pour vous que la taille au démarrage à froid.
Verdict
Bun et Perry permettent tous deux de livrer un programme TypeScript sous la forme d'un binaire unique, mais ils répondent à des questions différentes. Le binaire de Bun contient le runtime Bun et est optimisé pour les charges backend/CLI où le JIT et la compatibilité Node complète l'emportent. Le binaire de Perry ne contient aucun moteur JS et est optimisé pour la taille, le démarrage à froid, le mobile et l'UI native. Si vous livrez un serveur, Bun est plus éprouvé aujourd'hui. Si vous livrez une application native ou si la taille du binaire vous importe, Perry est conçu pour ce cas.