Alternativas a Electron para desarrolladores de TypeScript
Electron hizo que las apps de escritorio fueran accesibles para los desarrolladores web, y sus costes de tamaño y memoria convirtieron «alternativa a Electron» en una búsqueda permanente. Si TypeScript es tu lenguaje, hay cuatro caminos realistas en 2026: quedarte con Electron, pasarte a Tauri, construir binarios con runtime embebido usando Bun, o compilar a nativo con Perry. Cada uno hace concesiones muy distintas.
Los cuatro enfoques
Electron — la base
Empaqueta Chromium y Node.js con cada app. La ventaja es una década de madurez en producción y un stack de UI (HTML/CSS/JS) que tu equipo ya conoce — VS Code, Slack y Discord se distribuyen sobre él. La desventaja es el coste base: instaladores hello world de unos 80–150 MB, múltiples procesos de Chromium y cientos de MB de RAM en reposo. Solo escritorio. Comparativa completa de Perry frente a Electron.
Tauri — UI web en el webview del sistema, backend en Rust
Tauri conserva el frontend web pero elimina el Chromium empaquetado: la UI se renderiza en el webview del sistema operativo (WKWebView, WebView2, WebKitGTK), así que los instaladores se quedan en el rango de un solo dígito de MB. Es estable, está bien documentado, y Tauri 2 añadió iOS/Android. Las concesiones: el backend es Rust, no TypeScript — la lógica de la app más allá de la UI significa escribir Rust y cruzar un puente IPC — y el renderizado varía ligeramente según la plataforma porque cada sistema operativo distribuye un webview distinto. Comparativa completa de Perry frente a Tauri.
Bun — binarios de un solo archivo, sin capa de GUI
La gente que busca «bun electron» suele querer la comodidad de Electron sin su peso. bun build --compile produce un único ejecutable embebiendo el runtime de Bun junto con tu TypeScript empaquetado — excelente para CLIs y servidores, con compatibilidad total con npm porque literalmente es el runtime. Pero el binario pesa entre 60 MB (macOS arm64) y más de 100 MB (Linux/Windows), el código se sigue ejecutando vía JIT, y Bun no tiene framework de UI — una app de escritorio todavía necesita Electron, Tauri o una librería de webview encima. Comparativa completa de Perry frente a Bun.
Perry — TypeScript compilado a widgets nativos
Perry compila TypeScript de forma anticipada a código máquina y renderiza la UI a través de widgets reales de la plataforma — AppKit, UIKit, GTK4, Win32, Android vía JNI — sin webview y sin puente IPC. Un solo lenguaje para UI y lógica, hello world de ~330 KB, binarios típicos de 2–5 MB, arranque de ~1 ms, y diez plataformas incluyendo móvil, watch y TV. La salvedad honesta: Perry está en pre-1.0, su API de UI es propia (declarativa, al estilo SwiftUI — no HTML/CSS), y el ecosistema es joven comparado con el de Electron.
Cara a cara
| Perry | Electron | Tauri | Bun (--compile) | |
|---|---|---|---|---|
| Lenguaje | TypeScript en todas partes | JS/TS + HTML/CSS | Frontend JS/TS, backend Rust | TypeScript |
| Enfoque de UI | Widgets nativos de la plataforma | Chromium empaquetado | Webview del sistema | Ninguno (CLI/servidor) |
| Tamaño del hello world | ~330 KB | ~80–150 MB | ~3–10 MB | ~60–116 MB según la plataforma |
| Ejecución | Código máquina AOT | JIT (V8) | JIT (motor JS del webview) + Rust nativo | JIT (JavaScriptCore) |
| Memoria en reposo | Decenas de MB (un único proceso nativo) | Cientos de MB (Chromium multiproceso) | Menor que Electron (webview del SO) | Típico de un runtime |
| Móvil / watch / TV | iOS, iPadOS, Android, watchOS, tvOS | No | iOS, Android (Tauri 2) | No |
| Madurez | Pre-1.0 | Más de una década en producción | Estable (1.x/2.x) | Estable |
¿Qué pasa con React Native o Flutter?
Aparecen en todos los hilos sobre Electron, pero responden a una pregunta distinta. React Native es mobile-first: tu JavaScript corre en el motor Hermes y controla vistas nativas a través de un bridge, y el soporte de escritorio solo existe mediante forks separados de la comunidad/Microsoft — no es un reemplazo directo de Electron (Perry frente a React Native). Flutter cubre escritorio y móvil pero implica dejar TypeScript por Dart, y pinta sus propios widgets en lugar de usar los de la plataforma. Si quedarte en TypeScript es la restricción, la lista realista de opciones de escritorio sigue siendo las cuatro anteriores.
¿Cuál deberías elegir?
Quédate con el stack web
Si tu UI ya está construida en React/Vue/Svelte y necesitas hoy una distribución de escritorio probada en batalla, Electron sigue siendo la opción de menor riesgo — pagas en tamaño y memoria. Si ese coste te molesta y te sientes cómodo escribiendo el backend en Rust, Tauri te da la mayor parte de la experiencia del stack web a una fracción de la huella.
Deja atrás el webview
Si lo que realmente quieres es TypeScript como entrada, app nativa como salida — un solo lenguaje, widgets reales de la plataforma, binarios pequeños, y móvil/watch/TV desde el mismo código — ese es precisamente el hueco que Perry existe para llenar, con la madurez pre-1.0 como precio de entrada. Y si solo necesitas una CLI o un servidor como un único archivo con cero riesgo de compatibilidad, el --compile de Bun es la elección pragmática.
Compruébalo tú mismo
Instala Perry y distribuye una app nativa desde TypeScript.