¿Perdimos el rumbo en el desarrollo de software eficiente?

• Al intentar editar en el navegador un documento de Word de unos 30 MB, se experimentó retraso al escribir, lo que sirvió como ejemplo tangible del costo de rendimiento de las apps web modernas
• Aunque el documento era principalmente texto e incluía solo algunas imágenes y tablas, Google Docs o el entorno de Chrome no pudieron manejarlo con fluidez
• En LibreOffice, instalado en lugar de Microsoft Office de pago, el mismo documento funcionó mucho más rápido, resaltando la diferencia entre las apps web y las apps nativas
• A medida que las aplicaciones web modernas exigen más memoria y CPU, surge la preocupación de que el aumento en las especificaciones del hardware esté ligado a las apps web intensivas en recursos
• Incluso en un contexto de expansión de las PWA y las interfaces basadas en navegador, la renderización nativa y un diseño de software eficiente siguen siendo importantes para la usabilidad real

---

El problema de rendimiento de las apps web que reveló un documento de 30 MB

• Google Docs fue la primera opción porque permite aprovechar una cuenta de Google y la sincronización automática en la nube
• Tras subir el documento a Google Docs y empezar a escribir, las letras tardaban varios segundos en aparecer en pantalla
• El archivo pesaba unos 30 MB y, aunque tenía algunas imágenes y tablas simples, en su mayoría era texto
• Se concluyó que Chrome o Google Docs no lograban procesar correctamente este documento
• Microsoft Office se descartó por ser de pago y, en cambio, en LibreOffice el mismo documento funcionó con mucha rapidez

La pregunta más amplia sobre la eficiencia

• Esto lleva a preguntarse si las herramientas, frameworks y lenguajes modernos están haciendo que el software sea más pesado en términos de rendimiento
• Se plantea que las especificaciones de hardware han aumentado para soportar aplicaciones web intensivas en recursos, y que esos requisitos podrían haber sido menores si solo existieran apps nativas puras
• Se cita como ejemplo la situación en la que los dispositivos móviles necesitan 16 GB de RAM, cuestionando el aumento en el uso de recursos del software
• Se considera que la web debería alcanzar una eficiencia comparable a la de la renderización nativa, en lugar de quedarse como una simple envoltura de motor de renderizado de UI
• El contraste entre la computadora Apollo de 1966, que hizo posible el alunizaje con 2 KB de RAM, y un navegador de 2024 que tiene dificultades incluso para trabajar con un documento de unos 30 MB, subraya la necesidad de optimización

[GN⁺]

Opiniones de Hacker News

• Aunque quiera crear apps nativas, siento que Apple y Microsoft siguen poniendo trabas. Hay que bancarse cuentas de desarrollador, certificados de firma de binarios e incluso una comisión del 30% sobre los ingresos sin mucha razón; en particular, las API de Microsoft han cambiado de forma confusa
  Por eso uno termina eligiendo la web, que es más simple y barata

  • En macOS, el Apple Developer Program solo es necesario si quieres firmar binarios o distribuir en la Mac App Store. Microsoft también solo cobra si subes algo a Microsoft Store o si usas Visual Studio en una empresa que supera cierto tamaño
    Las apps sin firmar pueden ejecutarse tanto en Windows como en macOS, aunque muestran más advertencias. La comisión del 30% también aplica solo si usas la Mac App Store o Microsoft Store, y parece que Microsoft Store no cobra comisión si no es un juego y usas tu propio sistema de pagos
  • Una de las razones por las que, tras muchos años de desarrollo en C/C++, me pasé al desarrollo web con JavaScript fue esta. El proceso para subir una app de iPhone a la Apple App Store era un infierno, mientras que una app web no necesita licencias, aprobaciones ni instaladores
  • Dicho sin vueltas: con Microsoft, crear una cuenta de desarrollador, firmar binarios y compartir el 30% de los ingresos no es obligatorio. Tampoco veo las API de Microsoft como un desastre; hay opciones como Win32, .NET y UWP, y funcionan bastante bien y son flexibles
    No conozco tan bien el caso de Apple, pero probablemente se puedan crear apps para Mac sin cuenta de desarrollador; para iPhone sí hace falta. El precio que vi antes era de US$99 al año, y si piensas hacer una app en serio, no es mucho dinero
  • Si integras pagos con tarjeta directamente en la web, tienes que pagarle a Stripe 2.9% + 30¢. Recién cobrando 10 dólares la comisión por transacción baja a alrededor del 6%, así que aparecen restricciones de precio mínimo y de modelo de cobro
    Gestionar contracargos y reembolsos también cuesta, y tienes que dedicar tiempo a soporte al cliente o contratar a alguien. Si facturas menos de 1 millón de dólares al año, la comisión de Apple es del 15%, así que para apps baratas o apps de valor agregado, Apple puede ser un mejor trato que procesar pagos directamente
  • Al crear apps nativas para macOS, Windows y Linux nunca tuve que hacer nada de eso; simplemente uso Qt

