Pasa suficiente tiempo en Hacker News o Reddit y acabarás viendo la misma crítica: Electron es demasiado pesado, Electron consume demasiada memoria y las aplicaciones de escritorio serias deberían ser nativas.
Hay algo de verdad en esa crítica. Las aplicaciones Electron suelen tener un consumo de recursos de base mayor porque incluyen Chromium y Node.js. Una aplicación nativa cuidadosamente diseñada puede consumir menos memoria, iniciarse más rápido e integrarse más profundamente con su sistema operativo.
Pero este debate se centra demasiado en el ordenador y demasiado poco en la empresa que desarrolla el software.
Para la mayoría de los usuarios, la tecnología que hay detrás de una aplicación apenas importa. Les importa que funcione, que responda con agilidad, que se corrijan los errores y que sigan apareciendo funciones útiles. Por tanto, para una empresa de software, una de las propiedades más importantes de una pila tecnológica es algo que rara vez aparece en las tablas de pruebas de rendimiento: ¿con qué rapidez puede el equipo desarrollar, lanzar, aprender y mejorar el producto?
Para muchas aplicaciones de escritorio modernas, Electron es excepcionalmente bueno en eso.
El recurso escaso es el tiempo de desarrollo
La empresa idealizada que desarrolla aplicaciones de escritorio nativas tiene un excelente equipo de macOS, otro equipo que desarrolla la aplicación para Windows y quizá otro que da soporte a Linux. Cada aplicación está cuidadosamente optimizada para su plataforma y cada desarrollador conoce a fondo el sistema operativo en el que trabaja.
La mayoría de las empresas no tienen ese lujo.
Un producto de escritorio puede contar con cinco desarrolladores. Puede contar con dos. Esos mismos desarrolladores tienen que crear funciones, corregir errores, mejorar el rendimiento, atender a los clientes, mantener la infraestructura, adaptarse a los cambios de los sistemas operativos y seguir haciendo avanzar el producto.
El desarrollo nativo dificulta esta tarea porque macOS, Windows y Linux son plataformas realmente distintas. Tienen diferentes frameworks de interfaz de usuario, API, sistemas de permisos, comportamientos del ciclo de vida, instaladores, mecanismos de actualización, sistemas de notificaciones, gestión de ventanas, API de accesibilidad y años de peculiaridades específicas de cada plataforma.
Electron cambia esa ecuación. Combina Chromium, Node.js y API de escritorio en un modelo de aplicación compartido entre macOS, Windows y Linux. Un mismo desarrollador de TypeScript puede a menudo crear una función desde la interfaz hasta la lógica de la aplicación y publicarla en todas las plataformas de escritorio. El código nativo sigue estando disponible cuando realmente se necesita, pero se convierte en la excepción en lugar de ser la base del producto. El propio Electron describe esto como una de sus principales ventajas: una única base de código JavaScript para las tres grandes plataformas de escritorio.
Esa diferencia se acumula con los años. Si cada función importante requiere implementaciones separadas para Mac y Windows, la empresa paga repetidamente ese coste de mantener varias plataformas: con cada función, rediseño, experimento, corrección de errores, mejora de accesibilidad y optimización del rendimiento.
Con Electron, gran parte de ese trabajo se hace una sola vez.
Electron optimiza la velocidad de iteración
Los productos rara vez se vuelven excelentes porque la primera implementación fuera perfecta. Se vuelven excelentes mediante la iteración.
Un equipo lanza algo. Los clientes lo usan. El equipo aprende. Modifica la función. Más personas la usan. Se hace visible otro problema. El equipo vuelve a mejorarla.
Cuanto más corto sea el ciclo entre idea, implementación, comentarios y mejora, más rápido mejora un producto.
Electron es especialmente bueno acortando ese ciclo porque se basa en tecnologías que las empresas de software ya utilizan por todas partes: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js y npm.
Eso significa que las empresas pueden compartir mucho más que código fuente. Pueden compartir desarrolladores, componentes de interfaz de usuario, herramientas, bibliotecas, infraestructura, métodos de prueba y conocimiento organizativo entre sus productos web y de escritorio.
Un desarrollador frontend no deja de ser útil de repente porque la empresa necesite ayuda con el cliente de Windows. Un desarrollador de escritorio puede contribuir a la aplicación web. Un desarrollador full-stack de TypeScript puede pasar de un producto a otro a medida que cambian las prioridades.
Para una empresa pequeña o mediana, esa flexibilidad puede valer mucho más que ahorrar 100 MB de RAM.
Mira quién utiliza realmente Electron
A veces se describe Electron como un atajo para empresas que no están dispuestas a invertir en una aplicación de escritorio «como es debido». Los productos desarrollados con él hacen que ese argumento sea cada vez más difícil de sostener.
El propio proyecto Electron destaca productos como Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom y Canva. No son utilidades sencillas. Muchos se encuentran entre las aplicaciones de productividad más sofisticadas y utilizadas del mundo.
Visual Studio Code es un ejemplo especialmente útil. Microsoft podría desarrollar su editor de código insignia con prácticamente cualquier tecnología de Windows que quisiera y, aun así, VS Code utiliza Electron en Windows, macOS y Linux. Incluye terminales, depuración, servidores de lenguaje, integración con Git, desarrollo remoto, cuadernos, extensiones y editores altamente personalizados.
La pregunta interesante no es si Microsoft podría ahorrar memoria desarrollando tres versiones nativas separadas. Por supuesto que podría.
La pregunta más pertinente es si VS Code habría evolucionado tan rápido, mantenido tanta coherencia entre plataformas y desarrollado un ecosistema tan grande si cada capacidad importante hubiera requerido varias implementaciones separadas.
ChatGPT y Claude muestran la diferencia de enfoque
El contraste entre ChatGPT y Claude también resulta ilustrativo.
OpenAI desarrolló inicialmente una aplicación nativa específica de macOS para ChatGPT. Anthropic, en cambio, desarrolló Claude Desktop con Electron y contó desde el principio con una base de escritorio compartida entre plataformas.
Esa diferencia cobró más importancia a medida que los productos se ampliaban. Claude Desktop podía seguir añadiendo capacidades como integraciones con MCP, extensiones y Claude Code a la misma aplicación multiplataforma. Anthropic ahora ofrece Claude Code directamente dentro de su experiencia de escritorio, incluidas múltiples sesiones locales y remotas.
Más adelante, OpenAI también orientó su nueva estrategia de escritorio multiplataforma hacia Electron, y Electron ahora incluye tanto ChatGPT como Claude entre sus aplicaciones destacadas.
Sería excesivo afirmar que Electron por sí solo explica la diferencia en la velocidad de evolución de los productos. El tamaño del equipo, las prioridades, la estrategia del producto y la organización interna también importan. Pero la ventaja arquitectónica es sencilla: una base multiplataforma compartida facilita el lanzamiento de funciones en distintos sistemas operativos sin mantener implementaciones separadas.
Ese es exactamente el tipo de ventaja que gana valor a medida que crece un producto de escritorio.
Evernote aprendió el coste de mantener clientes separados
Evernote es uno de los ejemplos históricos más claros de este problema.
Durante años, Evernote mantuvo aplicaciones distintas para Mac, Windows, dispositivos móviles y la web. Con el tiempo, esos productos acumularon comportamientos diferentes, diferencias de renderizado, supuestos heredados y problemas de sincronización.
En 2020, Evernote reconstruyó sus aplicaciones de Windows y Mac sobre una base de código compartida. La empresa afirmó que la nueva base haría las aplicaciones más estables, permitiría corregir errores más rápido, publicar funciones con mayor frecuencia y mejorar la sincronización entre plataformas.
Esa migración no estuvo exenta de dificultades, y a algunos usuarios veteranos les disgustó la pérdida inicial de funciones específicas de cada plataforma. Pero el motivo por el que Evernote emprendió una reescritura tan costosa es más interesante que los propios problemas de la migración.
Una vez que un producto cuenta con un editor avanzado, almacenamiento sin conexión, búsquedas, archivos adjuntos, colaboración, tareas, calendarios y una sincronización compleja, mantener varias implementaciones independientes resulta cada vez más caro. Los errores se manifiestan de forma distinta. El renderizado varía. La lógica de sincronización interactúa con arquitecturas locales diferentes. Cada cambio importante del producto tiene que propagarse a varios clientes.
Una arquitectura compartida no hace desaparecer los problemas difíciles. Permite a la empresa resolver más de ellos una sola vez.
Linux puede ser la ventaja más infravalorada de Electron
Linux refuerza aún más los argumentos a favor de Electron.
Ofrecer un buen soporte para Linux es difícil. A diferencia de macOS o Windows, el «escritorio Linux» no es una única plataforma estrechamente controlada. Los desarrolladores tienen que lidiar con distintas distribuciones, formatos de paquetes, entornos de escritorio, pilas gráficas, bibliotecas del sistema y protocolos de visualización.
Para muchas empresas de software, la decisión empresarial racional sería simplemente no dar soporte a Linux.
Electron cambia la ecuación económica.
Como Electron proporciona un entorno de ejecución común para macOS, Windows y Linux, añadir soporte para Linux puede ser muchísimo más fácil que mantener una implementación nativa independiente para Linux. Esta es una de las razones por las que los usuarios de Linux tienen hoy acceso a muchas aplicaciones de escritorio importantes que, históricamente, quizá nunca habrían recibido un cliente oficial para Linux.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian y muchas otras herramientas pueden dar soporte a Linux sin mantener una aplicación GTK o Qt totalmente independiente.
Electron también asume gran parte de la complejidad específica de Linux por los desarrolladores de aplicaciones. Un buen ejemplo es el paso de X11 a Wayland. Los responsables de mantenimiento de Electron han explicado cómo la transición de Chromium a Wayland arrastró en la práctica a las aplicaciones Electron consigo, reduciendo la cantidad de trabajo sobre la pila de visualización que cada equipo de desarrollo tenía que realizar por separado.
Sin frameworks como Electron, muchas empresas no desarrollarían clientes nativos para Linux. Simplemente darían soporte a macOS y Windows y dejarían a los usuarios de Linux con una pestaña del navegador.
Electron probablemente ha hecho más por el software comercial de escritorio para Linux de lo que se le reconoce.
Incluso Microsoft elige cada vez más la tecnología web
Microsoft es quizá el contraejemplo más contundente de la idea de que el software serio para Windows debería utilizar siempre frameworks nativos de interfaz de usuario de Windows.
Microsoft controla Windows. Controla Win32, .NET, WinUI, WebView2 y buena parte de la plataforma sobre la que trabajan los desarrolladores. Si el desarrollo totalmente nativo para Windows fuera siempre la respuesta obvia, Microsoft estaría en la mejor posición posible para utilizarlo en todas partes.
No lo hace.
Visual Studio Code utiliza Electron. Teams sigue basándose en React, TypeScript y Chromium incluso después de que Microsoft sustituyera Electron por un contenedor WebView2 más optimizado. El nuevo Outlook para Windows también depende en gran medida de la tecnología web, y Microsoft describe explícitamente esa arquitectura como una forma de mejorar la agilidad, acelerar la entrega de funciones y crear una experiencia más coherente.
Teams resulta especialmente ilustrativo. Microsoft quería mejorar el rendimiento y reducir el consumo de recursos, así que cambió la arquitectura. Pero no reescribió la interfaz como una aplicación tradicional nativa de Windows.
Conservó la pila web y optimizó el resto a su alrededor.
Esa distinción importa. Microsoft decidió que las ventajas organizativas de React, TypeScript y Chromium merecían conservarse incluso mientras mejoraba agresivamente el rendimiento.
Aquí hay otra lección. La propia Microsoft ha introducido muchas generaciones de tecnologías para aplicaciones de Windows a lo largo de los años: Win32, WPF, UWP, WinUI y otras. Una empresa que elige «Windows nativo» no está necesariamente eligiendo una plataforma atemporal. A menudo está apostando por una generación concreta del framework preferido de Microsoft.
La plataforma web se ha convertido, con cierta ironía, en uno de los entornos de destino más estables disponibles para las aplicaciones.
La contratación forma parte de la arquitectura
La elección de frameworks también determina a quién puedes contratar.
Los desarrolladores de JavaScript y TypeScript constituyen una de las mayores reservas de talento técnico del sector. Una empresa que desarrolla con Electron puede contratar de esa reserva en lugar de necesitar equipos separados de especialistas experimentados en macOS, Windows y Linux.
Los especialistas en desarrollo nativo siguen siendo valiosos. Los productos de escritorio serios siguen necesitando desarrolladores que conozcan a fondo los sistemas operativos. Pero Electron cambia cuántos especialistas necesitas.
En lugar de exigir que la mayor parte de la aplicación sea desarrollada por expertos en cada plataforma, puedes mantener una cantidad relativamente pequeña de código de integración nativa y dejar que la mayoría del equipo trabaje en el producto compartido.
Esto importa aún más cuando una empresa ya tiene una aplicación web. A veces se pueden compartir componentes de React. Se pueden reutilizar bibliotecas de TypeScript. La lógica del producto puede trasladarse entre la web y el escritorio. Los desarrolladores pueden cambiar de equipo sin aprender un ecosistema completamente distinto.
La contratación también se vuelve menos vulnerable. Si se marcha el único desarrollador que conoce a fondo tu cliente nativo de Windows, puede ser difícil reemplazar ese conocimiento especializado. Con Electron, una parte mucho mayor de la base de código utiliza tecnologías conocidas por el resto de la organización.
Por tanto, un framework no determina únicamente cómo se renderiza una interfaz. Influye en cómo puede estructurarse la propia organización de desarrollo.
Nativo no significa automáticamente mejor software
Los desarrolladores suelen utilizar «nativo» casi como sinónimo de «rápido».
No lo es.
Las API nativas ofrecen a los desarrolladores la oportunidad de crear una aplicación muy eficiente. Que el producto final lo consiga realmente depende de la arquitectura, el equipo, el presupuesto y la cantidad de trabajo de optimización que la empresa pueda permitirse.
Una aplicación nativa también puede ser lenta, tener errores, consumir mucha memoria, ser incoherente o estar mal mantenida.
Y, lo que es más importante, repartir un equipo limitado entre varias implementaciones nativas significa que cada implementación recibe menos horas de desarrollo.
Imagina que una empresa dispone de seis desarrolladores para su producto de escritorio. Una opción es repartirlos entre Mac y Windows, quizá dejando Linux sin soporte. Otra es asignar a casi los seis a una única aplicación Electron compartida que dé servicio a las tres plataformas.
¿Qué enfoque proporciona a la empresa más capacidad de desarrollo para mejorar el tiempo de inicio, corregir fugas de memoria, pulir las interacciones, mejorar la accesibilidad, reducir los fallos y atender a los usuarios?
No es evidente que las aplicaciones nativas den lugar al mejor producto.
Esto crea una paradoja interesante: un framework que consume algo más de recursos de la máquina puede permitir a una empresa desarrollar un producto mejor optimizado porque consume muchos menos recursos de desarrollo.
Electron te ofrece una plataforma controlada
Electron también tiene otra ventaja que es fácil pasar por alto: incluye el entorno de ejecución de Chromium con el que se desarrolló y probó la aplicación.
Eso elimina una variable importante del desarrollo multiplataforma.
Los frameworks basados en las vistas web del sistema operativo pueden producir aplicaciones más pequeñas, pero la contrapartida es que el mismo frontend puede ejecutarse en WebView2 en Windows, WKWebView en macOS y WebKitGTK en Linux. Esos motores tienen distintas capacidades, errores, calendarios de lanzamiento y comportamientos de renderizado.
Electron elige una solución de compromiso distinta: incluir el entorno de ejecución y convertirlo en parte de la aplicación.
Sí, eso ocupa espacio en disco.
Pero ofrece a los desarrolladores un entorno de destino mucho más coherente entre tres sistemas operativos muy diferentes.
La coherencia tiene un enorme valor para el desarrollo.
Cuando Electron no es suficiente, puedes seguir recurriendo al código nativo
Elegir Electron no significa renunciar al acceso a las capacidades nativas.
Las aplicaciones Electron pueden utilizar módulos nativos y código específico de cada plataforma cuando sea necesario. Eso significa que la elección arquitectónica no es realmente:
100 % nativo o 100 % JavaScript.
Para muchos productos, un modelo mejor es:
la mayor parte de la aplicación compartida, con una pequeña cantidad de código nativo donde el sistema operativo realmente lo requiera.
El código nativo se convierte en una vía de escape en lugar de ser la base de todo el producto.
Para muchas empresas, eso supone una distribución mucho mejor del esfuerzo de desarrollo.
A los usuarios les importan los productos, no los frameworks
Hay un pequeño grupo de usuarios con conocimientos técnicos avanzados que abren el Monitor de Actividad, ven varios procesos de Chromium y se quejan de inmediato de que una aplicación utiliza Electron.
La mayoría de los usuarios no lo hacen.
No les importa que Slack utilice Electron. No les importa que VS Code esté desarrollado con tecnologías web. No saben qué framework utiliza Claude. Les importa que el software les ayude a hacer su trabajo.
Si una aplicación se inicia lo bastante rápido, responde con agilidad, rara vez falla y resuelve el problema del usuario, la tecnología utilizada para implementarla es en gran medida invisible.
Lo contrario es igualmente cierto. Una aplicación nativa no se convierte automáticamente en un buen producto por utilizar Swift o WinUI.
El software compite a nivel de producto, no de framework.
Optimiza la empresa, no solo el binario
Electron tiene costes reales. Utiliza más espacio en disco. Su consumo de memoria de base suele ser mayor que el de una aplicación nativa pequeña. Sin duda hay productos para los que esos costes hacen que Electron sea la elección equivocada.
Una pequeña utilidad de la barra de menús probablemente no necesita Chromium. Un controlador de dispositivo, desde luego, tampoco. Los juegos, el software de audio profesional y las aplicaciones extremadamente sensibles a la latencia tienen requisitos diferentes. Y si tu producto solo va a ejecutarse en un sistema operativo, el desarrollo nativo resulta mucho más fácil de justificar.
Pero un enorme porcentaje del software de escritorio moderno no pertenece a esas categorías.
Consiste en interfaces complejas conectadas a servicios en la nube. Necesita ejecutarse en Windows y macOS, y cada vez más usuarios esperan también soporte para Linux. Necesita evolucionar continuamente. Compite con productos que publican cambios todas las semanas. Y normalmente lo desarrolla una empresa con un número limitado de desarrolladores.
Para esos productos, la productividad de los desarrolladores forma parte del rendimiento de la aplicación.
Electron permite a una empresa contratar de una reserva de talento mucho mayor, compartir desarrolladores entre la web y el escritorio, mantener una aplicación principal en lugar de varias, reutilizar el ecosistema de JavaScript, publicar funciones en distintos sistemas operativos de forma más coherente, dar soporte a Linux a un coste que de otro modo a menudo sería difícil de justificar y dedicar más tiempo de desarrollo a mejorar el producto en lugar de mantener implementaciones paralelas.
Puedes medir fácilmente el coste de Electron en megabytes.
Los costes de la alternativa son más difíciles de ver. Aparecen en forma de desarrolladores adicionales, implementaciones duplicadas, ciclos de lanzamiento más largos, errores específicos de cada plataforma, dificultades de contratación, silos organizativos, usuarios de Linux sin soporte y funciones que tardan meses más en llegar a todos.
Esos costes no aparecen en el Monitor de Actividad.
Pero, para la empresa que desarrolla el software, pueden ser considerablemente mayores.
El objetivo del desarrollo de software no es producir el binario más pequeño.
Es crear el mejor producto que tu organización pueda lanzar, mantener y mejorar continuamente.
Para un conjunto sorprendentemente amplio de aplicaciones de escritorio, Electron sigue siendo una de las formas más eficientes de hacer precisamente eso.