Alternatives à Electron pour les développeurs TypeScript
Electron a rendu les applications desktop accessibles aux développeurs web, et son coût en taille et en mémoire a fait d'« alternative à Electron » une requête de recherche permanente. Si TypeScript est votre langage, il existe quatre voies réalistes en 2026 : rester sur Electron, migrer vers Tauri, construire des binaires à runtime embarqué avec Bun, ou compiler en natif avec Perry. Elles font des compromis très différents.
Les quatre approches
Electron — la référence
Regroupe Chromium et Node.js avec chaque application. L'avantage est une décennie de maturité en production et une stack UI (HTML/CSS/JS) que votre équipe connaît déjà — VS Code, Slack et Discord tournent dessus. L'inconvénient est le coût de base : des installeurs hello-world d'environ 80 à 150 Mo, plusieurs processus Chromium, et des centaines de Mo de RAM au repos. Desktop uniquement. Comparaison complète Perry vs Electron.
Tauri — UI web dans la webview système, backend Rust
Tauri conserve le frontend web mais abandonne Chromium embarqué : l'UI se rend dans la webview de l'OS (WKWebView, WebView2, WebKitGTK), si bien que les installeurs se situent dans la plage des Mo à un chiffre. C'est stable, bien documenté, et Tauri 2 a ajouté iOS/Android. Les compromis : le backend est en Rust, pas en TypeScript — la logique applicative au-delà de l'UI implique d'écrire du Rust et de traverser un pont IPC — et le rendu varie légèrement selon la plateforme puisque chaque OS fournit une webview différente. Comparaison complète Perry vs Tauri.
Bun — binaires monofichiers, aucune couche GUI
Les gens qui cherchent « bun electron » veulent généralement la commodité d'Electron sans son poids. bun build --compile produit un exécutable unique en embarquant le runtime Bun avec votre TypeScript empaqueté — excellent pour les CLI et les serveurs, avec une compatibilité npm complète puisque c'est littéralement le runtime. Mais le binaire fait environ 60 Mo (macOS arm64) à plus de 100 Mo (Linux/Windows), le code reste exécuté en JIT, et Bun n'a aucun framework UI — une application desktop a toujours besoin d'Electron, Tauri ou d'une bibliothèque webview par-dessus. Comparaison complète Perry vs Bun.
Perry — TypeScript compilé en widgets natifs
Perry compile TypeScript à l'avance en code machine et rend l'UI à travers de vrais widgets de plateforme — AppKit, UIKit, GTK4, Win32, Android via JNI — sans webview et sans pont IPC. Un seul langage pour l'UI et la logique, ~330 Ko pour un hello world, des binaires typiques de 2 à 5 Mo, un démarrage en ~1 ms, et dix cibles dont le mobile, la montre et la TV. La réserve honnête : Perry est pré-1.0, son API UI est la sienne propre (déclarative, de style SwiftUI — pas HTML/CSS), et l'écosystème est jeune à côté de celui d'Electron.
Côte à côte
| Perry | Electron | Tauri | Bun (--compile) | |
|---|---|---|---|---|
| Langage | TypeScript partout | JS/TS + HTML/CSS | Frontend JS/TS, backend Rust | TypeScript |
| Approche UI | Widgets natifs de plateforme | Chromium embarqué | Webview système | Aucune (CLI/serveur) |
| Taille hello-world | ~330 Ko | ~80–150 Mo | ~3–10 Mo | ~60–116 Mo selon la plateforme |
| Exécution | Code machine AOT | JIT (V8) | JIT (moteur JS de la webview) + Rust natif | JIT (JavaScriptCore) |
| Mémoire au repos | Dizaines de Mo (un seul processus natif) | Centaines de Mo (Chromium multi-processus) | Plus faible qu'Electron (webview de l'OS) | Typique d'un runtime |
| Mobile / montre / TV | iOS, iPadOS, Android, watchOS, tvOS | Non | iOS, Android (Tauri 2) | Non |
| Maturité | Pré-1.0 | Plus d'une décennie en production | Stable (1.x/2.x) | Stable |
Qu'en est-il de React Native ou Flutter ?
Ils reviennent dans chaque fil de discussion sur Electron, mais ils répondent à une question différente. React Native est mobile-first : votre JavaScript s'exécute dans le moteur Hermes et pilote des vues natives via un pont, et le support desktop n'existe qu'à travers des forks communautaires ou Microsoft séparés — ce n'est pas un remplacement direct d'Electron (Perry vs React Native). Flutter couvre le desktop et le mobile mais implique de quitter TypeScript pour Dart, et il dessine ses propres widgets plutôt que d'utiliser ceux de la plateforme. Si rester en TypeScript est la contrainte, la liste restreinte réaliste pour le desktop reste les quatre options ci-dessus.
Lequel choisir ?
Rester sur la stack web
Si votre UI est déjà construite en React/Vue/Svelte et que vous avez besoin dès aujourd'hui d'une distribution desktop éprouvée, Electron reste le choix le moins risqué — vous en payez le prix en taille et en mémoire. Si ce coût vous dérange et que vous êtes à l'aise pour écrire le backend en Rust, Tauri vous offre la majeure partie de l'expérience de la stack web pour une fraction de l'empreinte.
Laisser la webview derrière soi
Si ce que vous voulez vraiment, c'est du TypeScript en entrée, une application native en sortie — un seul langage, de vrais widgets de plateforme, de petits binaires, et le mobile/la montre/la TV depuis le même codebase — c'est précisément le vide que Perry existe pour combler, avec la maturité pré-1.0 comme prix d'entrée. Et si vous n'avez besoin que d'un CLI ou d'un serveur sous forme d'un seul fichier avec un risque de compatibilité nul, --compile de Bun est le choix pragmatique.
Voyez par vous-même
Installez Perry et livrez une application native depuis TypeScript.