• Es irónico que este artículo esté publicado en Medium, que descarga 10.88 MB para un texto de 265 palabras

  • Desde el punto de vista de Medium, los anuncios son el verdadero contenido. El artículo es el vehículo que transporta hasta el navegador el contenido real, que son los anuncios, y entregar anuncios requiere mucha complejidad
  • Mirando con about:process de Firefox, incluso 10 minutos después de terminar de cargar, este artículo seguía usando 239 MB de memoria y entre 0.06% y 0.2% de CPU; parece que el 45% del tiempo de CPU lo consume Google reCAPTCHA
    Ojalá organizaciones como Mozilla o Google recopilaran estadísticas de uso de CPU, memoria y energía por dominio, y avergonzaran públicamente a los desarrolladores a los que no les importa el rendimiento
  • Los navegadores se volvieron más grandes que la mayoría de los sistemas operativos, y el ecosistema también se siente cerrado. WASM todavía tiene muchas limitaciones, y en desarrollo web las únicas opciones realmente viables son JS/HTML/CSS
    La web vuelve a sentirse como en 2005. Solo que esta vez los pop-ups están incrustados dentro de la página
  • En estos casos abro gemini://gemi.dev/bin/waffle.cgi en el navegador Gemini y pego la URL. Quienes no usan la red Gemini pueden cambiar medium.com por scribe.rip en la URL
  • En navegadores en modo texto se ve bien

• Sí, nos perdimos, y la razón es simple: porque podíamos hacerlo. Era el camino de menor resistencia, así que tomamos ese camino
  Durante décadas, el software se subió gratis a la ola de los avances del hardware, sobre todo en la web y en las apps de escritorio. La ley de Moore fue tanto una bendición como una maldición, y el software que usamos hoy lo crearon personas que aprendieron tecnología en pleno auge de ese viaje gratis

  • Me vuelve loco que lo que hacemos con las computadoras sea casi lo mismo cada año, pero el software se vuelva cada vez más pesado. Todavía en 2010, una distro de Linux con entorno de escritorio usaba 100 MB de RAM justo después de iniciar, y una versión optimizada rondaba los 60 MB
    Hoy una computadora con menos de 8 GB es inutilizable, y hasta 8 GB apenas alcanzan. El software nuevo usa Electron y consume al menos 1 GB de RAM, y todo, incluidos los navegadores, usa cantidades absurdas de memoria
    Windows es todavía más incomprensible. Cada vez que ayudo a mi mamá con su computadora, que tiene un i5 reciente y 8 GB de RAM, está lentísima, y el arranque, la ejecución de programas y las actualizaciones tardan mucho. Si una computadora tarda más de un minuto en arrancar, me dan ganas de tirarla por la ventana
  • Es cierto. Creo que muchos de los problemas difíciles del software no se resolvieron, sino que se esquivaron. Los contenedores son un ejemplo perfecto
    No resolvimos la distribución de aplicaciones en múltiples lenguajes y entornos; la evitamos con motores de contenedores. Si el usuario quiere, podríamos darle un script de build que instale compiladores y herramientas, pero como eso es difícil de probar bien, terminamos usando contenedores
    Redbean y Cosmopolitan libc parecían lo más cercano a “resolver” este problema. Si quieres que los usuarios distribuyan apps de manera fácil y confiable, los contenedores tienen ventaja competitiva, y con eso llegan de inmediato más de 100 MB de disco y un motor de contenedores
  • Si llevas la lógica de “porque se puede” hasta enjambres de bots asesinos con IA, terminas en Slaughterbots
    Mientras la competencia entre países o empresas sea el principio central del desarrollo tecnológico, será difícil controlar crisis globales como el cambio climático, la destrucción de ecosistemas y la IA letal. Necesitamos colaboración y cooperación como principios organizativos de más alto nivel; la competencia genera enormes externalidades negativas para todo el planeta
  • No estoy de acuerdo. La causa son los frameworks y las funciones de seguridad de los sistemas operativos, como la telemetría, y sus bibliotecas
    Los programas escritos en Lazarus, es decir, Free Pascal, funcionan muy rápido incluso en Windows modernos como Windows 11. Mantener software de escritorio escrito para un propósito específico es lo mejor para la velocidad y la estabilidad
    Toda modernización del software, tanto del hardware como de los frameworks, actúa como un impuesto sobre todas las funciones existentes
  • Me gusta la expresión “camino de menor resistencia”. Siento que sobre ese camino se esparció una enorme cantidad de desarrollo impulsado por el currículum
    La complejidad se acumuló exactamente en los lugares equivocados

