:: electron host · 01

:: tauri host · 02

:: deno-desktop host · 03

Blog · actualizado 7 sep 2026 · Electron vs Tauri vs Deno · EN

Tres motores, el mismo contrato: por qué Línea arranca en Electron

Por Edu Peralta, construyendo Línea.

Quería un proyecto donde pudiera aplicar de verdad lo que aprendí durante la universidad y lo que he visto en proyectos de producción que aprovechan bien DIP e IoC. El primer ejemplo que se me viene a la cabeza es VSCode, donde si decidimos bajar el repo y bucear por el código podremos encontrar: orientación a objetos bien usada, IoC de verdad, módulos que se pueden sustituir y un sinfín de patrones que han utilizado a lo largo de sus más de 10 años de desarrollo. Permitiéndoles hacer evoluciones de módulos enteros de forma segura, sin embargo, lo que no han cambiado aún es el motor de desktop Electron.

Eso me quedó dando vueltas. Si la lógica ya está desacoplada, ¿por qué no el runtime? La respuesta probable es el coste: migrar módulos que ya funcionan no compensa. Al empezar Línea quise no heredar esa deuda. El objetivo no era “elegir el framework de moda”. Era poder cambiar el engine y medir: Deno, Tauri o Electron. ¿Cuál aguanta tres terminales a la vez, con Git, worktree y UI en React?

El contrato, no el framework

Definí IRuntime con el objetivo de desacoplar la app, haciendo que ésta hablase con una interfaz dejando que cada engine implemente el mismo contrato a su manera. Ejemplos de implementación:

• búsqueda de ficheros
• estado del repositorio y revisión del worktree
• sincronización del cwd
• PTY, procesos, filesystem, IPC

Cada adapter lo hace en su mundo:

• Tauri: Rust nativo
• Electron: proceso de background en Node
• Deno Desktop: TypeScript sobre las APIs de Deno

                    ┌─────────────────────┐
                    │     App / UI        │
                    │   (React + WebGPU)  │
                    └──────────┬──────────┘
                               │
                               │  IRuntime
                               │  findFiles()
                               │  repoStatus()
                               │  syncCwd()
                               │  ...
                               ▼
                    ┌─────────────────────┐
                    │   RuntimeContract   │
                    └──────────┬──────────┘
            ┌──────────────────┼──────────────────┐
            ▼                  ▼                  ▼
   ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
   │ ElectronAdapter│ │  TauriAdapter  │ │  DenoAdapter   │
   │ Node + node-pty│ │ Rust + webview │ │ Deno APIs + TS │
   └────────────────┘ └────────────────┘ └────────────────┘

Sé que esto suena muy académico, poco usable y en muchas ocasiones he visto utilizar patrones de diseño que al final no se acaban aplicando, pero en este caso, si se aplican bien, funciona.

Resultados (con tres terminales abiertas)

Tauri llega con fama de ser la más rápida y más ligera: menos peso, arranque más rápido, menos memoria. En el empaquetado y el arranque, sí, pero en este benchmark concreto no sale beneficiado.

Misma UI (React + WebGPU), misma carga: tres terminales.

Empiezo por Deno, que recordemos que está en un estado experimental, pero aún así quise implementarlo por ver el rendimiento. Como se puede ver, sin duda es el que más gasta en memoria y aún le queda mucho recorrido de mejora. Le tengo esperanza al equipo del creador de Node, que considero que están haciendo un buen trabajo.

La sorpresa es Tauri, ya que en este escenario se acerca a Electron en consumo debido al uso de WebGPU. Sin este renderer intuyo que los números de Tauri habrían sido más amables. Además, en velocidad de ejecución Tauri gana: por debajo está Rust, se nota.

Desarrollar con Tauri (lo que no sale en el README)

Usar el webview del sistema es una idea excelente, ya que el instalable baja mucho. El precio son tres engines reales, no uno.

1. Tres implementaciones, tres fallos. El que más me ha tocado es WebKit + WebGL/WebGPU en las terminales: a partir de un rato de ejecución empiezan los glitches. No es “un bug de mi código y ya”. Es el motor del WebKit.
2. El compilador de Rust. En una sesión de desarrollo se va a ~5 GB. Esto no es un detalle menor si compilas a menudo.
3. Dos (o tres) lenguajes. Tener todo en uno —TypeScript de punta a punta— ahorra contexto, tooling y dolores que no aparecen en un benchmark de 10 minutos.

En comparación con Electron, que es un Chromium, tenemos un sistema predecible y un solo sitio donde buscar el fallo.

Elección

La versión que se instala hoy es Electron. Aunque pese más y gaste algo más de memoria, obtenemos a cambio:

• Un solo motor (Chromium)
• Sesiones de días sin que WebGPU se caiga

No es la respuesta cool, sino que es la que sobrevive al uso que Línea pide: varios agentes, varios paneles, el repo a la vista, sin reiniciar a media tarde.

El contrato IRuntime sigue ahí. Si Deno madura o Tauri estabiliza WebKit en terminales largas, el cambio no es reescribir la app, sino que es otro adapter más.

Línea está disponible para macOS, Windows y Linux. Gratis, sin cuenta ni tarjeta.