When data has not yet
In Dante’s Peak, the volcano begins to speak long before it erupts.Small earthquakes. Changes in…
El desarrollo web moderno — y el desarrollo de software en general — no sabe o no puede contemplar procesos sin la utilización de gestores de paquetes.
Lejos quedan los tiempos en los que para desarrollar una sitio web, todo lo que utilizábamos era HTML, CSS y JavaScriptsin tener que transpilar, compilar, o utilizar herramientas de construcción que consumen recursos y tiempo.
Hoy nos centraremos en la utilización de una de estas herramientas, NPM, y miraremos algunos datos sobre el impacto y algunos efectos secundarios que tiene en la Web, y en el desarrollo Web actual.
¿Qué es NPM?
NPM, de Node Package Manager, aunque se diga también que “npm no es un acrónimo”, es un gestor de paquetes para el lenguaje de programación JavaScript.
Pertenece a GitHub — Microsoft, y es el gestor de paquetes predeterminado para el entorno de ejecución de Node.js. Existen otros gestores, pero NPM es seguramente el más popular.
Además de NPM, también puedes encontrar, en el mercado, alternativas como Yarn, o Pnpm.
Herramientas como NPM han revolucionado en sector del Desarrollo Web permitiendo que, entre muchas otras cosas, puedas compartir código con tu equipo, tu organización, o con otros programadores de partes del mundo cuyo nombres son impronunciables en castellano.
NPM es utilizado por millones de desarrolladores en todo el mundo gracias al compromiso de npm, Inc. de llevar el “desarrollo en JavaScript a la elegancia, productividad, y seguridad”.
NPM te permite aprovechar la vivacidad del ecosistema de JavaScript, y no tener que reinventar la rueda con problemas ya resueltos por la comunidad open-source.
¿Cuál es el problema?
1.3 millones. Según Wikipedia — felicidades por los 20 años — actualmente existen más de 1.3 millones de paquetes disponibles en el registro principal de npm. ¿No crees que este hecho también contribuye a la obesidad de la web?
Me pregunto, ¿qué huella de carbono dejará, en el medio ambiente todo el tiempo de construcción (build) de cada sistema con decenas, o incluso millares, de paquetes, en el entorno de test, en el de producción? ¿Conoces algún otro lenguaje de programación con tantos módulos?
Sin querer parecer ser un detractor de NMP, antes por el contrario, pues no imagino mi trabajo sin npm o yarn, creo que empieza a ser necesario una debate o reflexión seria sobre el uso desordenado de los gestores de paquetes.
Pienso que hay mucho código ahora mismo en NPM. En este momento, solamente Gatsby tiene 153 dependencias, según npmjs.com. Si una de esas dependencias tiene por lo menos una dependencia, ¿ya estamos hablando de 306 dependencias?
De esta forma, no hay dudas sobre la obesidad de la web, y del directorio node_modules de cada proyecto también.
Para que te hagas una idea, uno de nuestros últimos proyectos node_modules tenía las siguientes características:
$du -sh node_modules837M node_modules
Nos ha parecido una barbaridad. Tuvimos que investigar el por qué.
Desde el terminal, puedes ejecutar du -sh ./node_modules/* | sort -nr | grep ‘\dM.*’ para saber qué módulos ocupan la mayor parte de la memoria. Luego puedes intentar simplificar la estructura de tu árbol de dependencias, o eliminardirectamente los módulos que no estás utilizando, y no tienes previsto utilizar en el futuro. Muy probablemente también eliminarás alguna dependencia obsoleta
¿Cómo se acumulan las dependencias con el tiempo?
Existen diferentes tipos de dependencias. Por tanto, según el proyecto, te puedes encontrar con dependencias esencialespara que el código de tu proyecto funcione, pero también tienes dependencias de desarrollo, por ejemplo alguna biblioteca que te ayude a escribir código más limpio, o incluso dependencias de terceros que no están en NPM, etc.
Ejemplo visual de la relación entre dependencias
¿Qué te parece esta galaxia de dependencias de Gatsby.js?
¿Interesante? Encuentra a Gatsby, si puedes. La mala noticia es que no he podido llegar al final para ver el total de dependencias. Preocupante. Puedes intentarlo tú en npm.avanka.com, ¡y luego coméntalo abajo cómo es tu red de dependencias!
¿Cuál es la solución?
No tengo la solución exacta para este problema. Lo que sí sé es que no todos tus proyectos necesitan, o necesitaban Node.js. ¿Estás de acuerdo?
Si necesitas propiedades avanzadas y no quieres programarlas, que sepas que CSS ha evolucionado mucho en los últimos años y algunas características o propiedades nativas pueden sustituir a paquetes que utilizas regularmente.
Lo mismo se aplica a las nuevas propiedades de JavaScript. Algunas son tan potentes, con características que funcionan en todos los navegadores modernos, sin la necesidad de compilación, y pueden ser perfectas para tu sitio web estático.
Por tanto, para que herramientas como NPM sean parte de la solución, y no del problema creo que es urgente entender, y estudiar las necesidades de tus proyectos, siempre. Además, puedes analizar el peso y coste de un paquete antes de utilizarlo.
En la misma línea, no todos los sitios web son lo suficientemente complicados o complejos para pipelines complejos. Creo que es importante mantenerlo simple, porque todo suma, y más complejidad el código de base, significa más tecnología, más herramientas, más procesos, más automatización, más errores, más recursos, más consumo, menos sostenibilidad.
Sostenibilidad
El problema de la sostenibilidad puede estar relacionado con el proyecto que has desarrollado, y la vida útil del mismo. Por ejemplo, visitar un proyecto meses o años después suele ser un dolor de cabeza.
Aunque solo quieras hacer un pequeño cambio en alguna variable, te puedes encontrar con la sorpresa de que una de las dependencias ya no funciona, está obsoleta, no existe, y ya no puedes compilar el proyecto, mientras el cliente está esperando. Lo mismo puede pasar con Node. ¿Cuántas veces has tenido que reinstalarlo en tu Mac OS?
En vez de instalar una nueva dependencia — de otra dependencia -, por qué no intentar desarrollarlo tu mismo. A lo mejor se trata solamente de 3 líneas de código. No creo que sea un problema reinventar la rueda, siempre que esta rueda signifique más eficiencia para tu producto, proyecto y futuro.
Conclusión
Para concluir, el lenguaje de la moda, JavaScript, y NPM te permiten tener mucha flexibilidad a la hora de desarrollar un nuevo proyecto. Fuera de tu organización siempre hay gente más inteligente que dentro, y las dependencias de NPM te proporcionan esta inteligencia de forma abierta.
Pero con un “gran poder, viene una gran responsabilidad”. Por tanto, siempre que tengas la necesidad de ejecutar npm install, no te olvides que detrás de todo suceden cosas, recuerda la imagen de Gatsby de este artículo. Si no vigilas, la red de dependencias se hace infinita en muy poco tiempo.
¿Qué política tienes en tu organización para la gestión de paquetes de NPM?
FOTO: Myriams-Fotos de Pixabay
Fuente:
Comments