Electron: el estándar que hay que entender
El framework que definió la categoría, su arquitectura de proceso principal y renderizadores, qué compra de verdad con el peso que cobra, y por qué su modelo de seguridad es el contraste que explica el de Tauri.
La arquitectura
Electron es Chromium más Node.js en el mismo programa, y hereda el modelo de procesos del navegador.
Si esto se parece mucho a lo que viste en la ontología, es porque la forma es la misma: un proceso con autoridad, un proceso de presentación, y un canal de mensajes en medio. La diferencia no está en la forma. Está en de qué está hecha la frontera.
Qué compra el motor empaquetado
El argumento contra Electron siempre empieza por el peso, y es un mal argumento porque ignora lo que el peso compra:
- Una sola versión del motor. Escribes contra una versión concreta de Chromium y esa es la que ejecuta todo el mundo. No hay comprobaciones de disponibilidad, no hay una función que existe en dos sistemas de tres, no hay un usuario con una distribución antigua. Para una aplicación con una interfaz ambiciosa, esto vale mucho dinero en horas no gastadas.
- Las herramientas de desarrollo que ya conoces. Las DevTools completas, iguales en las tres plataformas, con el mismo depurador y el mismo perfilador.
- Node entero, y npm. Cualquier librería del ecosistema más grande que existe, sin envoltura, en el proceso que manda.
- Veinte años de respuestas. Cualquier problema que tengas, alguien lo tuvo antes y lo escribió. La diferencia de madurez del ecosistema es real y no se cierra con entusiasmo.
Dónde está la diferencia de verdad
No en el peso ni en el rendimiento: en de qué material está hecha la frontera.
En Electron, el proceso principal y el renderizador hablan el mismo lenguaje, comparten node_modules y viven en el mismo modelo de tipos. Mantener la frontera cerrada es una disciplina que el equipo se impone: activar el aislamiento de contexto, escribir un preload que exponga lo justo, no llamar a ipcRenderer desde la página, revisar cada dependencia que entra en el proceso principal. Todas esas cosas son buenas prácticas configurables, y las buenas prácticas configurables se desconfiguran.
En Tauri, cruzar la frontera significa cambiar de lenguaje, de proceso y de sistema de tipos a la vez. Para que el frontend haga algo con consecuencias, alguien tiene que haber escrito una función de Rust, haberla registrado, y haber declarado un permiso en un fichero versionado.
La conclusión honesta no es «Tauri es seguro y Electron no». Una capability mal escrita abre la puerta exactamente igual que un preload mal escrito. La diferencia es que en Tauri abrir la puerta cuesta un fichero que aparece en la revisión de código, y en Electron puede costar una línea dentro de un preload que nadie vuelve a leer.
Cuándo Electron sigue siendo la respuesta
Cuatro casos, y ninguno es una concesión:
- Tu equipo es de JavaScript y no va a aprender Rust. Escribir mal el core en un lenguaje que no dominas produce peor software que escribirlo bien en el que dominas. Este es el caso más frecuente y el que más se ignora.
- La interfaz usa características recientes del navegador y tiene que verse idéntica. Editores complejos, herramientas de diseño, cualquier cosa con un lienzo exigente.
- Dependes de librerías de Node que no tienen equivalente. Reescribirlas en Rust es el proyecto, no un detalle.
- El peso no importa en tu contexto. Herramientas internas, máquinas de trabajo, instalación gestionada.