• Estas quejas se repiten, pero en la práctica es un estado que nadie desea de verdad
  A los desarrolladores les gusta la web, una plataforma de cómputo de propósito general totalmente integrada y conectada, y los usuarios parecen no preocuparse demasiado por el rendimiento mientras sea lo suficientemente aceptable. Al final, se permite que el software empeore hasta el punto en que no irrite demasiado a los usuarios
  A la gerencia tampoco le interesa hacer mejor software si ya se desarrolló uno suficientemente bueno. Nada cambia a menos que alguien decida que hace falta una salida drástica, y desde ningún punto de vista hay muchos incentivos para cambiar

  • La gente claramente se queja del rendimiento y del tamaño de descarga, pero normalmente lo expresa hablando de efectos secundarios. Preguntan por qué la laptop se calienta o por qué el iPhone “se congela”
    Las personas que descargan apps grandes en teléfonos con poca señal, viven en zonas con internet inestable o usan dispositivos viejos en sectores de bajos ingresos o países en desarrollo se frustran con apps grandes y lentas. Si sientes que a nadie le importan el rendimiento y el tamaño de las apps, quizá les estás haciendo las preguntas equivocadas a las personas equivocadas
  • La hinchazón del software no es un fenómeno nuevo. Hay quejas al menos desde mediados de los años 90, y quienes llevan más tiempo dirían que se remontan a los 80 o incluso a los 70
    Con el tiempo, los que se quejan terminan pareciendo los raros, y el resto actualiza, soporta la hinchazón o sigue usando software viejo
    Pero también hay que mirar los beneficios que trae esa hinchazón. Si Google Docs no fuera más que un clon de Word, no se usaría tanto, pero hay gente que lo usa porque es gratis, se puede acceder desde varios dispositivos y permite una colaboración fluida
    Además, parte de lo que parece hinchazón en realidad es una mejora de conveniencia. Funciones como fuentes proporcionales que se ven bien a cualquier tamaño, fuentes Unicode, manejo de documentos más grandes que la memoria, cambiar entre documentos de trabajo y materiales, y protección de memoria consumen muchos recursos, pero mejoran la calidad de vida
  • Me pregunto si realmente es así. Quizá para los desarrolladores web, pero casi no he hecho desarrollo web directo. Una interfaz web es una elección, y la necesidad comercial de querer ingresos por suscripción y evitar ventas únicas parece ser un gran motor
    El mundo moderno basado en la nube o medio en línea es bastante antinatural desde la perspectiva del usuario, y en casos como OpenOffice, donde no existe la necesidad de monetizar, puede seguir siendo una aplicación de escritorio
  • Una de las startups exitosas era una app de una sola página que descargaba un paquete de 5 MB y leía datos por adelantado, y tardaba casi 10 segundos en iniciar
    Nadie se quejaba de eso, y aunque el rendimiento de algunas partes de la app era pésimo, las quejas de los clientes eran raras. Las quejas empezaban a aparecer recién cuando la carga rondaba los 60 segundos
    Aun así, como ese software resolvía un problema muy valioso que reducía a minutos algo que tomaba una semana, los clientes hablaban maravillas de él. A medida que la competencia se volvió más intensa hubo que mejorarlo, pero a la mayoría realmente no le importaba y siempre quedaba al final de las prioridades
  • Donde más se siente esta diferencia es al usar software que no cayó en esa trampa. Sistemas como MYOB EXO/CRM o SAP ERP han ido cambiando muy lentamente bases de código de décadas, y aunque en la práctica siguen siendo tecnología de los 2000 y todavía son incómodos de usar, eso se convierte en una gran ventaja
    Es divertido abrir el administrador de tareas y ver que usan solo 20 a 30 MB de RAM, aunque buena parte de la base de datos actual ya esté cargada. VLC y Blender son ejemplos similares

