5 alternativas ligeras a Electron

Hay cinco alternativas ligeras a Electron que vale la pena considerar. tinyjs, Electrobun, Neutralinojs y Wails renderizan tu frontend en el webview propio del sistema operativo. Perry, en cambio, compila TypeScript a una aplicación nativa que dibuja widgets reales de la plataforma y no utiliza ningún webview.

Tienes un frontend en React o Svelte que funciona bien y, sin embargo, el instalador de una pequeña utilidad construida sobre él ocupa más que la mayoría de las aplicaciones instaladas a su lado.

Toda aplicación Electron empaqueta su propio Chromium y Node.js. Por eso, cada instalación incluye un motor de navegador completo, y cada aplicación en ejecución lo paga en espacio en disco y en memoria. Este artículo compara cinco alternativas con los mismos cuatro criterios: cómo renderiza cada una, qué lenguaje ejecuta el backend, qué plataformas de escritorio soporta y a quién le conviene.

¿Por qué buscan los desarrolladores alternativas a Electron?

La mayoría de las alternativas a Electron no incluyen Chromium en el paquete y aprovechan el webview que ya trae el sistema operativo, lo que reduce mucho el tamaño de las aplicaciones. El precio es la consistencia del renderizado. Tu aplicación se ejecuta sobre WebKit en macOS, WebView2 en Windows y WebKitGTK en Linux, de modo que los casos límite se comportan igual que cuando publicas un mismo sitio para Safari y Chrome.

Dos opciones conocidas no forman parte de las cinco que se analizan a continuación. Tauri combina el webview del sistema con un backend en Rust. Deno Desktop construye aplicaciones de escritorio sobre el runtime de Deno.

La siguiente tabla compara las cinco alternativas a Electron según el motor de renderizado, el lenguaje del backend, las plataformas de escritorio y el tamaño declarado:

tinyjs: backend en JavaScript sin puertos abiertos

tinyjs ejecuta un backend en JavaScript sobre txiki.js y muestra tu página en el webview propio de la plataforma: WebKit en macOS, WebView2 en Windows y WebKitGTK en Linux. La página y el backend se comunican mediante un socket Unix (una named pipe en Windows), así que la aplicación nunca abre un puerto de red local.

• Backend: txiki.js (QuickJS más libuv), con acceso a archivos, procesos, sockets, FFI y SQLite. No necesita Node en tiempo de ejecución.
• Plataformas: el repositorio apunta a macOS, Windows y Linux, y el sitio del proyecto considera macOS la plataforma principal. Las compilaciones deben ejecutarse en el mismo sistema operativo para el que se distribuye. tinyjs build genera un paquete firmado y tinyjs notarize lo envía al proceso de notarización de Apple.
• Tamaño: tinyjs sitúa una aplicación distribuida en unos 6 MB, de los cuales 5,6 MB corresponden a su runtime txiki.js.

tinyjs new myapp --template react-ts
cd myapp
tinyjs dev
tinyjs build

El backend exporta un objeto api y la página invoca sus métodos por nombre:

// src/backend/main.js
export const api = {
  greet: async ({ user }) => `Welcome, ${user}`,
};

// in the page
const message = await tiny.api.call('greet', { user });

tinyjs advierte que Linux es donde más varía el renderizado. Los códecs multimedia dependen de qué plugins de GStreamer estén instalados, y la salida de Web Audio puede producir chasquidos con WebKitGTK. Ideal para: desarrolladores de JavaScript que quieren toda la aplicación, backend incluido, en un solo lenguaje.

Electrobun: proceso principal en TypeScript o compilado

Electrobun renderiza por defecto con el webview del sistema. Su proceso principal ejecuta TypeScript sobre Cottontail (o Bun), aunque también puedes escribirlo en Zig, Rust, Go u Odin. Es compatible con macOS, Windows y Linux.

