Por qué esa app de escritorio te deja con cara de "esto no va bien"

Hablemos claro. Has instalado una aplicación de escritorio y algo no termina de convencerte. Funciona, sí, técnicamente está bien. Pero se siente... rara. El texto apenas se lee. La ventana se comporta de formas impredecibles. Y esa aplicación que prometía ser "ligera" te está devorando la RAM como si no hubiera un mañana.

Si esto te suena familiar, probablemente tienes una app de Electron.

El concepto: web developers al rescate del escritorio

Electron es un framework que permite crear aplicaciones de escritorio usando las mismas tecnologías que funcionan en la web: HTML, CSS y JavaScript. La propuesta suena lógica: si ya tienes desarrolladores web, ¿por qué no aprovechar ese conocimiento para crear apps de escritorio?

Imagina no tener que aprender Swift para macOS, C# para Windows o Qt para Linux por separado. Un solo equipo, un solo código base, tres sistemas operativos. Para startups con recursos limitados, esto parece un chollo.

El problema es lo que nadie menciona en el folleto de ventas.

El problema del gabán

Hay una frase que lo describe perfectamente: las apps de Electron son navegadores web disfrazados. Y no es exageración. Debajo de esa interfaz que simula ser nativa, hay una instancia completa de Chromium funcionando. Un motor de JavaScript completo. Un motor de renderizado completo. Y todo el peso que eso implica.

El resultado práctico es una cliente de correo que consume más memoria que un videojuego en 3D. Una aplicación de notas que tarda tres segundos en abrirse. Una "utilidad ligera" que permanece en segundo plano consumiendo recursos como si estuviera minando bitcoins.

La ironía: la versión web funciona mejor

Aquí está lo que más me fastidia de todo esto. En muchos casos, la versión web de una aplicación funciona mejor que su homóloga de escritorio construida con Electron. El mismo código, las mismas funcionalidades, pero de alguna forma el navegador responde más rápido, se siente más ágil.

¿Por qué ocurre esto? Los navegadores web llevan décadas optimizándose. Los fabricantes compiten activamente por el rendimiento. Los componentes de renderizado web de tu sistema operativo se actualizan automáticamente con los parches de seguridad. En cambio, las apps de Electron incluyen su propia versión de Chromium, congelada en el tiempo hasta que el desarrollador decida actualizarla... si es que alguna vez lo hace.

Esto no es paranoia teórica. Investigadores de seguridad han documentado casos donde aplicaciones Electron incluían vulnerabilidades conocidas en sus componentes de Chromium empaquetados. Ese navegador donde estás leyendo esto probablemente se ha actualizado tres veces desde que empezaste. ¿Esa app de Electron en tu escritorio? Podría estar ejecutando código de hace dos años.

La multa por mala usabilidad

Hablemos de la experiencia de uso. Cuando abres una app nativa en macOS o Windows, tienes expectativas. Esperas que Cmd+Desplazamiento amplíe el texto. Que las ventanas se redimensionen sin tirones. Que los atajos de teclado funcionen igual que en el resto de tus aplicaciones.

Las apps de Electron frecuentemente rompen estas expectativas. No porque los desarrolladores sean negligentes —muchos de ellos se preocupan genuinamente— sino porque están trabajando dentro de un framework que nunca fue diseñado para replicar el comportamiento nativo. Es como pedirle a un pez que suba a un árbol y luego preguntarse por qué está agotado.

He perdido la cuenta de las veces que he tenido que rebuscar en menús de configuración solo para hacer legible el texto de una app Electron, probando cambios adelante y atrás para verificar si funcionaban. En la web, simplemente haría Ctrl+ o usaría el gesto de pinza en el trackpad. Pero aparentemente, eso es tecnología demasiado avanzada para algunas aplicaciones de escritorio.

WebViews: el término medio con el que nadie está contento

Entonces, ¿cuál es la alternativa? Algunos desarrolladores están recurriendo a WebViews: componentes a nivel de sistema que renderizan contenido web usando el motor de renderizado propio del sistema operativo. Es más eficiente que Electron porque el motor web se comparte entre todas las aplicaciones y recibe actualizaciones de seguridad a través del sistema operativo.

Pero los WebViews tienen sus propios problemas. Diferentes sistemas operativos usan diferentes motores web. Tu aplicación podría verse ligeramente distinta en Windows, macOS o Linux. Esa promesa de "escribe una vez, ejecuta en cualquier lugar" empieza a agrietarse.

La verdad honesta es que no existe una solución perfecta. Las apps nativas ofrecen el mejor rendimiento y experiencia de usuario, pero requieren bases de código separadas para cada plataforma. Electron ofrece comodidad en el desarrollo a costa de uso de recursos y seguridad. Los WebViews dividen la diferencia de forma incómoda.

¿Qué deberías hacer?

Si eres desarrollador y estás construyendo aplicaciones de escritorio, te animo a evaluar honestamente si Electron es la elección correcta. Piensa en tus usuarios. Ten en cuenta que alguien podría describir tu app en redes sociales como "un navegador web con gabán". Considera que "en mi máquina funciona" adquiere un significado completamente nuevo cuando estás enviando un navegador completo junto con tu código.

Si eres usuario, no te sientas culpable por quejarte de esa app Electron que va lenta. Tu frustración es legítima. La multa de memoria, la interfaz inconsistente, el texto demasiado pequeño para leer —estos no son problemas menores. Impactan directamente en tu flujo de trabajo y merecen ser atendidos.

Al final del día, deberíamos estar construyendo herramientas que respeten tanto a desarrolladores como a usuarios. A veces eso significa elegir la comodidad. A veces significa hacer el esfuerzo adicional de hacerlo bien. La pregunta no es si Electron es bueno o malo —es si es la elección correcta para lo que intentas lograr.

La metáfora del gabán funciona porque fundamentalmente trata sobre el disfraz. Las apps de Electron a menudo se sienten como si estuvieran fingiendo ser algo que no son. Quizás es hora de dejar de fingir y empezar a construir software que sepa lo que quiere ser.