Której biblioteki JS powinieneś użyć?

Czy będzie to dobre doświadczenie programistyczne?

• Dobra dokumentacja: Dobrze, jeśli da się łatwo znaleźć spis dostępnych funkcji z ich sygnaturami, przykładami użycia i wyczerpującymi opisami. Jeśli biblioteka nie ma dokumentacji, to zwykle jest to znak, że nie jest bardzo przyjazna programistom.
• Elastyczność: Przykłady użycia podane w dokumentacji mogą wyglądać dobrze, ale być może będziesz chciał wykorzystać tę bibliotekę w trochę inny lub zupełnie inny sposób, niż one pokazują. Sprawdź, czy bibliotekę łatwo przystosować do swoich celów: Czy nie jest trudno ustawiać własnych konfiguracji? Czy są dostępne udokumentowane dodatki/wtyczki? Czy da się samodzielnie zmieniać lub rozszerzać niektóre funkcjonalności?
• Utrzymywanie: Przeglądarki zmieniają się bardzo szybko. Biblioteki, które kiedyś działały, mogą nagle odmówić posłuszeństwa, jeśli mocno opierały się na jakiejś funkcjonalności przeglądarki, która została zmodyfikowana czy usunięta. Dobrym przykładem jest tu dostosowywanie do HTML5 — przeglądarki często wypuszczają nowe wersje z dopiero rozwijającą się obsługą HTML5. Sprawdź datę ostatniej aktualizacji repozytorium w changelog..
• Myślenie przyszłościowe: Jeśli szukasz podkładki do API (ang. ‘shim’), wybieraj raczej tzw. „łatki” (ang. ‘polyfill’), czyli biblioteki naśladujące API. W ten sposób, teoretycznie, jeśli wszyscy użytkownicy Twojej aplikacji będą już korzystali z przeglądarek obsługujących daną technologię, będziesz mógł zrezygnować z używania tej biblioteki, nie zmieniając nic w swoim kodzie. Na przykład, jeśli chcesz zamieścić wideo na stronie internetowej, wybierz łatkę, która pozwoli Ci używać tagu video z HTML5, a w starszych przeglądarkach w ich miejscu użyje technologii „awaryjnej”, takiej jak Flash.
• Przetestowanie: Wszystkie dobre biblioteki powinny zawierać testy, sprawdzające, czy ich funkcje działają, jak powinny. Kiedy biblioteka jest przetestowana, możemy mieć pewność, że jej nowe wersje będą do pewnego stopnia kompatybilne wstecz.
• Przejrzysty kod: Możemy traktować biblioteki typu open source jak czarne skrzynki i nie zaglądać do środka, ale czasem zachodzi potrzeba debugowania czy dodania jakiejś funkcjonalności, kiedy to musimy przekopać się przez jej wnętrzności. Rzuć okiem na kod, zobacz, czy łatwo się go czyta i czy nie ma tam nic odpychającego, np. wielkich połaci zakomentowanego kodu.
• Pomocna społeczność: Będziesz miał pytania. Będziesz napotykał błędy. Najlepiej, jeśli będziesz mógł uzyskać pomoc od innych, czy to programistów, czy użytkowników.

• Liczba rozgałęzień: Dużo rozgałęzień (ang. ‘forks’) oznacza co najmniej to, że wielu programistów dba o bibliotekę. To nie znaczy, że będą dla Ciebie pomocni, ale to już coś. Duże biblioteki często mają tysiące rozgałęzień, podczas gdy bardziej niszowe mają ich po kilkaset czy kilkadziesiąt.
• Liczba wątków w „issues”: Czy jest dużo wątków w dziale „issues”? To może być znak, że nikomu nie chce się na nie reagować i ich zamykać. Może to być też po prostu bardzo popularny projekt, z wieloma pomysłami na ulepszenia — w tym wypadku możesz spokojnie przejść do następnego punktu.
• Atmosfera: Poczytaj kilka wątków w dziale „issues” i przejrzyj „pull requests”. Czy programiści pracujący przy projekcie reagują na opinie wyrażane przez użytkowników? Czy odpowiadają na pytania o sposób użycia elementów biblioteki? Czy w ich wypowiedziach wyczuwasz przyjazne nastawienie?
• Społeczność poza projektem: Czy pytania o bibliotekę doczekują się odpowiedzi na StackOverflow? Czy istnieją inne biblioteki, które z niej korzystają? Mniejsze biblioteki nie będą w Internecie bardzo widoczne pod tym względem, ale większe, takie jak Modernizr czy Backbone, mają znaczne grono odbiorców, od których można uzyskać wsparcie, a to jest wielki plus. Możesz sprawdzić, jakie wyniki pokaże wyszukiwarka internetowa po wpisaniu nazwy biblioteki, którą masz na oku.

Czy użytkownik będzie odczuwał dobre wrażenia?

• Rozmar pliku: Jak bardzo rozmiar biblioteki będzie wpływał na całość? Dla przykładu, jQuery po skompresowaniu waży 18k, a Select2 7k.
• Wydajność: Nie licząc rozmiaru, inne funkcjonalności biblioteki JS mogą wpływać na jej wydajność, na przykład czy manipuluje DOM, rysuje grafikę, oblicza, wykonuje zapytania, itd. Szukaj obietnic programistów i spróbuj sam.
• Wsparcie przeglądarek: Sprawdź czy obsługuje wszystkie przeglądarki. Wiele bibliotek nie obsługuje już starych przeglądarek (być może twoja strona będzie musiała na nich działać), ponieważ mają być lekkie i dostępne dla przeglądarek mobilnych.
• Dostępność: Wiele bibliotek rysujących interfejs wygląda świetnie, ale nie działa dobrze z osobami niedowidzącymi. Możesz sprawdzić bibliotekę dzięki WAVE na stronie z demonstracją.
• Responsywność: Czy użytkownik będzie mógł widział elementy interfejsu na przeglądarce mobilnej? Czy przyciski są odpowiedniej wielkości? Czy korzysta ze zdarzeń dla ekranów dotykowych? Czy skaluje się na mniejszych ekranach?