Hace no tanto tiempo, para los que trabajábamos en determinadas plataformas (ejem, Microsoft) era complicado justificar el uso de liberías de terceros, pero por fortuna hoy en día la situación ha cambiado. En casi cualquier plataforma existe una amplia varidad de librerías disponibles para hacer las tareas más diversas, y eso, que parece una maravilla, también tiene conlleva sus problemas.

Es fácil acabar agobiado ante la cantidad de cosas que creemos que necesitamos conocer y que el número de opciones disponibles nos lleve a una parálisis que no nos deje decidir (lo que se conoce como paradoja de la elección).

Elegir qué librerías utilizar no es fácil y, al igual que elegir un lenguaje de programación, depende muchos factores. Muchos de ellos, además, son muy dependientes del equipo de desarrollo y del contexto en que se toma la decisión (gustos personales, conocimientos previos, tipo de proyecto, etc.).

Pese a ello, creo que es interesante ver algunas cosas que deberíamos tener en cuenta a la hora de elegir una librería. El que sean más o menos determinantes, dependerá en gran medida de ese contexto que mencionaba antes.

Intenta no usar librerías

Puede parecer una tontería, pero más de una vez me he visto usando una librería que realmente no necesitaba. Es una consecuencia de ese lado oscuro que tienen los gestores de paquetes actuales. Es tan fácil instalar una librería, que ni nos lo pensamos.

Lo malo es que cada librería que instalas es una dependencia nueva que tienes que mantener actualizada y por la que tienes que responder ante tus clientes. Para ellos, un fallo en la librería es un fallo en tu aplicación, así que más te vale confiar en ella.

Si lo que vas a usar de la librería lo puedes implementar tú en unas cuantas líneas de código, seguramente sea mejor empezar por ahí. Ya tendrás tiempo de recurrir a la librería si realmente se complica la cosa.

Esto no quiere decir que no debas usar librerías. Es complicado justificar una inversión de 3 años para escribir tu propio ORM, tu framework SPA y tu framework para servidor web en lugar de utilizar cosas que ya existen.

Trata de buscar alternativas

Es muy tentador quedarse con la primera librería que encontremos para hacer algo, y hay veces, sobre todo cuando ese algo no es muy crítico, que es razonable hacerlo así.

Pero si estás eligiendo una librería que va a condicionar tu forma de desarrollar la aplicación, que va a tener impacto en partes importantes de la misma, o a la que se va a acoplar gran parte de ella, merece la pena dedicar un poco de esfuerzo a considerar alternativas en lugar de quedarte con el primer resultado de Google o lo que hayas visto en Reddit ese día.

Que tenga cierta madurez

Usar cosas antiguas está mal visto, pero elegir una librería que no es lo último de lo último al empezar un proyecto nuevo, parece algo de locos. Sin embargo, optar por lo último de lo último del hype de esta semana, es probablemente una de las peores decisiones que puedes tomar.

En primer lugar, porque lo último de lo último todavía no estará terminado, será una versión alpha, o beta, o release candidate o 1.0. Con los tiempos que corren, es más o menos lo mismo: algo poco estable. Y ya no sólo hablo de bugs, que puede que no sean excesivos (o que los corrijan rápido), sino también de API. Puedes perder mucho tiempo readaptando tu aplicación a los cambios de API que se van introduciendo en las nuevas versiones, y además te verás obligado a actualizarte para corregir los bugs que has ido encontrando. Un escenario nada agradable.

Por si eso fuera poco, algo que lleva unos meses disponible es complicado que tenga tracción suficiente para tener muchos usuarios, y cabe la posibilidad de que acabe descontinuado pronto.

Personalmente, prefiero utilizar una librería más antigua, que tenga cierta estabilidad y haya sobrevivido al mundo real, aunque sea más «fea», que una librería supernovedosa que no sé cómo acabará. Eso no quiere decir que no esté bien conocer las librerías novedosas, pero a la hora de desarrollar profesionalmente, un poco de cautela viene bien.

No seas el único usuario y que haya alguien detrás

Es muy desesperante tener un problema y que no aparezca en ningún sitio en Google. O peor aun, que el único resultado que encuentres sea la pregunta que hiciste en StackOverflow hace 2 semanas y que no tiene ninguna respuesta.