• Es interesante que la mayoría culpe a los desarrolladores, pero en la realidad todo son decisiones de negocio
  La migración a la nube ocurre porque a las empresas les gustan los ingresos estables de las suscripciones, y los clientes corporativos no tienen que contratar equipos de IT; además, la responsabilidad pasa a un tercero, por lo que pueden exigir alta disponibilidad. El rendimiento solo tiene que ser “aceptable” para el usuario final
  Los clientes que se negaban a actualizar software on-premise generaron ciclos de mantenimiento largos y parches interminables, y desarrollar una sola vez para la web es más ventajoso para el negocio que tener desarrolladores y testers separados para cada plataforma. La experiencia técnica de los desarrolladores por sí sola no puede cambiar estas fuerzas fundamentales

  • Después de cierto tiempo, ese software simplemente les funciona bien a los clientes. Photoshop es un buen ejemplo
    Quizá no puedas usar las funciones modernas más llamativas, pero en una máquina con Win7, CS4 todavía se puede usar sin costo adicional
  • También se pueden crear apps web eficientes sobre la nube. Al final, no son más que servidores
    El problema es que los desarrolladores programan en máquinas con un rendimiento que los usuarios no pueden costear y no se preocupan por el rendimiento ni por escribir código eficiente
  • Creo que muchos desarrolladores tomarían la misma decisión. Mantener versiones separadas del mismo software para cada plataforma es doloroso, y lidiar con servidores consume tiempo de desarrollo

• A principios de los 90, recuerdo que MS Word cabía en unos cuantos disquetes y que el ejecutable principal era de 2 MB. Funcionaba bien incluso en una 386 de 16 MHz con 2 MB de RAM total.
  La mayoría de lo que hacemos hoy ya lo hacía entonces; creo que solo faltaba algo como el corrector gramatical. Ahora se mide en GB y creció 1000 veces, pero no sé qué ganamos. No solo nos perdimos: ya ni sabemos cuál era el destino.

  • Lo que ganamos fueron funciones y gráficos.
    Por ejemplo, solo dict.words en Linux pesa 4.8 MB, y Arial Unicode es una fuente de unos 20 MB. Un solo ícono de una app en la que estoy trabajando pesa 400 KB, y el handler de Google Crashpad para gestionar fallos también pesa varios MB.
    Una pantalla 4K true color es 138 veces más grande que una pantalla de 640x480 con 16 colores.
  • Hace unos años, como broma del Día de los Inocentes, subí imágenes de disco de DOS/Windows 3.11 a un servidor de arranque de red PXE. Incluían un Word 6 for Windows funcional, y la imagen comprimida con gzip cabía en 12 MB.
    Las PC de esa época podían arrancar sin UEFI y, si se configuraban bien, Windows 3.11 iniciaba casi al instante y Word se abría de inmediato.
    Hoy Word tiene bastantes funciones muy pequeñas y algunas grandes agregadas, pero estoy convencido de que, si a Microsoft le importara, podría reducir el uso de memoria a una décima parte. Simplemente no hay incentivo. Las computadoras son rápidas, hay mucha memoria y ya no dependemos de disquetes, así que solo implicaría más costo.
    Creo que la hinchazón del software podría tener un impacto ambiental nada despreciable, pero no va a cambiar salvo que haya quejas lo bastante fuertes o algo como una ley de la UE contra la hinchazón del software.
    Hace poco también vi en GitHub el código fuente de MS Word for Windows 1.0. La publicación original está en el Computer History Museum y puede verse en https://computerhistory.org/blog/microsoft-word-for-windows-.... Era C puro y grandes partes estaban en ensamblador, pero el código era increíblemente desordenado comparado con los estándares, patrones y características actuales de C/C++.
  • Hace tiempo, por nostalgia, abrí Word 5.1 en una vieja PowerBook Duo que había llegado para ser descartada.
    Alguna vez leí la frase de que el software es como un gas: se expande hasta llenar el espacio disponible.
    Con las distribuciones live pasa algo parecido. Antes eran de 700 MB para que entraran en un CD-R; ahora ya cuesta encontrar algo que entre en una USB de 2 GB. Aun así, es bueno ver que lo “minimal” está ganando fuerza.
  • En la empresa, el archivo Docker que ejecuta código de machine learning pesa 6 GiB. Ni siquiera incluye los archivos del modelo.
    Nvidia, ¿qué demonios nos está haciendo descargar? ¿Miles de combinaciones de código generado que jamás vamos a usar?
  • Las funciones que tenía Word 6 son, en la práctica, las funciones que usamos incluso en el Word más reciente.
    Solo que ahora toma más tiempo encontrar lo que uno quiere entre todas las funciones infladas que se agregaron.

