La aplicación que trae su propio navegador
El problema central de Electron es sencillo: cada aplicación trae su propio navegador. Combina tecnologías web (HTML, CSS, JavaScript) con Node.js.js para la interacción con el sistema y lo envuelve todo en un Chromium runtime dedicado. Esta arquitectura significa que cada aplicación de Electron es un entorno web autónomo, independiente del navegador nativo del sistema operativo.
Este diseño supone un alto coste en recursos del sistema. Tomemos Claude en macOS: solo el Electron Framework consume 286 MB de los 618 MB totales de la aplicación. En un Mac, 22 aplicaciones de Electron representaban en conjunto 6,5 GB de copias duplicadas de Chromium. Además, cada instancia de Chromium exige memoria; Claude, estando simplemente abierto, utilizaba aproximadamente 600 MB de RAM repartidos en 11 procesos.
Estas cifras, extraídas de un vídeo de Better Stack, ilustran la carga. Es importante señalar que se trata de ejemplos concretos, no de referencias universales. El tamaño final y el uso de memoria de una aplicación varían considerablemente según las herramientas incluidas, las bibliotecas específicas y la carga de trabajo activa, pero la ineficiencia subyacente de las instancias aisladas de Chromium permanece.
Por qué las alternativas no son victorias gratuitas
Los críticos de Electron suelen presentar el desarrollo nativo como la alternativa obvia, pero ese camino está lleno de esfuerzo multiplicado. Desarrollar con SwiftUI para Mac, por ejemplo, ofrece una experiencia perfecta al píxel, pero requiere implementaciones totalmente separadas para Windows y Linux, lo que aumenta drásticamente la carga de ingeniería y mantenimiento. Una empresa, 1Password, llegó a necesitar cuatro equipos distintos antes de consolidarse en Electron.
Alternativas como Tauri y Wails abordan la sobrecarga de Electron aprovechando el webview que ya existe en el sistema operativo (WebKit en macOS, WebView2 en Windows, WebKitGTK en Linux), mientras que Rust o Go se encargan de las interacciones nativas con el sistema. Este enfoque produce aplicaciones notablemente más ligeras: una aplicación vacía de Tauri pesa aproximadamente 5 MB en Mac, frente a los 268 MB del runtime base habitual de Electron.
Sin embargo, esta eficiencia introduce una contrapartida crítica: la compatibilidad. Depender de los webviews del sistema significa que la renderización de su aplicación puede variar entre plataformas, heredando errores o incoherencias del sistema operativo que escapan a su control. Slack, por ejemplo, utilizaba originalmente el motor de Safari integrado en macOS, pero cambió a Electron tras encontrar problemas de renderización sin solución en versiones antiguas de macOS.
En definitiva, la aparente «victoria gratuita» de las alternativas más ligeras se paga con coherencia y control. Aunque Tauri y Wails ofrecen reducciones de tamaño impresionantes, reintroducen la misma fragmentación que Electron fue diseñado para superar, lo que obliga a los desarrolladores a equilibrar el rendimiento con una experiencia de usuario predecible.
A gran escala, la coherencia supera a la elegancia
El verdadero acierto de Electron, y a la vez su defecto más molesto, reside en su carácter autónomo. Mientras que las aplicaciones nativas dependen de webviews del sistema impredecibles, como el motor de Safari en macOS o el de Edge en Windows, Electron incluye su propio Chromium runtime. Esto garantiza un entorno de renderización coherente en Windows, macOS y Linux, y elimina para los desarrolladores las sorpresas específicas de cada plataforma.
Sin embargo, este control tiene un coste. Cuando Slack utilizaba inicialmente el motor de Safari integrado en macOS, las versiones antiguas del sistema operativo con errores de Safari la dejaban sin capacidad de actuar. Cambiar a Electron le proporcionó una base de código unificada y la autonomía para publicar las correcciones por sí misma. Esta contrapartida es la razón por la que incluso frameworks más recientes como Tauri están considerando incluir Chromium, reconociendo la principal fortaleza de Electron. Obtenga más información sobre sus capacidades en Electron: Build Cross-Platform Desktop Apps.
No obstante, esta autonomía genera un problema de actualizaciones disperso. Cada aplicación de Electron lleva su propia copia de Chromium, lo que significa que una corrección en Electron o en el propio Chromium solo llega a los usuarios después de que cada proveedor de aplicaciones publique una actualización. Por ejemplo, una actualización de macOS el año pasado provocó lentitud en todo el sistema en las aplicaciones de Electron debido a un error de Electron que sobrescribía código privado de la interfaz de usuario de Apple. La corrección tuvo que ser propagada por todas y cada una de las aplicaciones afectadas, lo que ilustra la enorme ineficiencia de este modelo de actualización distribuido. Este enfoque que prioriza la coherencia sobre la elegancia, aunque simplifica el desarrollo, fragmenta la experiencia del usuario.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
Para las aplicaciones de IA, una sola base de código puede superar a tres
Para los productos de IA de rápida evolución, el atractivo de Electron es innegable. Compartir código web y de escritorio permite a los equipos llevar funciones a Mac, Windows y Linux con menos esfuerzo duplicado, lo que agiliza el desarrollo de productos como Anthropic’s Claude y OpenAI’s Codex. Se trata de contrapartidas de ingeniería, no de respaldos generales a Electron.
OpenAI, por ejemplo, sustituyó su aplicación nativa de ChatGPT para Mac por un cliente Codex basado en Electron. Mientras que la aplicación nativa original ocupaba 159 MB, la nueva versión de Electron aumentó hasta 1,7 GB, aunque una parte significativa incluye herramientas de Codex. Esto ilustra el coste en recursos de una base de código unificada.
Incluso con herramientas avanzadas de programación con IA, la carga de los clientes nativos no desaparece. Los agentes de programación destacan en la generación de implementaciones iniciales, pero probar, corregir y dar soporte a varias aplicaciones específicas de cada plataforma sigue siendo un desafío considerable, que multiplica la cantidad de errores y el trabajo de mantenimiento. Como afirmó uno de los creadores de Claude Code: «tres aplicaciones, son tres veces más errores que corregir y a los que dar soporte».
La regla práctica sigue siendo la misma: para utilidades pequeñas en las que el tamaño importa, considere Tauri o Wails, que pueden producir aplicaciones de tan solo 5 MB en macOS. Para productos complejos y multiplataforma que priorizan un comportamiento coherente y lanzamientos rápidos en Mac, Windows y Linux, Electron sigue siendo la apuesta más segura y predecible.
Preguntas frecuentes
¿Por qué las aplicaciones de Electron utilizan tanta memoria?
Cada aplicación de Electron incluye Chromium y ejecuta sus propios procesos, lo que añade carga adicional incluso cuando la aplicación está inactiva.
¿Por qué las empresas siguen eligiendo Electron?
Ofrece un entorno Chromium coherente y permite a los equipos compartir código entre Mac, Windows, Linux y, a menudo, la web.
¿Es Tauri siempre más pequeño que Electron?
Sus paquetes de aplicación pueden ser mucho más pequeños porque Tauri suele utilizar el webview del sistema operativo, pero la renderización puede variar según la plataforma.
¿Cuándo debería un equipo elegir el desarrollo nativo?
El desarrollo nativo puede ser una buena opción cuando el rendimiento y la experiencia de usuario específicos de cada plataforma justifican mantener implementaciones separadas.