¿Qué biblioteca de JS deberías usar?

¿Será una buena experiencia de desarrollador?

• Bien documentada: debería ser fácil encontrar una referencia a la firma de las funciones, ejemplos reales de uso y una guía de uso con más narrativa. Si una biblioteca no tiene documentación, suele ser una señal de que no es la más amigable con el desarrollador.
• Flexible: los ejemplos en la documentación pueden parecer geniales, pero tal vez queramos usar una biblioteca de una manera un poco o muy diferente a lo que muestran los ejemplos. Busca señales de flexibilidad: ¿es fácil mandar opciones de configuración? ¿Hay una arquitectura de complementos documentada? ¿Desencadena muchos eventos en los cuales puedes enganchar tu código?
• Mantenida de manera activa: los navegadores cambian de manera frecuente. Las bibliotecas que alguna vez funcionaron pueden dejar de funcionar de manera repentina porque dependían de alguna peculiaridad 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 implementaciones que evolucionan de los elementos de HTML5. Puedes averiguar qué tan recientemente fue actualizada la biblioteca al revisar la fecha en su registro de cambios. Si no hay un registro de cambios y la biblioteca está hospedada en un repositorio de código abierto como Github, puedes revisar la fecha en que se hicieron los últimos cambios.
• Pensamiento a futuro: si estás buscando un "shim" de HTML5, mejor prefiere un "polyfill", un shim que imita la API. De esa manera, en teoría, cuando tus usuarios estén usando un navegador que soporte esa tecnología, serás capaz de dejar de usar esa biblioteca por completo, sin hacerle ningún cambio a tu código. Por ejemplo, si estuvieras usando una biblioteca para usar un video en tu página web, usa un polyfill que te permitirá usa la etiqueta video de HTML5, y la reemplazará con la tecnología de respaldo como Flash en navegadores más antiguos.
• Probada: todas las buenas bibliotecas deben incluir pruebas para asegurar que su funcionalidad trabaje como se espera. Cuando una biblioteca está probada, entonces tenemos confianza en que habrá un cierto grado de compatibilidad con versiones anteriores en las nuevas versiones de la biblioteca.
• Código limpio: podríamos tratar a las bibliotecas de código abierto como cajas negras y negarnos a ver dentro de ellas, pero a veces puede que necesites escarbar un poco dentro del código de la biblioteca para depurar un problema o agregar alguna nueva funcionalidad. Echa un vistazo rápido al código y ve qué tan fácil es leerlo y si tiene banderas rojas, como grandes pedazos de líneas de código comentadas.
• Comunidad responsiva: vas a tener preguntas. Vas a encontrar problemas. Idealmente, serás capaz de resolverlos con los desarrolladores, ya sean los que mantienen la biblioteca o los usuarios.

• 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?

• 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?