Definición
Una librería es código ya escrito por otra persona que resuelve un problema concreto y que tú incorporas a tu proyecto para no reescribirlo.
La diferencia con un framework es de control: tú llamas a la librería cuando quieres. No te dice cómo organizar carpetas ni cuándo ejecutar nada. Entra, hace su trabajo y se aparta.
Y la diferencia con un SDK: un SDK es el kit que publica un proveedor concreto para hablar con su servicio. Toda librería resuelve un problema; un SDK resuelve el problema de integrarte con alguien.
En el mundo JavaScript se instalan con npm; en PHP con Composer; en Python con pip.
El coste que no se ve
Instalar una librería parece gratis. No lo es, y conviene saber qué firmas:
- Peso. En el navegador, cada kilobyte se descarga, se interpreta y se ejecuta.
- Superficie de ataque. Su código corre con los mismos permisos que el tuyo. Si la comprometen, te comprometen.
- Dependencias transitivas. Instalas una y vienen cuarenta detrás. Cada una con su propio riesgo.
- Mantenimiento. Si la abandonan, el problema pasa a ser tuyo.
- Cambios de ruptura. Actualizar deja de ser gratis.
La pregunta antes de instalar no es "¿me ahorra tiempo hoy?" sino "¿me ahorra más tiempo del que me va a costar mantenerla?".
Ejemplo práctico
En esta web hay decisiones en las dos direcciones, y las dos fueron deliberadas.
Sí instalé sharp para redimensionar imágenes, zod para validar el formato de los términos del diccionario y gray-matter para leer las cabeceras de los Markdown. Son problemas resueltos, con casos límite que yo no habría previsto, y las tres están muy mantenidas.
No instalé nada para el gato que camina por el borde inferior de aeworks.tech, ni para el teléfono del asistente, ni para el buscador que compara vectores. Eran unas decenas de líneas de JavaScript y CSS. Meter una librería de animación de 40 KB para mover un dibujo de un lado a otro habría costado más que escribirlo.
El caso que mejor ilustra la decisión: el buscador semántico sí usa una librería grande, @huggingface/transformers, porque ejecutar un modelo de IA en el navegador no es algo que se escriba en una tarde. Pero esa librería descarga 60 MB desde un servidor de terceros, y eso obligó a declararlo en el aviso legal de la web. Una dependencia puede tener consecuencias que no son técnicas.
Cómo evaluar una antes de instalarla
- Última publicación. Si lleva dos años sin tocarse, cuidado.
- Incidencias abiertas frente a cerradas. Si nadie responde, estás solo.
- Cuántas dependencias arrastra. Mira el árbol completo, no solo la de arriba.
- Peso real en el paquete final. Herramientas como Bundlephobia te lo dicen antes de instalar.
- Licencia. La mayoría son permisivas, pero conviene mirarlo si el proyecto es comercial.
- ¿Cuánto código me ahorra de verdad? Si son treinta líneas que entiendes, escríbelas.
Errores comunes
- Instalar por costumbre. Muchas utilidades de librerías clásicas ya están en el lenguaje desde hace años.
- No fijar versiones. Sin un fichero de bloqueo, dos instalaciones del mismo proyecto pueden traer versiones distintas y comportarse distinto.
- Actualizar todo a la vez. Cuando algo se rompe, no sabes cuál fue.
- No auditar nunca. Un comando de auditoría de vulnerabilidades cada cierto tiempo evita disgustos.
- Confundirla con un framework y esperar que lo organice todo. Una librería resuelve un problema, no tu arquitectura.
- Meter una librería enorme para usar una función. Ocurre constantemente.
Cuándo usarla
Sí cuando el problema es complejo, está bien resuelto y no es tu negocio: criptografía, fechas y zonas horarias, parseo de formatos, procesamiento de imágenes. Escribir tu propia criptografía es de las peores ideas del oficio.
No cuando el problema es pequeño y lo entiendes, cuando el peso importa mucho (una web que tiene que cargar rápido), o cuando la librería está poco mantenida. En esos casos, treinta líneas propias son más baratas a tres años que una dependencia.
