Quelles bibliothèques JS devez-vous utiliser ?

S’agira-t-il d’une bonne expérience pour le développeur ?

• Elle est bien documentée : il doit être facile de trouver une référence avec les signatures de fonctions, des démos concrètes, et un guide d'utilisation bavard. Si une bibliothèque ne possède pas de documentation, c'est généralement un signe qu'elle n'est pas vraiment des plus agréables à utiliser pour les développeurs.
• Elle est flexible : Les démos dans la documentation pourraient être impressionnantes, mais il se pourrait que nous souhaitions utiliser la bibliothèque d'une manière légèrement, ou même complètement, différente que ce qu'elles montrent. Cherchez des indices de flexibilité. Est-il facile de passer des options de configuration ? Y a-t-il une architecture de plugin documentée ? Déclenche-t-elle beaucoup d'événements sur lesquels vous pourriez amorcer votre code ?
• Elle est maintenue activement : Les navigateurs évoluent fréquemment. Les bibliothèques qui marchaient avant peuvent soudainement arrêter de fonctionner, car elles s'appuyaient sur une bizarrerie du navigateur qui a été modifiée. C'est particulièrement vrai à propos des shims et polyfills HTML5, car les navigateurs sortent fréquemment de nouvelles versions avec des implémentations évolutives des éléments HTML5. Vérifiez la date du plus récent 'commit'.
• Elle anticipe l'avenir : Si vous cherchez un "shim" HTML5, préférez un "polyfill" (un shim qui imite l'API). De cette façon, théoriquement, quand tous les utilisateurs utiliseront des navigateurs qui supporteront la technologie, vous pourrez complètement arrêtez d'utiliser la bibliothèque, sans faire aucun changement dans votre code. Un bon exemple est l'utilisation d'une bibliothèque qui utilise la balise video HTML5, et qui la remplace par une technologie alternative comme Flash, sur les navigateurs anciens.
• Elle est testée : Toute bonne bibliothèque doit contenir des test pour vérifier que les fonctionnalités agissent comme prévu. Quand une bibliothèque est testée, on peut s'attendre à un certain degré de rétrocompatibilité dans les nouvelles versions.
• Son code est propre : On peut traiter les bibliothèques open-source de boîtes noires, et refuser de regarder à l'intérieur, mais quelquefois, vous pourriez avoir besoin de farfouiller dans le code de la bibliothèque pour déboguer un problème, ou ajouter une nouvelle fonctionnalité. Jetez rapidement un œil au code pour voir s'il est facile à lire, s'il y a des alertes, comme de gros morceaux de commentaires en dehors des lignes de code.
• Sa communauté est réactive : Vous aurez des questions. Vous rencontrerez des bogues. Dans l'idéal, vous devez être capable de voir cela avec des développeurs, qu'ils soient chargés de la maintenance ou que ce soit d'autres utilisateurs.

• Le nombre de forks : beaucoup de forks (ou étoiles) signifie qu'il y a beaucoup de développeurs qui s'y intéressent, suffisamment pour créer des embranchements à la bibliothèque. Cela ne veut pas dire qu'ils vous aideront, mais c'est un début ! De grosses bibliothèques ont souvent des milliers de forks. Des bibliothèques spécialisées en ont des dizaines à des centaines.
• Le nombre de problèmes : Y a-t-il beaucoup de problèmes déclarés ? Cela pourrait être le signe qu'il n'y a pas d'effort réactif de la part de la communauté pour clore les problèmes. Cela peut aussi signifier que c'est un projet très populaire, qui développent de nombreuses améliorations, donc lisez le point suivant.
• L'atmosphère autour des problèmes : Parcourez quelques problèmes et propositions d'amélioration ('pull requests'). La maintenance est-elle réceptive aux retours ? Répond-elle aux questions ? Ressentez-vous des ondes positives ou négatives en lisant les conversations ?
• La communauté externe : les questions sur la bibliothèque obtiennent-elles des réponses sur StackOverflow ? Existe-t-il des bibliothèques qui sont construites à partir de cette bilbliothèque ? De nombreuses petites bibliothèques ne sont pas assez imposantes pour créer une communauté externe visible, mais de plus grosses, comme Modernizr ou Backbone, en détiennent de significatives, et c'est une réelle motivation pour les utiliser. Vous pouvez faire une recherche sur Internet sur le nom d'une bibliothèque pour voir quel résultat on obtient.

S’agira-t-il d’une bonne expérience pour l'utilisateur ?

• Taille du fichier : de combien il contribuera à la quantité de JS que vos utilisateurs devront télécharger ? Dans ce contexte, jQuery, compressé et minifié, fait 18ko et Select2, 7Kio.
• Performance : en plus de sa taille, d’autres aspects d’une bibliothèque JS peuvent affecter ses performances, si elle fait d'importantes manipulations du DOM, des rendus graphiques, du calcul, des appels à stockage synchrone, etc. Cherchez des promesses d’excellentes performances dans la documentation et bien sûr, testez vous-même.
• Support des navigateurs : vérifiez qu’elle prend en charge tous les navigateurs désirés. Beaucoup de bibliothèques, aujourd'hui, ne supportent délibérément pas les navigateurs plus anciens (que votre page Web pourrait avoir besoin de supporter), parce qu’elles sont conçues pour être légères ou fonctionner seulement sur des navigateurs pour mobiles.
• Accessibilité : beaucoup de bibliothèques de composants d’interface utilisateur affichent un bon rendu, mais elles ne sont pas accessibles (elles ne fonctionnent pas bien pour les utilisateurs ayant une déficience visuelle). Pour une vérification rapide, vous pouvez exécuter WAVE sur la page de démonstration de la bibliothèque.
• Adaptative : si jamais vos utilisateurs utilisent le composant d’interface utilisateur d’une bibliothèque sur un navigateur mobile, il doit correctement fonctionner pour eux. Les boutons sont-ils assez gros ? Utilise-t-il les événements tactiles ? S’adapte-t-il à la taille des petits écrans ?