Saltar al contenido principal

Ya no se optimiza como antes

Tengo la sensación de que cada vez los desarrolladores nos estamos preocupando menos por la optimización de los productos que creamos, y eso lo creo porque el hardware es cada vez mejor.

Pero no siempre fue así, hace muchos años, como el hardware del que se disponía era muy limitado, todo lo que se desarrollaba tenía que estar optimizado al máximo para que al menos pudiera funcionar.

Eso hacía que los desarrolladores tuvieran que pensar a bajo nivel cómo hacer las funcionalidades que requería el software que estaban desarrollando.

Optimizaciones a lo bestia en videojuegos clásicos

Esto se daba mucho en videojuegos. Los primeros tenían paletas de color limitadas, dibujaban en pantalla lo mínimo imprescindible e incluso reutilizaban los recursos gráficos siempre que podían.

En el primer Super Mario, por ejemplo, la imagen de las nubes del juego era la misma que la de los arbustos del suelo, solo que con otro color, con eso conseguían reducir al mínimos las imágenes para las texturas del juego.

Imagen del primer Mario Bros en la que se ve que las nubes y los arbustos son el mismo sprite

Otro ejemplo en videojuegos, Chris Sawyer hizo el famoso Roller Coaster Tycoon usando ensamblador, un lenguaje de muy bajo nivel. Lo bueno es que Chris ya tenía amplia experiencia en este lenguaje ya que había estado haciendo ports de algunos juegos a PC.

En los años 90 los procesadores eran muy poco potentes y encima la memoria era escasa, es por eso que algunos juegos fueron programados en ensamblador, para tener el máximo control sobre el uso de memoria y de recursos, ya que por entonces el compilador de C no optimizaba tanto como actualmente.

¿Te imaginas programar un juego entero en ensamblador? Hoy en día sería una locura.

La trampa de Electron

Cuando hablo de optimización siempre me viene a la mente Electron. Por si no te suena Electron, es una librería que permite construir aplicaciones de escritorio para ordenadores usando el motor de renderizado de Chrome, es decir, usando tecnologías web del Frontend 🚧.

Electron permite que no tengas que aprender C para crear aplicaciones y, además, que se puedan desarrollar aplicaciones más rápido, ya que no te tienes que preocupar de compilar para cada sistema.

Pero no todo es tan bonito, el problema que tiene es que si abres varias aplicaciones hechas con Electron, es como si abrieras múltiples navegadores de Chrome, y todos sabemos lo que consume Chrome.

Spotify por ejemplo ya está reescribiendo partes de su app de escritorio en tecnologías nativas para evitar problemas de rendimiento.

Varios megas de Javascript para abrir una web

Lo mismo pasa en las webs, antiguamente navegabas por Internet y abrir una web significaba descargar el HTML, un par de archivos CSS y a veces JS para algo dinámico.

Hoy en día es lo contrario, para abrir una simple web hay que descargar un bundle y varios ficheros Javascript 🚧 simplemente para que la web se abra.

Y esto pasa porque poco a poco nos hemos ido convenciendo de usar frameworks para todo, que aunque es cierto que mejoran la experiencia de desarrollo, es a costa de mandar mucho código al usuario final.

También es cierto que en una web de cierta envergadura viene bien ter cosas como reactividad, estado, control de rutas, ciclo de vida, componentes, aislamiento de estilos, etc.

Yo por ejemplo en este blog he intentado reducir al máximo el Javascript, no uso frameworks y escribo a mano lo que necesito, que no es mucho. Más info en Acerca de este sitio

Algunas conclusiones

Hoy en día, aunque hay de todo, no se tiene tanto en cuenta las optimizaciones de rendimiento hasta que no hacen falta, es normal, preferimos centrarnos en otras cuestiones más importantes, o al menos esa es mi Opinión 🚧.

También es cierto que se añaden cada vez más capas de abstracción, facilitando la vida a los programadores (o no, depende del caso), y por cada capa se está añadiendo parte de código que quizás no sea tan necesario.

Con esto de la optimización también hay que tener mucho cuidado, Evita la optimización temprana, e intenta maximizar la entrega de valor. Analiza los cuellos de botella y estudia sus costes y la cantidad de tiempo que se puede invertir en optimizar el código.