Ya hablamos del sprawl y de que es necesario tener buen criterio a la hora de diseñar un sistema. Es fácil imaginar los peligros de instalar cualquier librería para resolver hasta el más mínimo detalle. Pero hoy quiero hablar del otro lado de la moneda: Hay librerías que sí vale la pena usar, y hay razones muy buenas para hacerlo.
En el mundo del desarrollo de software, vemos desde siempre una especie de guerra silenciosa entre dos posturas. Por un lado, los que importan librerías para todo. Y por otro, los que sostienen que hay que escribir todo uno mismo y evitar dependencias a toda costa. Yo estuve casi toda mi carrera en el segundo grupo, pero hoy me quedo en el medio.
Llenar un sistema de librerías ridículas como is-odd o left-pad puede terminar generando sistemas frágiles y difíciles de mantener, sin mencionar la cantidad de puertas que estamos abriendo a problemas de seguridad generados por terceros (vale la pena seguir ese enlace).
No se trata de evitar todas las dependencias ni de abrazarlas todas. Se trata de usar la cabeza. No reinventar la rueda, pero tampoco instalar una fábrica de tornillos. Pero algunas tareas engañan, son más complejas de lo que parecen, y aunque pueden parecer triviales pero tienen sutilezas que pueden traer problemas en producción. Acá van algunos ejemplos de librerías que, desde mi experiencia, tienen sentido utilizar.
Un caso clásico es moment (o su sucesor dayjs). A primera vista, manejar fechas es fácil: Sumás un día, restás una hora, y listo. Pero la realidad es mucho más oscura, con husos horarios, calendarios diferentes, horarios de verano que cambian arbitrariamente, años bisiestos, y hasta zonas donde la misma fecha tiene dos interpretaciones posibles dependiendo del año. Manejar bien todo eso a mano es un infierno.
Otro ejemplo clave es todo lo relacionado con criptografía. Bajo ningún concepto hay que escribir tu propio algoritmo de encriptación, debemos apoyarnos siempre en librerías serias y bien auditadas. Porque la criptografía es contraintuitiva, es muy fácil creer que una función es segura solo porque nos funciona o parece aleatoria. La realidad es que la seguridad se rompe en los detalles: timing attacks, padding, generación de claves, manejo de seeds. Usar librerías como crypto (la nativa de Node), libsodium, o incluso bcrypt para hashing de contraseñas no es un capricho, es una necesidad si uno quiere que el sistema no sea vulnerable. Y ni hablar si estás manejando datos sensibles de usuarios.
Hay más casos donde usar una librería puede parecer exagerado pero tiene sentido en la práctica. validator permite validar y sanitizar inputs comunes como emails, URLs, fechas, números. Usar ese regex para validar un mail que encontraste en StackOverflow ya no alcanza, el estándar de emails válido es tan amplio que incluye cosas como caracteres raros, nombres entre comillas, incluso direcciones IP. Usar una librería probada te ahorra pelearte con todos esos detalles y te permite confiar en que alguien ya se ocupó de cubrir los casos borde.
Otro buen ejemplo es uuid. Generar identificadores únicos universales no es algo trivial. Uno puede pensar “bueno, le meto Math.random() y ya está”, pero eso es una receta para el caos. uuid permite generar identificadores únicos que realmente tienen un riesgo prácticamente nulo de colisión, y encima están estandarizados. Se usan en bases de datos, sistemas distribuidos, tokens temporales. Es una librería pequeña, sólida, sin dependencias, y que hace una cosa y la hace bien bien.
Un caso más, quizás menos conocido pero igualmente útil: lodash. Esta librería ofrece un montón de funciones utilitarias que podrías escribir vos mismo, pero que ya están probadas, optimizadas y con buen soporte para edge cases. ¿Podés hacer un deep clone a mano? Posiblemente. Pero cuando te das cuenta de que tu estructura tiene referencias circulares o prototipos no estándar, empezás a valorar lo que significa tener una función que lo resuelve bien. Igual, hay que usarlo con criterio, no para todo, pero sigue siendo una herramienta valiosa.
En mi opinión, la línea que divide el importar o escribir está en la complejidad oculta. Si algo parece simple pero tiene muchas variantes, muchos casos borde, mucha historia o muchos estándares, probablemente valga la pena usar una librería. Si el problema es bien conocido, está bien resuelto y es estable, también. Ahora bien, si lo que estás por instalar es una función que podrías escribir en 1 minuto y que no tiene mayores complicaciones…
El desarrollo moderno nos pone miles de herramientas al alcance de un comando, pero eso no significa que debamos usarlas todas. Tampoco significa que debamos rechazarlas por deporte. Como en tantas otras cosas, lo importante es el juicio. Usar la cabeza. Pensar en la calidad del software, en su mantenimiento, en su seguridad, en su performance. No se trata de escribir menos código, sino de escribir mejor. Y a veces, eso incluye saber cuándo dejar que otro lo escriba por vos.