Welche JS-Bibliothek sollte ich benutzen?

Wird es eine Intuitiv für die Entwickler?

• Gute Dokumentation: Es sollte einfach sein, eine Referenz der Funktionsbeschreibung, Beispiele des tatsächlichen Einsatzes und eine detailierte Anleitung zur Verwendung zu finden. Wenn eine Bibliothek keine Dokumentation hat, ist das normalerweise ein Zeichen dafür, dass sie nicht die entwicklerfreundlichste ist.
• Flexibel: Die Demos in der Dokumentation sehen vielleicht großartig aus - aber vielleicht möchtest du eine Bibliothek auf eine leicht oder komplett andere Art und Weise verwenden, als es die Demos zeigen. Achte auf Anzeichen von Flexibilität - Ist es einfach, Konfigurationsoptionen zu verwenden? Gibt es eine dokumentierte Plugin-Architektur? Löst sie viele Ereignisse aus, in die du deinen Code einhängen kannst?
• Aktiv gewartet: Browser ändern sich häufig. Bibliotheken, die einmal funktionierten, können plötzlich aufhören zu funktionieren, weil sie sich auf eine Eigenart des Browsers verlassen, die sich geändert hat. Das gilt besonders für HTML5-Shims und Polyfills, weil die Browser häufig neue Versionen mit sich weiterentwickelnden Implementierungen der HTML5-Elemente herausbringen. Du kannst herausfinden, wanb die Bibliothek zuletzt aktualisiert wurde, indem du das Datum in ihrem Changelog überprüfst. Wenn es kein Changelog gibt und die Bibliothek in einem Open-Source-Repository wie Github gehostet wird, kannst du das Datum des letzten Commits überprüfen.
• Zukunftsorientiert: Wenn du nach einem HTML5-"Shim" suchst, bevorzuge ein "Polyfill" - ein Shim, welches die API nachahmt. Auf diese Weise kannst du theoretisch, wenn alle Ihre Benutzer Browser verwenden, die die Technologie unterstützen, die Bibliothek entfernen, ohne deinen Code zu ändern. Wenn du z. B. eine Bibliothek verwendest, um Video in deiner Webseite zu nutzen, verwende ein Polyfill, das dir die Verwendung des HTML5-Tags video ermöglicht und es in älteren Browsern durch eine Fallback-Technologie wie Flash ersetzt.
• Getestet: Alle guten Bibliotheken sollten Tests enthalten, die sicherstellen, dass ihre Funktionalität wie erwartet funktioniert. Wenn eine Bibliothek getestet ist, dann können wir darauf vertrauen, dass es ein gewisses Maß an Rückwärtskompatibilität in neuen Versionen der Bibliothek geben wird.
• Sauberer Code: Wir könnten Open-Source-Bibliotheken als Blackboxen behandeln und uns weigern, in sie hineinzuschauen, aber manchmal musst du vielleicht in den Code der Bibliothek hineinschauen, um ein Problem zu debuggen oder ein neues Stück Funktionalität hinzuzufügen. Wirf einen kurzen Blick auf den Code und schau, wie einfach er zu lesen ist, und ob er irgendwelche Warnzeichen hat, wie große Stücke von auskommentierten Codezeilen.
• Reaktionsfreudige Gemeinschaft: Du wirst Fragen haben. Du wirst auf Bugs stoßen. Idealerweise wirst du in der Lage sein, diese mit den Entwicklern zu klären, egal ob es sich um die Betreuer oder die Nutzer handelt.

• Anzahl Forks: Viele Forks (oder Sterne) bedeutet, dass es eine Menge von Entwicklern gibt, denen die Bibliothek so wichtig ist, dass diese einen Fork gemacht haben. Das bedeutet nicht, dass sie dir helfen werden, aber es ist ein Anfang! Große Bibliotheken haben oft Tausende von Forks, weniger bekannte Bibliotheken haben 10 oder 100 Forks.
  • Anzahl der Issues: Gibt es viele offene Issues? Das ist ein Zeichen, dass die Community nicht auf offene Issues reagieren und diese behebt. Es kann auch bedeuten, dass es nur ein sehr beliebtes Projekt mit vielen Ideen für Verbesserungen ist.
• Stimmung der Issues: Lies ein paar Issues und Pull-Requests. Sind die Betreuer empfänglich für Feedback? Beantworten sie Fragen zur Verwendung? Spürst du eine positive oder negative Stimmung in den Diskussionen.
• Externe Community: Werden Fragen rund um die Bibliothek auf StackOverflow beantwortet? Gibt es Bibliotheken, die auf dieser Bibliothek aufbauen? Viele kleinere Bibliotheken werden nicht groß genug, um eine sichtbare externe Community zu haben, aber größeren wie Modernizr oder Backbone haben eine erhebliche, und das ist eine große Motivation für ihren Einsatz. Du kannst eine Suche im Internet nach dem Namen der Bibliothek durchführen, um zu sehen, welche Art der Ergebnisse du findest.

Wird die Benutzererfahrung gut?

• Dateigröße: Wie viel zusätzlichen JavaScript Code wird deine Webseite laden müssen? Zum Vergleich, jQuery gzipped und minified ist ca. 18k und Select2 ist ca. 7K.
• Geschwindigkeit: Neben der Größe können auch andere Aspekte wie z. B. viel DOM Manipulationen, Darstellung von Grafiken, Berechnungen, synchrone Aufrufe zur Speicherung etc. einer JS Bibliothek ihre Geschwindigkeit beeinflussen. Suche für Hinweise guter Performance in der Dokumentation und teste die Bibliothek nach diesem Aspekt.
• Browserunterstützung: Prüfe, ob sie alle gewünschten Webbrowser unterstützt. Heutzutage unterstützen viele Bibliotheken bewusst ältere Webbrowser, welche deine Webseite ev. unterstützen muss, nicht mehr, da sie für mobile Browser schlank designed sind.
• Accessibility: Viele Bibliotheken für UI-Komponenten sehen zwar gut aus, aber sie sind nicht "accessible" (sie funktionieren nicht gut für Benutzer mit Sehbehinderungen). Für einen kurzen Test kannst du WAVE auf der Demoseite der Bibliothek ausführen.
• Responsive: Wenn deine Benutzer die UI-Komponenten der Bibliothek auf einem Mobile-Browser benutzen, dann sollte diese auch darauf gut funktionieren. Sind die Buttons groß genug? Benutzt sie Touch-Events? Skaliert das Benutzerinterface gut auf kleinen Bildschirmen?