• Renderizador: por defecto, el webview del sistema. Puedes empaquetar Chromium mediante CEF cuando un renderizado idéntico entre plataformas importa más que el tamaño de descarga.
• Backend: Cottontail, que la versión 2.0 presenta como un runtime de JavaScript construido con Zig sobre JavaScriptCore.
• Tamaño: Electrobun indica que la descarga comprimida de un hello world en macOS ARM64 ocupa 1,28 MiB con un proceso principal nativo y unos 15 MiB con Cottontail.
• Distribución: incluye de serie firma de código, actualizaciones diferenciales e instaladores para cada sistema operativo. El paquete se publica en npm con licencia MIT.

npx electrobun init

import { BrowserWindow } from "electrobun/main";

new BrowserWindow({
  title: "Inventory",
  url: "views://mainview/index.html",
  frame: { width: 1024, height: 720 },
});

El esquema views:// carga una vista empaquetada de tu proyecto. Si utilizas Hutch, el CLI de Electrobun, hutch electrobun init genera el mismo proyecto. Ideal para: equipos que quieren la separación entre proceso principal y renderizador de Electron en un paquete mucho más pequeño.

Neutralinojs: aplicaciones solo de página, sin backend de propósito general

Neutralinojs renderiza en el webview del sistema operativo y no tiene un proceso de backend en JavaScript de propósito general. Tu código se ejecuta en la página e invoca una API nativa integrada. Su documentación confirma que la aplicación no incluye Chromium; en su lugar, se apoya en el webview que proporciona el sistema operativo, como WebKitGTK en Linux.

• Backend: la página accede a la capa nativa mediante una librería cliente. Según el repositorio de Neutralinojs en GitHub, las llamadas nativas viajan por un WebSocket y un servidor estático integrado entrega los archivos del frontend. Para la lógica que la API no cubre, puedes escribir extensiones en cualquier lenguaje y conectarlas por IPC.
• Plataformas: Linux, Windows, macOS y Web. La página de versiones muestra v6.10.0 como la más reciente.

Ideal para: pequeñas utilidades cuyas necesidades caben en la API integrada (acceso a archivos, ejecución de comandos, cuadros de diálogo).

Perry: widgets nativos, no un webview

Perry no es un wrapper de webview. Compila TypeScript de forma anticipada (AOT) mediante LLVM a un ejecutable nativo que dibuja widgets reales de la plataforma: AppKit en macOS, Win32 en Windows y GTK4 en Linux. Perry también es compatible con móviles, relojes y TV.

• Backend: no existe un backend separado. Toda la aplicación es TypeScript compilado a código máquina, y el runtime de Perry se enlaza en el binario cuando el programa lo necesita.
• Limitaciones: Perry compila un subconjunto práctico de TypeScript. Su página de limitaciones descarta eval() y otras formas de código dinámico, e indica que el soporte de decoradores es solo parcial. Algunos paquetes de npm no compilarán. Para la compatibilidad con paquetes JavaScript de npm, Perry ofrece un runtime V8 opcional mediante --enable-js-runtime.
• Tamaño: el repositorio de Perry indica unos 34 KB para un hello world que solo imprime constantes. Cuando un programa usa el runtime (bucles, JSON, async), cabe esperar unos pocos MB, alrededor de 5,5 MB en macOS arm64.

perry doctor
perry check ./src
perry compile main.ts -o myapp

perry doctor comprueba que el compilador, el enlazador y el SDK de la plataforma estén instalados. perry check informa del código que no se puede compilar de forma nativa. Perry no tiene DOM, así que el código de frontend que dependa del DOM no se puede trasladar. Ideal para: desarrolladores de TypeScript dispuestos a reescribir la interfaz para obtener controles nativos.

Wails: backend en Go, webview del sistema

Wails combina un backend en Go con el webview del sistema operativo. Los desarrolladores de Go conservan las herramientas de frontend web que ya utilizan, y el WebView propio de cada plataforma se encarga de renderizarlo, por lo que no se empaqueta ningún motor de navegador. Wails v3.0.0 se publicó el 26 de octubre de 2026.

