Tree-shaking y la muerte de moment.js

Hoy de casualidad, ya no recuerdo cómo, he terminado mirando este repositorio de github https://github.com/you-dont-need/You-Dont-Need-Momentjs. Al primer vistazo parece que la razón de ser de este repositorio es demostrar que no siempre podemos necesitar usar moment.js para trabajar con fechas en nuestros desarrollos.

 

 

Si nos fijamos en la imagen que se nos presenta, vemos una comparación del peso de la librería al importarla y una alternativa llamada date-fns. Por lo que se puede ver, hay una gran diferencia de peso entre una y la otra. Más abajo, se hace una explicación con los dos motivos principales y es aquí donde ha empezado a llamarme la atención, ya que uno de los puntos aparece la palabra tree-shaking.

 

It is highly based on OOP APIs, which makes it fail to work with tree-shaking, thus leading to a huge bundle size and performance issues.

 

La frase anterior me gusta mucho, me recuerda a lo que con un amigo mío llamamos las hipsterías de JavaScript ya que por una parte, menciona una palabra extraña, que parece inventada por los de marketing, palabras que hace 5 años no existían en el desarrollo web. 

Por otra parte pone la programación orientada a objetos en jaque, algo que ahora esta muy de moda. Así que no me he podido resistir y he tenido que investigar que es el tree-shaking, una de tantas otras palabras que en algún momento he leído sueltas por ahí, pero no me he dignado a entender.

Tree-shaking

Bien, aunque ahora mismo si haces una búsqueda en google por este término lo vas a ver relacionado principalmente con dialectos de ECMAScript (Dart, Javascript, TypeScript) su origen data del 1990 para LISP, uno de los abuelos de JavaScript, sobretodo por sus influencias en programación funcional. Así que para empezar, resulta que no es tan nuevo el término.

Tree-shaking se podría resumir en que es una técnica para eliminar código sin usar de nuestra aplicación al hacer el empaquetado para producción, algo tremendamente útil hoy en dia para el desarrollo frontend ya que los desarrolladores web necesitamos hacer cada vez aplicaciones más ligeras, ¡recordad que estan por venir las PWA! que tienen que pesar poquísimo y trabajar offline, a parte, piensa que tus usuarios van justos de megas de tanto darle a instagram.

Bromas aparte, vamos a ponernos técnicos, solo un poco. Veamos cómo funciona el tree-shaking.

Desde que se introdujeron los ECMAScript 6 modules, para usar código ubicado en otros ficheros podemos hacer sentencias del tipo:

 

Este código no importa la función times() del fichero algebra.js por tanto, ¿qué sentido tendría incluirlo en nuestro empaquetado para producción? Ahí es donde el tree-shaking entra en acción, si usas un module bundler como webpack, a través de un análisis estático previo al uglify (los imports/exports no pueden hacerse en tiempo de ejecucción, al contrario que los require) se procede por defecto a la eliminación de este código en nuestro empaquetado final sin que nos demos cuenta.

Algo a tener en cuenta, es que esta técnica es realmente útil cuando trabajamos con librerías externas, ya que si tenemos código en nuestra aplicación que no estamos usando, tenemos otro tipo de problema. Al usar librerías externas hasta hace poco teníamos pocas posibilidades para reducir su peso si no necesitábamos la totalidad de las funcionalidades que brinaba, algunas permitiían descargar versiones reducidas de las mismas y poco más.

Ahora que sabemos en que consiste el tree-shaking podemos entender el porqué el repositorio que he encontrado reivindica como una mejor alternativa la libreria dates-fns.

 

La muerte de Moment.js

Recordando la cita del principio, ¿por qué no podemos hacer tree-shaking con la librería moment.js? Bien, el motivo como bien dice es que moment.js se basa en la importación de un solo objeto que nos permite interactuar con fechas a través de todos los métodos del objeto importado:

 

Aquí únicamente estamos usando el método add(), sin embargo, al tener que llamarlo sobre el objeto moment, no podemos usar ténicas de tree-shaking, ya que necesitamos la librería entera para poder acceder a ese método. Para poder usar tree-shaking necesitaríamos algo así:

 

Curioseando por los tickets del repositorio de dates-fns me ha parecido que hay bastante gente convencida de que es mejor no usar moment.js por este simple motivo y por otros relacionados con la mutabilidad y bugs presentes en la librería.

Por mi parte si bien no creo que una gran librería como moment.js vaya a morir, ya que su utilidad ahora mismo es brutal (no hay librería que soporte zonas horarias tan bien), sí creo que un día u otro recibirá una reescritura para poder solucionar este problema y adaptarse al estado moderno del desarrollo web frontend. Mientras eso ocurre, de seguro que la próxima vez me lo pensaré dos veces antes de instalarla como dependencia en mis proyectos frontend y me miraré el repositorio You-Dont-Need-Momentjs (ya que tiene algunas recetas para hacer operaciones básicas con fechas de manera nativa) o le pegaré un vistazo a date-fns

¿Te ha gustado el artículo? ¿Quieres que te avise de mis próximas publicaciones?

¿Quieres seguir aprendiendo?

Spread Operator y Arrays en JavaScript

Siguiendo la serie de videos que estoy haciendo para aprender JavaScript moderno hoy me gustaría explicaros una de las adiciones que más me ha gustado desde JavaScript ES6 y que uso constantemente, es el spread operator y me gusta...

Seguir leyendo