Eine häufige Frage von Kunden betrifft die Auswahl eines JavaScript-Frameworks. Um es von vorne herein zu sagen: Es gibt auf diese Frage keine einfache Antwort. In diesem Artikel sollen ein paar Denkanstöße gegeben werden.

Im Laufe der Jahre haben wir einige JavaScript-Frameworks erlebt. Angefangen von Prototype, über Dojo, jQuery, AngularJS, React und Angular, nur um einige zu nennen. Das schnelle Aufblühen und Verblassen von JavaScript-Frameworken lässt die Frage aufkommen, ob nicht natives JavaScript eine einfachere Lösung sei. Statt alle paar Jahre wieder ein neues Framework zu lernen, könnte das Entwicklungsteam seine eigenen Module mit wiederverwendbarem Code erstellen.

Sofern die Umgebung, die es zu unterstützen gilt, klein genug ist, könnte diese Herangehensweise valide sein. Das trifft meistens bei Web-Anwendungen zu, die nur im eigenen Unternehmen eingesetzt werden. Doch spätestens wenn ein Mitarbeiter aus der Management-Ebene ein neues Tablet oder Smartphone hat, könnte sich die Liste der unterstützten Browser/Geräte als zu kurz erweisen. Schnelle Update-Zyklen bei Geräten und/oder Browsern kann diesen Ansatz sehr schnell in einen aussichtslosen Wettlauf verwandeln.

Aus unternehmerischer Sicht ist es existenziell, die vorhandenen Ressourcen so effizient wie möglich einzusetzen. JavaScript-Frameworks helfen dabei auf vielfältige Weise.

Wie eben ausgeführt, ist die Unterstützung von möglichst vielen Plattformen und Browsern ein absoluter Vorteil. Die wenigsten Entwicklungsabteilungen sind in der Lage, jede erdenkliche Kombination zu testen. Wenn das eingesetzte Framework eine ausreichende Verbreitung hat, erhöht sich die Chancen, dass alle wichtigen Kombinationen abgedeckt sind. Kommt eine neue Browser-Version heraus, mit der es eventuell ein Problem geben könnte, wird das hoffentlich schon in der Beta-Phase herausgefunden. Spätestens nach der Verfügbarkeit der neuen Browser-Version in der Masse, wird auch jemand zumindest einen Work-around gefunden haben. Ein kleines Entwicklerteam mit nur selbst geschriebenen Komponenten könnte dieses gar nicht leisten.

Statt alle Komponenten selber zu schreiben, kann aus einer Vielzahl von vorhandenen Open-Source-Komponenten ausgewählt werden. Sollte eine Eigenschaft der ausgewählten Komponente nicht den eigenen Vorstellungen entsprechen, kann diese Eigenschaft geändert werden, weil es sich um Open-Source handelt.

Für neue Mitarbeiter ist es wesentlich einfacher, sich in ein bekanntes JavaScript-Framework einzuarbeiten, weil die Anzahl der Tutorials, Blog-Einträge und Bücher wesentlich größer ist. In kleinen Entwicklungsteams ist die Zeit für Dokumentation meistens eng bemessen.

Die Frage, welches das "Beste" JavaScript-Framework ist, wird teilweise mit einer Vehemenz geführt, die an religiöse Fragen heranreicht. Die traurige Wahrheit ist, dass die einzige Konstante in diesem Bereich der stete Wandel ist. Früher oder später wird es eine bessere Alternative geben. War in dem einem Jahr AngularJS noch die ultimative Wahl, so war im nächsten Jahr React dominant. Allerdings hielt diese Dominanz nur vor bis Angular mit einer neuen Architektur herauskam.

Was bedeutet dieses Wissen für den Auswahlprozess? So dramatisch, wie es sich im ersten Moment anhört, ist es in der Praxis tatsächlich selten. Zum einen bleiben die grundlegenden Strukturen und Konzepte der Web-Entwicklung über einen längeren Zeitraum stabil. Je mehr Erfahrung man hat, desto leichter fällt es, sich in ein neues Framework einzuarbeiten. Auf dem Fundament des bisherigen Wissens kann man zu neuen Höhen hinaufsteigen.

Zum anderen muss immer wieder evaluiert werden, ob das vermeintlich bessere Framework tatsächlich ein Problem des aktuell eingesetzten Frameworks löst, was in den eigenen Projekten auftritt. Wenn z.B. der versprochene Performance-Gewinn gar nicht so entscheiden ist, weil die bisherigen Projekte in dem Aspekt völlig zufriedenstellend waren, besteht kein Grund, aktiv zu werden.

Stets gilt es zu evaluieren, ob die neuen Features tatsächlich zu einer Effizienzsteigerung bei der Entwicklung führen. Die Anwender interessieren sich nicht dafür, mit welchem Framework die Anwendung realisiert wurde. Sie interessieren sich dafür, ob sie ihren Zweck erfüllt. Selbstverständlich sind aus Auftraggebersicht die zu veranschlagenden Kosten wichtig.

Die folgenden Kriterien sollten bei einer Auswahl berücksichtigt werden

• Deckt das Framework die gewünschten Einsatzszenarien ab?
• Hat es eine ausreichende Verbreitung, sodass eine lange Lebensdauer wahrscheinlich ist?
• Gibt es genug Ressourcen, um das Framework zu erlernen?
• Ist die Community ausreichend groß, sodass Fragen leicht beantwortet werden können?
• Lassen sich viele schnell einsetzbare Komponenten finden?

Wir haben im Laufe der Jahre tatsächlich mit allen oben aufgeführten Frameworks (Prototype, dojo, jQuery, AngularJS, React und Angular) Erfahrungen gesammelt. Aktuell gefällt uns Angular am Besten.

Die Performance der entstehenden Anwendungen ist ausgezeichnet. Im Internet erschlägt einen die Menge der zur Verfügung stehenden Ressourcen. Mit Visual Studio Code und seinen Erweiterungen gibt es die optimale Unterstützung beim Entwickeln. Das sind alles gute Gründe für den Einsatz.

Der ausschlaggebende Grund waren aber die Erfahrungen aus den vorherigen Frameworks, die als Best Practice direkt in das Framework geflossen sind. Wenn mit dem Angular Command Line Interface - CLI ein neues Projekt erstellt wird, wird automatisch eine sinnvolle Verzeichnisstruktur vorgegeben. Für alle Phasen der Entwicklung gibt es passende Toolunterstützung.

Für die Business-Anwendungen, die wir primär als Web-Anwendungen entwickeln, können wir uns somit auf den wichtigsten Aspekt konzentrieren: die Wünsche unserer Kunden.