Hay un número enorme de bibliotecas allá afuera y para cualquier pedazo de funcionalidad dado, probablemente haya múltiples bibliotecas que logran ese pedazo de funcionalidad. Por ejemplo, hay tantas bibliotecas para escoger fechas, que hay artículos como "15 seleccionadores de fecha más populares de jQuery" para intentar ayudar a los desarrolladores a escoger.
Pero demasiadas opciones pueden convertirse en parálisis de decisión para nosotros los desarrolladores web. ¿Cómo sabemos cuál es la mejor? ¿Y si tomamos la decisión equivocada?
A menudo no hay una sola "mejor opción" en desarrollo web. Pero a menudo hay opciones mejores que otras, y pensar acerca de las siguientes consideraciones te puede ayudar a escoger la mejor opción.
Como una biblioteca de JS es frecuentemente utilizada cuando se desarrolla un producto orientado al usuario, estas consideraciones deben satisfacer dos públicos: los desarrolladores que deben codificar y mantener el código que usa la biblioteca (¡como tú!), y los usuarios que interactuarán con él.

¿Será una buena experiencia de desarrollador?

  • Bien documentadas: debe ser fácil encontrar una referencia de las firmas de las funciones, demostraciones de uso real y una guía de uso más narrativa. Si una biblioteca no tiene documentación, generalmente es una señal de que no es la más amigable con el desarrollador.
  • Flexible: las demostraciones en la documentación pueden verse geniales, pero quizá quieras usar una biblioteca de una manera ligera o completamente diferente a lo que muestran los ejemplos. Busca señales de flexibilidad: ¿es fácil cambiar las opciones de configuración? ¿Existe una arquitectura de complementos documentada? ¿Desencadena muchos eventos a los cuales puedes enganchar tu código?
  • Mantenida activamente: los navegadores cambian frecuentemente. La bibliotecas pueden dejar de funcionar de repente porque dependían de alguna característica especial del navegador que cambió. Esto es especialmente cierto para los shims y polyfills de HTML5, porque los navegadores frecuentemente están lanzando nuevas versiones con las implementaciones de los elementos de HTML5 que están evolucionando. Revisa la fecha de la versión más reciente.
  • Pensar a futuro: si estás buscando un "shim" de HTML5, mejor opta por un "polyfill", un shim que imita la API. De ese modo, en teoría, cuando todos tus usuarios estén usando exploradores que soporten esa tecnología, podrás dejar de usar completamente la biblioteca, sin modificar tu código en absoluto. Por ejemplo, si estás usando una biblioteca para usar video en tu página web, usa un polyfill que te permitirá usar la etiqueta de video de HTML5, y la reemplazará con una tecnología de respaldo como Flash en los navegadores antiguos.
  • Probada: todas las buenas bibliotecas deben incluir pruebas que aseguran que su funcionalidad es como se espera. Cuando se prueba una biblioteca, entonces podemos tener confianza que habrá cierto grado de compatibilidad hacia atrás en nuevas versiones de la biblioteca.
  • Código limpio: podríamos tratar a las bibliotecas de código abierto como cajas negras, y negarnos a mirar dentro de ellas, pero a veces, puede que necesites escarbar en el código de la biblioteca para depurar un problema o agregar un poco de funcionalidad nueva. Echa un vistazo rápido al código y ve qué tan fácil es leerlo, y si tiene banderas rojas, como pedazos grandes de líneas de código comentados.
  • Comunidad participativa: vas a tener preguntas. Vas a encontrar errores. Idealmente, serás capaz de darles solución junto con los desarrolladores, ya sean los programadores o los usuarios.
Si la biblioteca está alojada en un sitio de control de versiones como Github, puedes ver:
  • Número de forks: muchos forks (o estrellas) significan que por lo menos hay muchos desarrolladores que se preocuparon lo suficiente como para hacerle un fork a la biblioteca. Eso no significa que te ayudarán, ¡pero es un comienzo! Las bibliotecas grandes tienen miles de forks, las bibliotecas emergentes tienen 100s o 10s de forks.
  • Número de problemas: ¿hay muchos problemas abiertos? Eso puede ser una señal de que no hay un esfuerzo de la comunidad por responder y cerrar los problemas. También puede significar que es un proyecto muy popular con muchas ideas para mejorar, así que continúa al siguiente punto.
  • Vibra sobre los problemas: lee algunos problemas y pull requests. ¿Los que mantienen el proyecto están abiertos a la retroalimentación? ¿Responden preguntas sobre su uso? ¿Tienes una vibra positiva o negativa sobre esas conversaciones?
  • Comunidad externa: ¿hay preguntas sobre la biblioteca respondidas en StackOverflow? ¿Hay bibliotecas construidas encima de esa biblioteca? Muchas bibliotecas pequeñas no van a ser lo suficientemente grandes como para tener una comunidad externa, pero las más grandes, como Modernizr o Backbone, tienen unas significativas, y eso es una gran motivación para usarlas. Puedes hacer una búsqueda en internet con el nombre de la biblioteca para ver qué tipo de resultados encuentras.

¿Será una buena experiencia de usuario?

Si la biblioteca de JS no crea una componente de interfaz de usuario (UI), entonces solo las primeras de estas importan.
  • Tamaño de archivo: ¿qué tanto contribuirá a cuánto JS tienen que descargar tus usuarios? Para ponerlo en contexto, jQuery comprimido y minificado es de 18k y Select2 es de 7K.
  • Rendimiento: además del tamaño, otros aspectos de una biblioteca de JS pueden afectar su rendimiento, como si hace manipulación pesada del DOM, procesamiento de gráficas, cálculos, llamadas asíncronas a almacenamiento, etc. Busca promesas de gran rendimiento en la documentación y, por supuesto, pruébala tú mismo.
  • Soporte de navegadores: revisa que soporte todos tus navegadores deseados. En estos días, muchas bibliotecas no soportan navegadores viejos a propósito (los cuales puede que tu página requiera soportar), porque están diseñados para ser ligeros y solo para navegadores móviles.
  • Accessibilidad: muchas bibliotecas para componentes de UI se ven muy bien, pero no son accesibles (no funcionan bien para usuarios con discapacidades visuales). Para una revisión rápida, puedes ejecutar WAVE en la página de demostración de la biblioteca.
  • Adaptable: si tus usuarios alguna vez usarán la componente de UI de una biblioteca en un navegador móvil, entonces debe funcionar bien para ellos ahí. ¿Los botones son suficientemente grandes? ¿Usa eventos de tocar? ¿Se escala para pantallas pequeñas?
Si has considerado todos los criterios y aún no puedes decidir entre un puñado de bibliotecas, entonces puedes intentar el enfoque de llamar a un amigo: pregúntale a tus colegas o amigos desarroladores cuál biblioteca usan. Tal vez encuentres una favorita entre las multitudes.
Recuerda: no hay una respuesta correcta, no hay una mejor opción. También, no tienes que revisar exhaustivamente cada biblioteca JS que estás pensando usar, especialmente si estás trabajando en proyectos por tu cuenta. Puedes simplemente escoger una biblioteca y ver qué te gusta de ella a medida que la usas. Empezarás a construir una lista en tu cabeza de tus bibliotecas favoritas para usar, así como tus propios criterios, y eso es lo que te ayudará en tus decisiones futuras.