Demasiadas apps para Mac se están construyendo con Electron

Artículo original ↗ Discusión en Hacker News ↗

Muchos usuarios de Mac están frustrados porque aplicaciones de escritorio populares como Slack, WhatsApp y Teams están construidas con Electron, argumentando que estas capas basadas en la web están infladas, tardan en arrancar y desperdician RAM en comparación con el software nativo de macOS. Otros responden que Electron reduce drásticamente el costo de desarrollo, permite paridad de funciones en Windows, macOS, Linux y la web, y a menudo representa la única forma viable de que las empresas publiquen un cliente de escritorio. El intercambio plantea preguntas más amplias sobre si las plataformas deberían priorizar la eficiencia y la UX nativa, invertir en mejores herramientas multiplataforma o aceptar que las apps cada vez más centradas en la web sean el estándar práctico.

Propósito y compensaciones de Electron

  • Muchos sostienen que Electron es aceptable o incluso esencial: permite apps multiplataforma y versiones web con código compartido, especialmente para startups y empresas financiadas por VC.
  • Enmarcado común: elige dos de tres: bajo precio, paridad de funciones, rendimiento. Para apps como Slack, Discord, Spotify y WhatsApp, usuarios y empresas han elegido en su mayoría precio + paridad por encima del rendimiento.
  • Otros responden que esta mentalidad de “suficientemente bueno” normaliza el bloat y una mala UX, obligando a los usuarios a comprar máquinas cada vez más rápidas para ponerse al día.

Desarrollo nativo frente a multiplataforma

  • Las apps nativas para Mac son elogiadas por ser más rápidas, más ligeras y más integradas (BBEdit, iTerm, Transmit, clientes nativos de Telegram).
  • Pero construir y mantener apps nativas separadas por plataforma se describe como algo muy costoso y organizativamente complejo; la rotación de plataformas en Apple (Toolbox/Carbon/AppKit/SwiftUI, Objective-C/Swift) empeora esto.
  • Se mencionan kits de herramientas alternativos (Qt, wxWidgets, QML, Avalonia, Flutter, Godot) como un “punto intermedio”, y algunos afirman que pueden verse modernos y ser altamente eficientes, mientras otros dicen que siguen “apestando, solo un poco menos” que Electron.

Rendimiento, uso de recursos y UX

  • Las anécdotas van desde WhatsApp abriéndose en ~1 segundo en Macs recientes hasta tardar 16 segundos o varios minutos en sincronizar historiales grandes. Algunos culpan a la app, otros al hardware o a la configuración.
  • Se critica Electron por la sobrecarga de múltiples procesos y el alto uso de RAM/CPU; las réplicas señalan que algunas apps nativas son igual de pesadas y que Electron no siempre es el cuello de botella.
  • Ejemplos: el nuevo Teams se percibe como extremadamente lento; Slack y Outlook se ven como aceptables; Apple Music se critica como una app nativa con retrasos y errores, comparada con Spotify basada en Electron.

Pestañas del navegador, PWA y “solo usa la web”

  • Algunos prefieren ejecutar servicios como Slack/WhatsApp en pestañas del navegador por las extensiones, el flujo de trabajo con pestañas y para evitar instalaciones de apps de varios cientos de MB.
  • Otros valoran las apps de escritorio por los iconos en el dock, el cambio con Cmd-Tab, la gestión de apps a nivel del SO, las insignias y las notificaciones.
  • Las PWA dividen opiniones: la idea gusta, pero algunos creen que socavan entornos de navegador controlados por el usuario y que obtienen APIs exclusivas. Se menciona con frustración que Firefox haya abandonado el soporte para PWA.

Economía e incentivos empresariales

  • Varios comentarios enfatizan que las apps Electron a menudo “compiten con no existir en absoluto”, especialmente en macOS y Linux.
  • Coordinar equipos nativos paralelos, mantener la paridad de funciones y manejar diferencias entre plataformas se presenta como una gran carga frente a una sola pila Electron/Web.
  • Algunos sugieren que Apple podría mitigar esto haciendo que Swift/SwiftUI sea más multiplataforma, pero dudan de que Apple lo haga.

APIs y clientes nativos de terceros

  • Una línea de argumento: los servicios no deberían lanzar apps nativas en absoluto; deberían exponer APIs completas y dejar que desarrolladores independientes construyan clientes nativos.
  • Ejemplo histórico: el ecosistema de apps de terceros de Twitter floreció antes de ser recortado por la empresa.
  • Objeciones: este tipo de apps envoltorio son “aburridas”, difíciles de monetizar a escala y pueden verse socavadas cuando las plataformas cambian las reglas de autenticación o prohíben clientes no oficiales. Se cita como víctima tanto de la economía como de la política de plataforma a un cliente ligero de Slack/Discord ya discontinuado.

Críticas al artículo y a Apple

  • Algunos ven el artículo como un sesgo de “propaganda pro Mac nativo”, especialmente dado que está alojado en el blog de una app solo para Mac y compara un editor de texto local con un mensajero rico con sincronización en la nube.
  • Otros acusan a Apple de tener máquinas caras y con poca RAM que hacen que los usuarios sean inusualmente sensibles al bloat, y señalan que las propias apps nativas de Apple (por ejemplo, Music, Reminders) a menudo se sienten lentas o mal diseñadas.
  • Aun así, un grupo insiste en que la UX nativa es notablemente mejor, incluso si las fuerzas del mercado hacen que muchas apps nunca vayan a ser nativas.