• El software minimalista existe, pero la gente no suele elegirlo. Dedicar bastante tiempo a escoger dependencias de forma conservadora lleva a un stack ligero y de buen rendimiento.
  Hoy prefiero herramientas como Lua, SQLite, Fennel[0], Althttpd[1], Fossil[2] y Mako Server[3]. Se puede usar software excelente, ligero, estable y eficiente gratis, pero hay que salirse un poco del camino común. No son cosas que uno escuche mencionar muy seguido en Stack Overflow.
  Con el frontend tengo sentimientos encontrados. Prefiero las apps nativas y las páginas web, pero uso Tiddlywiki todos los días y creo que las apps web tienen su lugar. Aun así, una pestaña con un archivo de Tiddlywiki de 6 MB usa 155 MB de RAM, mientras que una sesión de Emacs muy personalizada usa solo 88 MB, así que coincido con la preocupación del autor.
  [0]: https://fennel-lang.org/
  [1]: https://sqlite.org/althttpd/doc/trunk/althttpd.md
  [2]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
  [3]: https://makoserver.net/

  • Lua es la herramienta de programación más subestimada que conozco. Dominar Lua es una de las mejores formas de mejorar como programador.
    Claro que también puede usarse mal, pero comparado con la mayoría de los otros lenguajes, es casi sorprendente lo pequeños y eficientes que pueden ser los programas en Lua.

• Creo que el problema es más o menos así: un ejecutivo de la empresa decide que, para ser competitivos, los desarrolladores necesitan hardware de primer nivel, y entonces el desarrollador crea una app web en una laptop potente con 128 GB de RAM que le dio la empresa.
  Luego no la prueba en un entorno como la PC familiar de 2010 que usa su padre, o no la prueba con la frecuencia y profundidad suficientes como para darse cuenta de que muchas cosas se rompen y se vuelven prácticamente inutilizables.

  • Lo mismo pasa con la conexión de red. La experiencia de alguien que usa la app en la oficina con Wifi 7 y fibra gigabit simétrica no puede ser igual a la de alguien que la usa con el pésimo router Wi-Fi de un edificio de departamentos y una conexión residencial.
  • Esto se puede corregir fácilmente. Al desarrollar, se configuran las herramientas de desarrollo en modo móvil y con conexión limitada.
    Así, el enfoque mobile-first, el diseño responsivo, el espacio de pantalla limitado y los posibles problemas con malas conexiones se tratan como preocupaciones de primera clase.
    Normalmente, si se le informa el problema al responsable de producto, lo deja pasar. Por eso el tercer punto podría corregirse a: “también se prueba en una PC familiar de 2010, pero no es algo que le importe a los stakeholders más importantes”.
  • Parte de mi trabajo actual es probar en hardware antiguo o de bajo rendimiento, en navegadores viejos que todavía se usan y, especialmente, en entornos móviles.
  • No es una conjetura descabellada. Aunque el texto en sí trataba sobre un problema imaginario.
  • Relacionado con esto, me pregunto si los ingenieros de Google Android realmente usan teléfonos Android para probar. Sospecho que la mayoría son usuarios de Apple.

• Hace poco migramos una página vieja de HTML puro y generación desde el backend a React, y un dropdown con unas mil opciones tardaba varios segundos en abrirse. Antes, la página completa se abría en unos 100 ms
  Al principio se propuso mostrar solo las primeras 100 y renderizar recién cuando el usuario escribiera tres caracteres. Así es la realidad hoy en día
  Claro que, en la práctica, arreglamos el pésimo código de React e hicimos que se renderizara al instante

  • Exacto. Es algo común. Mientras se multiplican los artículos sobre rendimiento, como el tiempo hasta mostrar la primera pantalla, React creó toda una nueva categoría de problemas de este tipo
  • Basta con usar un framework de renderizado del lado del servidor como Turbo. Probé muchos de los frameworks del lado del cliente que la gente quiere usar hoy, pero con muchos datos todos eran lentos; Turbo fue la única excepción
  • Un selector con miles de opciones parece una experiencia de usuario pésima
    Si el nuevo framework deja el problema tan en evidencia que le da a alguien una justificación para arreglarlo de verdad, entonces hay incluso más razones para usar ese framework

• Se promueven textos como “Ruby idiomático” o “la optimización prematura es la raíz de todos los males”, y se dice que “el tiempo de desarrollo importa más que el rendimiento”; así terminamos
  Antes había desarrolladores que escribían mejor código en menos tiempo

  • No estoy de acuerdo. Hoy hay muchos más recursos que antes para ayudar a escribir código eficiente
    También vi mucho código antiguo horrible que hoy no se escribiría