Una plegaria de 2024 por software ligero

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

El software se ha vuelto cada vez más voluminoso, y hasta las herramientas simples agrupan enormes árboles de dependencias, runtimes pesados como Electron e instaladores de gigabytes, lo que genera preocupación por la seguridad, el rendimiento y el despilfarro. Los comentaristas lo contrastan con alternativas más ligeras del pasado y del presente, argumentando que los incentivos del mercado, las habilidades de los desarrolladores y las demandas multiplataforma empujan a los equipos hacia la conveniencia en lugar de la eficiencia. Las soluciones propuestas van desde cambios culturales y mejores herramientas hasta regulación y APIs abiertas, aunque muchos dudan de que el bloat pueda revertirse de forma significativa.

Servicios simples/autohospedados vs servicios fáciles de usar

  • Varios comentarios señalan que se pueden construir herramientas extremadamente ligeras (por ejemplo, intercambio básico de imágenes/pegado mediante un servidor web + SSH/FTP/NFS + pequeños scripts).
  • Otros responden que los usuarios no técnicos viven casi por completo en el navegador; pedirles que aprendan FTP/SFTP o montajes es una barrera real.
  • Para familiares/amigos autohospedados, algunos sostienen que basta con enseñar o preinstalar herramientas como FileZilla, sistemas de archivos SFTP o herramientas de sincronización en lugar de crear frontends de subida personalizados.

Ejemplo de intercambio de imágenes, rendimiento y privacidad

  • Algunos critican la app de demostración del artículo por no redimensionar ni optimizar las imágenes y por servir miniaturas del tamaño completo, llamándolo “optimizar lo incorrecto” (tamaño binario frente a ancho de banda).
  • Debate sobre EXIF: un lado dice que no eliminar metadatos es un riesgo serio de privacidad/seguridad en muchos contextos; otros dicen que esto trata más de la responsabilidad del usuario o puede ser una función para compartir de forma privada.
  • Hay desacuerdo sobre si esto hace que el artículo sea “hipócrita” o simplemente “inacabado”.

Incentivos y causas del bloat

  • Varios comentarios culpan a los incentivos organizacionales: lanzar rápido trae ascensos; la ingeniería cuidadosa y ligera parece “improductiva”.
  • El bloat también resulta de decisiones de seguridad/portabilidad: enviar todo (controladores, runtimes, mapas de depuración) es más fácil que recortar por plataforma.
  • Algunos sostienen que el bloat es inevitable a medida que crecen las capacidades; otros creen que se debe sobre todo a la cultura y las prioridades de los desarrolladores.

Electron, stacks web y toolkits GUI

  • Muchos ven Electron y el “web en una caja” como emblemáticos del bloat (descargas enormes, alto uso de RAM/CPU para apps simples).
  • Sus defensores señalan que Electron reduce drásticamente el costo de desarrollo multiplataforma, aprovecha la abundancia de desarrolladores web y acelera la iteración de la UI.
  • Alternativas mencionadas: Qt, JavaFX, Avalonia, Tauri, Slint, apps “pesadas” nativas como Telegram. Los compromisos incluyen licencias (Qt), madurez de herramientas y dificultad para contratar.
  • Algunos piensan que sin Electron muchas apps de escritorio (especialmente en Linux) quizá no existirían; otros dicen que las pilas nativas son perfectamente viables.

Librerías, empaquetado y compartidas vs estáticas

  • Discusión sobre el tamaño de Mesa y dónde “trazar la línea” entre complejidad necesaria y sobreenvío.
  • Argumentos a favor de librerías compartidas (centralizadas, más ligeras en disco/RAM) frente a binarios estáticos (despliegue más simple, menos dependencias ocultas).
  • Los gestores de paquetes pueden ocultar la complejidad real: apt install no da ninguna pista sobre si estás incorporando un motor de navegador completo o un binario estático pequeño.

¿Está empeorando la calidad del software?

  • Un bando dice que las apps modernas (especialmente Electron) son claramente peores: herramientas triviales que usan cientos de MB de RAM/CPU y patrones de UX deficientes comparadas con antiguas interfaces nativas.
  • Otro bando dice que el software del pasado (por ejemplo, el escritorio de los 90) también era notoriamente defectuoso e inseguro; la nostalgia puede sesgar.
  • Una visión más matizada: hubo un “período dorado” (~2003–2013) con toolkits nativos sólidos y mejores prácticas de ingeniería, seguido de una regresión impulsada por las presiones multiplataforma de la web y el móvil.

Ejemplos de bloat vs ligereza

  • Bloat reportado:
    • Notion Calendar ~84 MB.
    • Firefox como Snap consumiendo cientos de MB por versión.
    • Binario “client” de ClickHouse ~900 MB porque incluye servidor/herramientas.
    • Instaladores de QGIS para Windows alrededor de 1 GB y creciendo.
  • Contraejemplos más ligeros:
    • Antiguo cliente Ventrilo de unos pocos MB y RAM mínima.
    • Algunas apps de escritorio Qt/JavaFX mantenidas por debajo de ~30–140 MB y decenas de MB de RAM con cuidado.
    • Una herramienta reducida de 33 MB a 1,4 MB eliminando partes innecesarias (los detalles no se describen por completo).

Regulación, cadena de suministro y APIs

  • Nueva legislación de seguridad y obligaciones de actualización a largo plazo ya están empujando a algunas organizaciones a replantearse la proliferación de dependencias.
  • Algunos proponen mejores herramientas y métodos formales ligeros para razonar sobre enormes grafos de dependencias, en lugar de esperar que el bloat desaparezca.
  • Otros abogan por APIs abiertas para que los usuarios puedan elegir clientes alternativos y ligeros en lugar de verse obligados a usar los oficiales, más voluminosos.

Sistemas operativos y modelo de seguridad

  • Una línea de discusión culpa a los modelos de seguridad de los sistemas operativos: los sistemas del pasado (por ejemplo, configuraciones basadas en disquetes) aplicaban implícitamente límites simples de capacidades, mientras que los SO modernos permiten código arbitrario con acceso amplio, haciendo que los enormes árboles de dependencias de hoy sean más peligrosos.