• Renderizador: WebView2 en Windows y WebKit en macOS. Desde la v3.0.0, Linux usa por defecto GTK4 con WebKitGTK 6.0, y la pila anterior basada en GTK3 sigue disponible con -tags gtk3 hasta la v3.1.
• Estado: la v3.0 es la línea estable actual, y la v2 sigue recibiendo actualizaciones críticas. El soporte para iOS y Android en la v3 es experimental y queda fuera del compromiso de estabilidad. Se publican versiones con regularidad.
• Tamaño: la página Why Wails indica binarios de unos 15 MB.

go install github.com/wailsapp/wails/v3/cmd/wails3@latest
wails3 setup

Ideal para: equipos cuya lógica de backend ya está escrita en Go.

¿Qué alternativa a Electron deberías elegir?

La alternativa a Electron adecuada depende, en primer lugar, del lenguaje que quieras usar en el backend y, después, de cuánta variación en el renderizado estés dispuesto a aceptar. Si quieres JavaScript de principio a fin, la opción es tinyjs. Si buscas un proceso principal en TypeScript con la posibilidad de empaquetar Chromium, Electrobun. Si trabajas con Go, Wails, y si tu aplicación solo necesita una API nativa integrada, Neutralinojs. Si prefieres controles nativos en lugar de una interfaz web, Perry es la única de las cinco que los ofrece. Antes de comprometerte, crea un hello world con tus dos candidatas principales y ejecuta tu frontend real en el webview de cada sistema operativo de destino.

Preguntas frecuentes

¿Necesitan los usuarios de Windows instalar WebView2 para ejecutar aplicaciones creadas con estas herramientas?

Normalmente no. El runtime Evergreen de WebView2 viene preinstalado en todos los dispositivos con Windows 11, y Microsoft lo distribuyó a la mayoría de los dispositivos con Windows 10, incluidos los administrados y los unidos a un dominio, a partir de enero de 2023. Aun así, una pequeña parte de los equipos con Windows 10 sigue sin tenerlo. Por eso Microsoft recomienda que tu instalador compruebe si el runtime está presente y lo instale cuando falte, incluso si usas el modo Evergreen.

¿Puedo reutilizar un frontend existente en React con Perry?

Solo en parte y de forma experimental. Perry no tiene DOM, pero el proyecto independiente perry-react es un renderizador compatible con React. Un bloque packageAliases en package.json redirige los imports de react y react-dom a perry-react, y los elementos JSX se asignan a widgets nativos, por ejemplo div a VStack y button a Button. El propio proyecto se describe como una prueba de concepto en Fase 1 orientada a macOS, con iOS, Android, GTK4 y Win32 previstos. En la Fase 1, las instancias de un mismo componente comparten el estado de los hooks, no se admite el estilizado con className (solo props de estilo en línea) y las librerías que dependen del DOM o de className, como MUI o React Router, no funcionan.

¿Cuáles de estas alternativas a Electron permiten crear también aplicaciones móviles?

Perry es compatible con móviles: compila el mismo TypeScript para iOS y Android, y también para watchOS y TV. tinyjs indica que no es compatible con iOS ni Android y se define como un runtime de escritorio. Neutralinojs enumera Linux, Windows, macOS y Web como sus plataformas. Wails v3 ofrece soporte experimental para iOS y Android que todavía no está cubierto por su compromiso de estabilidad. Si quieres una aplicación basada en webview que también funcione en teléfonos, Tauri 2 es compatible con iOS y Android además de con escritorio.

¿Qué necesitan tener instalado los usuarios de Linux para ejecutar una aplicación basada en el webview del sistema?

Necesitan una librería WebKitGTK, ya que estas herramientas usan el webview del sistema en lugar de empaquetar uno propio. Los ejemplos de tinyjs incluyen libwebkit2gtk-4.1-0 como requisito en Linux. Wails v3.0 utiliza por defecto GTK4 con WebKitGTK 6.0. El soporte de audio y vídeo depende de los plugins de GStreamer instalados en el equipo, así que prueba la reproducción multimedia en cada distribución de Linux que tengas previsto soportar.