Qual biblioteca de JS você deve usar?

Essa vai ser uma boa experiência como desenvolvedor?

• Bem documentada: Deve ser fácil encontrar uma referência de assinatura de função, demonstrações de uso real, e um guia de uso mais narrativo. Se uma biblioteca não tem documentação, normalmente é um sinal de que ela não é a mais amigável ao desenvolvedor.
• Flexível: As demonstrações na documentação podem ser impressionantes, mas pode-se querer usar a biblioteca de uma maneira ligeira ou completamente diferente do que as mostradas nos exemplos. Procure por sinais de flexibilidade: é fácil alterar opções de configuração? Há uma arquitetura de plugins documentada? Ela desencadeia muitos eventos aos quais você poderia associar seu código?
• Mantida ativamente: Navegadores mudam frequentemente. Bibliotecas podem parar de funcionar de repente porque dependiam de alguma característica específica do navegador que mudou. Isso é especialmente verdadeiro para shims e polyfills do HTML5, porque os navegadores estão frequentemente lançando novas versões com implementações dos elementos do HTML5 que estão evoluindo. Verifique a data da versão mais recente.
• Pensando no futuro: Se você estiver procurando por um "shim" do HTML5, prefira um "polyfill" - um shim que imita a API. Dessa forma, teoricamente, quando todos os seus usuários estivessem usando navegadores que suportassem a tecnologia, você estaria apto a parar de usar a biblioteca completamente, sem mudança nenhuma no seu código. Por exemplo, se você estiver usando uma biblioteca para rodar vídeo em sua página web, use um polyfill que te permitirá usar a tag video do HTML5, e a substituirá com uma tecnologia alternativa como o Flash em navegadores mais antigos.
• Testada: Todas as boas bibliotecas devem incluir testes que garantem que suas funcionalidades rodam como esperado. Quando uma biblioteca é testada, podemos confiar que haverá algum grau de retrocompatibilidade em novas versões da biblioteca.
• Código limpo: podemos tratar bibliotecas de código aberto como caixas pretas e nos recusarmos a olhar dentro delas, mas, às vezes, você pode precisar escavar o código da biblioteca para depurar um problema ou adicionar um pouco de funcionalidade. Dê uma olhada no código e veja quão fácil ele é de ser lido e se há sinais de alerta, como grandes trechos de linhas de código comentadas.
• Comunidade ativa: Você vai ter perguntas. Você vai encontrar bugs. Idealmente, você conseguirá resolvê-los junto com desenvolvedores, sejam os programadores ou usuários.

• Número de forks: Ter muitos forks (ou estrelas) significa que pelo menos há muitos desenvolvedores que se preocuparam o suficiente para dar um fork na biblioteca. Isso não significa que eles vão te ajudar, mas é um começo! Grandes bibliotecas normalmente têm milhares de forks enquanto bibliotecas mais específicas têm centenas ou dezenas de forks.
• Número de problemas: Há muitos problemas abertos? Isso pode ser um sinal de que não há um esforço da comunidade para responder e fechar problemas. Isso pode significar também que trata-se apenas de um projeto muito popular com muitas ideias de melhorias, então continue para o próximo tópico.
• Impressão sobre problemas: Leia alguns problemas e requisições de pull. Os programadores são receptivos a feedbacks? Eles respondem a perguntas sobre seu uso? Você tem uma impressão boa ou ruim dessas conversas?
• Comunidade externa: As perguntas sobre a biblioteca no StackOverflow são respondidas? Há bibliotecas construídas em cima dessa biblioteca? Muitas bibliotecas pequenas não serão grandes o suficiente para possuir uma comunidade externa, mas bibliotecas maiores como Modernizr ou Backbone possuem comunidades externas significativas, e isso é uma grande motivação para usá-las. Você pode realizar uma busca na internet pelo nome da biblioteca e ver que tipo de resultado você encontra.

Essa vai ser uma boa experiência como usuário?

• Tamanho do arquivo: quanto isso vai contribuir para a quantidade de JS que seus usuários precisam baixar? Por exemplo, o jQuery com gzip e reduzido tem 18k e o Select2 tem 7K.
• Performance: além do tamanho, outros aspectos de uma biblioteca JS podem afetar sua performance, como se ela tem muita manipulação DOM, renderização de gráficos, computação, chamadas de armazenamento síncrono, etc. Procure por promessas de boa performance na documentação, e claro, experimente você mesmo.
• Suporte a navegador: verifique se ela suporta todos os navegadores que você deseja. Muitas bibliotecas hoje em dia não suportam navegadores mais antigos (os quais sua página pode precisar suportar), porque elas são projetadas para que sejam leves e apenas para navegadores de dispositivos móveis.
• Acessibilidade: Muitas bibliotecas para componentes de interface de usuário parecem ótimas, mas elas não são acessíveis (elas não funcionam bem para usuários com deficiência visual). Para fazer uma verificação rápida, você pode executar WAVE na página de demonstração da biblioteca.
• Responsividade: se seus usuários forem usar o componente de interface de usuário de uma biblioteca no navegador de um dispositivo móvel, então ela deve funcionar bem em dispositivos móveis. Os botões são grandes o bastante? Ela usa eventos de toque? Ela fornece uma escala para telas de tamanho menor?