Коя JS библиотека да избереш

Дали това ще е добро преживяване за разрабочика?

• Добра документация: Трябва да е лесно да се открие информация за сигнатурата на една функция, примери за употребата ѝ, както и по-обстойно ръководство за употреба. Ако една библиотека няма документация, това обикновено е знак, че не е особено лесна за употреба.
• Гъвкавост: Примерите в документацията може да изглеждат добре – но ние може да искаме да използваме една библиотека по малко или по много по-различен начин от този в документацията. Затова търси признаци за гъвкавост – Лесно ли се подават опции за конфигурация? Документирана ли е архитектурата от плъгини? Активират ли се достатъчно много събития, към които можеш да закачиш кода си?
• Активна поддръжка: Браузърите се променят често. Библиотеки, които някога са работили, могат внезапно да спрат да работят, тъй като са разчитали на някаква функционалност на браузъра, която е била премахната. Това е особено валидно за shim и polyfill в HTML5, тъй като браузърите често се обновяват с нови версии на развиващата се имплементация на HTML5 елементите. Можеш да провериш колко скоро е била обновена една библиотека, като прегледаш датата на нейния регистрационен файл с промени. Ако няма такъв файл и библиотеката е хостната в хранилище с отворен код например в GitHub, можеш да провериш датата на последната промяна (commit).
• Мисъл за бъдещето: Ако търсиш "shim" за HTML5, избери "polyfill" – това е shim, който имита API. По този начин, теоретично, когато твоите потребители, които използват браузъри, които са поддържали тази функционалност, ще можеш да изцяло да спреш да използваш тази библиотека, без да има нужда да променяш каквото и да било в кода си. Например, ако използваш библиотека за видео на своята страница, използвай polyfill, който ти позволява да използваш таг video от HTML5 и това ще замени видеото с резервна технология като Flash при по-стари браузъри.
• Тестване: Всички добри библиотеки трябва да включват и тестове, които да гарантират, че функционират правилно. Когато една библиотека е изтествана, можем да разчитаме на това, че в новите версии на библиотеката ще бъдат до известна степен съвместими с предишните версии.
• Чист код: Можем да се отнасяме към библиотеките с отворен код като към черни кутии и да отказваме да надничаме в тях, но понякога ще имаш нужда да се разровиш в кода на библиотеката, за да дебъгнеш някакъв проблем или за да добавиш ново парче функционалност. Хвърли един бърз поглед на кода и прецени колко е лесен за четене и дали съдържа нещо нередно, като големи парчета коментиран код.
• Активна общност: Гарантирам ти, че ще имаш въпроси. И ще се натъкваш на бъгове. Затова би било идеално да можеш да се посъветваш за тях с други разработчици: отговорниците за библиотеката или хората, които я използват.

• Брой на разклоненията (forks): Многото разклонения (или звезди) в Github означават, че има много девелъпъри, които са си направили труда да разклонят библиотеката. Това не означава, че те ще ти помагат, но все пак е някакво начало! Големите библиотеки често имат хиляди разклонения, а по-специализираните библиотеки достигат до стотици и десетки такива.
• Брой проблеми: Има ли много отворени проблеми? Това може да е знак, че не се полагат усилия за отговарянето и затварянето на проблемите. Може също да означава, че проектът е много популярен и има много идеи за подобрение, така че продължи към следващата точка.
• Проверка на проблемите: Прочети няколко проблема и предложените за тях решения – pull request или PR. Дали отговорниците за библиотеката (maintainers) взимат предвид обратната връзка? Отговарят ли да въпроси за употребата? Как ти се струват разговорите – позитивни или негативни?
• Външна общност: Дали има въпроси, на които е отговорено в StackOverflow? Има ли библиотеки, които да надграждат библиотеката? Много малки библиотеки няма да са достатъчно големи, за да имат видима външна общност, но по-големите като Modernizr или Backbone имат значителни общности и това е голям мотиватор за използването им. Можеш да потърсиш името на библиотеката в интернет, за да видиш какви резултати ще получиш.

Дали това ще е добро преживяване за потребителя?

• Размер на файла: Колко ще допринесе библиотеката и колко JS код трябва да свали потребителят? За да се ориентирш, jQuery архивиран и минифициран е 18k, а Select2 е 7K.
• Изпълнение: Освен размера, други аспекти на една JS библиотека също могат да повлияят върху изпълнението като това дали изпълнява тежка манипулация на DOM, зареждане на графики, изчисления, синхронизиране на съхранената информация и т.н. Потърси обещания за добро изпълнение в документацията и, разбира се, тествай кода самостоятелно.
• Поддръжка на бразузъри: Провери дали поддържа всички браузъри, които искаш да използваш. Днес много библиотеки целенасочено не поддържат по-старите браузъри (а на твоята уеб страница може да се наложи да ги поддържа), защото са направени така, че да са леки и да се използват само за мобилни браузъри.
• Достъпност: Много библиотеки за UI компоненти изглеждат страхотно, но не са достъпни (не работят добре за незрящи потебители). За бърза проверка можеш да изпълниш WAVE в страницата с демонстрации на библиотеката.
• Адаптивност: Ако твоите потребители използват UI компонент на библиотеката в мобилен браузър, компонентът трябва да работи добре за тях. Дали бутоните са досатъчно големи? Има ли събития при допир (touch events)? Мащабира ли се за по-малък размер на екрана?