Una librería con una buena base de usuarios suele implicar dos cosas: que probablemente esté más pulida porque haya habido más gente reportando fallos, y que será más fácil encontrar a alguien que ya haya pasado por el mismo problema que tienes que tú ahora y tal vez te pueda ayudar.

También es importante ver quién está detrás de la librería. No es igual una empresa grande (Facebook, Google, …) que un desarrollador freelance, que una comunidad establecida de gente colaborando. Cada caso es diferente, pero lo importante es pensar qué continuidad puede tener esa librería en el futuro. Y, ojo, el hecho de que sea de una empresa grande no garantiza más continuidad que un par de desarrolladores apasionados por su trabajo. Puede que para la empresa no sea algo estratégico y la acabe descontinuando, mientras que esos desarrolladores podrían acabar creando una comunidad capaz de mantener la librería si les pasara algo.

En este aspecto, si el proyecto es de código abierto y tiene una comunidad lo bastante grande, puedes tener cierta esperanza de que si los creadores originales desaparecen, alguien dé un paso al frente y siga con el proyecto (que también podrías ser tú, pero ese es otro tema).

Fácil de integrar o de extender

Suelo preferir librerías pequeñas. Normalmente están más focalizadas en resolver un problema concreto y hacerlo bien, y además suelen ser más simples por lo que es más fácil que estén bien depuradas y sean sólidas. Lo malo de elegir librerías pequeñas es que acabarás necesitando más (con los problemas que implica el aumento de dependencias) y es importante que sea fácil integrar unas con otras.

Si optas por una librería o framework de mayor tamaño, asegúrate de que sea lo bastante flexible y extensible como para poder cambiar su comportamiento en el futuro, sobre todo si vas a acabar con mucho (incluso todo) el código de tu aplicación dependiendo de ella. Tener una única dependencia grande tiene sus ventajas frente a muchas dependencias pequeñas, pero si al final te acaba impidiendo hacer lo que necesitas y tienes que desecharla entera, también es más costoso.

(Razonablemente) Bien documentada

Seamos realistas, esto hoy en día esto es complicado de encontrar. Entre la cantidad de proyectos que corren más que su documentación oficial (algunos incluso procedentes de empresas con muchos recursos), y la velocidad a la que se sacan versiones rompiendo APIs y dejando posts obsoletos, no siempre es fácil encontrar una documentación adecuada. Pese a todo, es un factor que valoro bastante porque puede ahorrarte (o hacerte perder) mucho tiempo. Un punto adicional para las librerías que mantienen la documentación versionada y te permiten acceder a la documentación de la versión que estás usando, no a la última disponible.

En los proyectos de código abierto tienes la ventaja de que siempre puedes mirar el código. Y eso está muy bien. Si tienes ganas y tiempo, claro. Puedes ponerte a leer el código para ver cómo se hace algo, y con un poco de suerte aprenderás cosas por el camino, pero no es la forma más rápida de resolver una duda.

Con una licencia que te sirva

No se trata de que todo tenga que ser de código de abierto y gratis, pero ahora que casi todo es así, hay que tener cuidado con la licencia de la librería que vas a usar. El mundo de las licencias de software es complicado y, si quieres ser legal (cosa que doy por hecho), es necesario prestar un poco de atención. Y a veces, la cosa se lía y entender las implicaciones de una licencia es realmente difícil (como el caso de React y las patentes).

Que la librería sea de pago no debería ser un factor determinante, se supone que te va a ahorrar un trabajo que cuesta más que la librería. Por desgracia, en el mundo real, el precio de las cosas importa y si el coste es muy alto, o si el coste es por instalación y estás vendiendo licencias de un producto, puede que ya no salga tan rentable.

Conclusiones

Básicamente, mi guía a la hora de elegir una librería es asegurarme de que la necesito, de que puedo (legal y económicamente) usarla, de que no me va a volver loco, y que va a seguir existiendo dentro de unos años. Todos los puntos anteriores llevan de una u otra forma a cumplir con alguna de estas cuatro premisas.

Quizá alguien eche de menos una mención a la usabilidad o la curva de aprendizaje, pero en mi caso concreto son dos factores que puedo llegar a gestionar bien. Al desarrollar productos (no proyectos ni produyectos), el proceso de desarrollo y vida del software son lo bastante largos como para que hacer una inversión inicial mayor en aprender una librería, o en crear un wrapper sobre su API para hacerla más usable, se diluya en los (esperables) beneficios de utilizarla a medio y largo plazo.