¿Perdimos el rumbo en el desarrollo de software eficiente?

La dificultad de abrir archivos de Microsoft Word en Google Docs

• El padre del autor tuvo que instalar Word en su laptop para trabajar con un archivo de documento de Microsoft Word
• El autor le sugirió usar Google Docs
  • Su padre ya tenía una cuenta de Google, era fácil de usar, estaba basado en la nube y se sincronizaba automáticamente
• Sin embargo, al abrir en Google Docs un archivo de documento de unos 30 MB, Chrome o Google Docs no podían manejarlo bien; por ejemplo, el texto escrito tardaba varios segundos en mostrarse en pantalla
• Al final instalaron LibreOffice, y ahí funcionó muy rápido

Reflexión sobre los estándares actuales del software

• Surge la duda de si el desarrollo de software está retrocediendo en términos de rendimiento
  • Si las herramientas, frameworks y lenguajes modernos, vistosos y recientes nos están haciendo retroceder en eficiencia
• Las especificaciones de hardware están aumentando para poder manejar web apps y navegadores
  • Si solo existieran apps nativas puras, eso sería innecesario
  • Por qué un teléfono móvil necesita 8 GB o 16 GB de RAM
• La web necesita renderizado nativo en lugar de envoltorios sobre motores de renderizado de UI
  • La razón por la que no se puede abrir un archivo de Word de 30 MB en Google Docs, incluso en una laptop potente, es que el navegador requiere más memoria y uso de CPU
• Parece que hemos perdido la forma de desarrollar aplicaciones optimizadas, eficientes y con buen rendimiento. Hay que resolver este problema
  • La computadora Apollo de 1966, con 2 KB de RAM, llevó a la humanidad a la Luna, pero en 2024 no podemos manejar un archivo de documento de 30 MB en el navegador
• Hoy, como toda la industria está enfocada en aplicaciones PWA de cara al futuro, el enfoque está puesto en la web

La importancia de optimizar las API

• La optimización de API es importante tanto en apps web como nativas, ya que el rendimiento de las API puede contribuir al rendimiento de la app
• El producto del autor, Onradar(https://onradar.io), ayuda con la optimización mediante monitoreo de API
  • Onradar ofrece monitoreo de disponibilidad y monitoreo basado en flujos para API
  • En el editor de flujos se pueden crear escenarios de usuario posibles con las API relacionadas y dejar que Onradar los pruebe 24/7
  • Proporciona alertas cuando ocurre un incidente

La opinión de GN⁺

• Los problemas de compatibilidad entre Google Docs y MS Office han sido señalados durante mucho tiempo. Aún no se han resuelto por completo y siguen causando molestias a los usuarios. Ojalá ambas empresas colaboren de forma más activa para resolver este problema
• Resolver los problemas de rendimiento de las web apps aumentando las especificaciones del hardware no es una solución de fondo. Se necesita desarrollo de software que use de manera eficiente recursos limitados
• Apostar por las apps nativas es una opción, pero sería mejor mejorar el rendimiento de las web apps aprovechando las ventajas de la web. La portabilidad y accesibilidad de las web apps son ventajas difíciles de abandonar
• La optimización y el monitoreo de API son factores importantes que pueden contribuir a mejorar el rendimiento de todo el sistema. En especial ahora que la arquitectura de microservicios se está volviendo la norma, es inevitable que aumente el interés en la capa de API
• Compararlo con la era de Apollo no parece adecuado. Es difícil poner en el mismo plano el control de una nave espacial y el procesamiento de texto. El software actual se ha vuelto tan grande y complejo que es difícil esperar la eficiencia de la época de Apollo

[GN⁺]

Opinión de Hacker News

Resumen:

• Apple y Microsoft dificultan el desarrollo de apps nativas al exigir cuentas de desarrollador, comprar certificados para firmar binarios y compartir ingresos. La web es una alternativa mucho más simple y barata.
• Gracias a la ley de Moore, el software se ha beneficiado durante décadas de las mejoras del hardware sin hacer mucho esfuerzo. Eso ha sido tanto una bendición como una maldición.
• A los desarrolladores les encanta una plataforma de cómputo universal, totalmente integrada y conectada: la web. A los usuarios no les importa demasiado si el rendimiento es lo suficientemente bueno. Hacer buen software no parece importar.
• Las decisiones de negocio son la causa principal:
  1. Mudanza a la nube: las empresas prefieren suscripciones recurrentes y los clientes ya no necesitan contratar su propio equipo de TI
  2. Los clientes se niegan a actualizar el software on-premise, lo que alarga los ciclos de mantenimiento y hace que los parches se acumulen sin fin
  3. El desarrollo web cuesta menos que desarrollar para múltiples plataformas
• A principios de los 90, MS Word se distribuía en disquetes y su ejecutable pesaba 2 MB. Hoy se mide en GB, pero no está claro qué ha mejorado.
• Sí existe software liviano, pero no suele elegirse. Hay excelentes opciones ligeras como Lua, SQLite, Fennel, Althttpd, Fossil y Mako Server.
• En frontend se suelen preferir las apps nativas y las páginas web, pero webapps como Tiddlywiki también tienen sus ventajas. Aun así, siguen usando más recursos que Emacs.
• Hubo un caso en el que, al cambiar de página en React, un menú desplegable tardaba mucho en renderizarse. Al final se resolvió modificando el código de React.
• Como las empresas les dan a los desarrolladores equipos de alto rendimiento, surge el problema de que ya no se prueba lo suficiente en PCs comunes y antiguos.
• Se ven muchos posts sobre "código idiomático" y "la optimización de rendimiento es la raíz de todo mal", así que se termina valorando más el tiempo de desarrollo. Antes había desarrolladores que escribían mejor código y más rápido.