Wer in der Software-Entwicklung arbeitet, kennt das Problem: Es wird ein Tool genutzt, das dem Projekt nicht zu 100 % gerecht wird. Was anfangs trivial erscheint, kann spĂ€ter entscheidend sein: die Wahl des passenden Toolsets. Verkommt die Auswahl des Toolsets vor Projektstart zur Nebensache, fĂ€llt die Entscheidung nicht selten auf ein ĂŒber- oder gar unterentwickeltes Werkzeug. HĂ€ufig wird dann ein kompliziertes Refactoring der bereits entwickelten Anwendung unternommen, das zu retten versucht, was noch zu retten ist. Nicht nur, dass die Erfolgsaussichten dieser Methode gegen Null gehen: Am Ende verschlingt das Refactoring auch noch jede Menge Zeit und Ressourcen. Auch wir bei denkwerk stehen immer wieder vor der Frage nach dem passenden Toolset, da wir von Zeit zu Zeit mit einer Vielzahl von Projekten konfrontiert werden.
Projekte haben unterschiedliche Anforderungen, Ziele, Fristen, Budgets usw. Deshalb ist es wichtig, bei der Wahl des Tools die Rahmenbedingungen nicht aus den Augen zu verlieren. Folglich setzen wir uns vor jedem Projekt an den Denktisch. Letâs talk! Bei der richtigen Wahl des Tools werden ĂŒber alle verfĂŒgbaren Optionen des jeweiligen Werkzeugs diskutiert. Dabei setzen wir auf Schwarmintelligenz und teilen beispielsweise viele Erfahrungen unseres JavaScript-Teams, um die Alternativen besser abwĂ€gen zu können, die uns die JavaScript-Plattformen bieten.
Doch eins ist klar: Es gibt nur einen Weg, um festzustellen, ob ein Tool oder Toolset fĂŒr ein Projekt geeignet ist. Das Tool muss ausprobiert werden, um alle Vor- und Nachteile zu verstehen. Denn egal, wie viel wir ĂŒber etwas lesen oder dazu recherchieren â es ist immer schwierig, ein Werkzeug ohne praktische Erfahrung zu beurteilen. Das Experimentieren mit Tools ist und bleibt daher ein essenzieller Teil unserer Arbeit â besonders fĂŒr interne Projekte.
Neben Design zĂ€hlt die Frontend-Entwicklung zu unseren StĂ€rken. In JavaScript können wir aus einer Vielzahl an Optionen wĂ€hlen. FĂŒr die Entwicklung von Frontend-Anwendungen greifen wir auf Frameworks bzw. Bibliotheken wie React, Vue, Angular, Nuxt oder Next zurĂŒck. All diese Tools haben ihre eigenen Vor- und Nachteile.
Unser De-facto-Tool ist heutzutage zunehmend React, und zwar aus mehreren GrĂŒnden: Technisch gesehen lĂ€sst sich mit React das Gleiche bauen wie mit Angular oder Vue oder anderen weniger bekannten Tools (und umgekehrt). Aber als JavaScript-Team lieben wir die Arbeit mit React schon allein deshalb, da es uns ermöglicht, rein in JavaScript zu denken und dabei fast die gesamte FlexibilitĂ€t der Sprache zu nutzen. Wir mĂŒssen nicht viel neuen syntaktischen Zucker lernen, um unsere Anwendungen durchzufĂŒhren und können uns auf das Schreiben von Code konzentrieren. Auch die Community und die enorme UnterstĂŒtzung fĂŒr React machen dieses Tool fĂŒr uns zu einem sicheren Werkzeug fĂŒr Projekte mit langer Laufzeit. Was nicht heiĂen soll, dass wir andere Tools auĂer Acht lassen. Im Gegenteil: Um ein GefĂŒhl fĂŒr die gesamte Bandbreite an Tools zu gewinnen, berĂŒcksichtigen wir auch andere Meinungen in unserem Team wie auch in anderen Teams.
Wir haben verschiedene Tools ausprobiert. Zum Beispiel haben wir VueJS fĂŒr ein Team mit Design-/Template-Design-Hintergrund verwendet, da wir dachten, dass es viel einfacher ist, die reine HTML-Ă€hnliche Templating-Syntax in Vue zu erfassen. Das Verstehen eines JavaScript-Frontend-Frameworks geht dadurch deutlich leichter, anstatt das gesamte Team React lernen zu lassen.
Dann kam der Relaunch unserer Firmenwebseite und wir dachten uns: Lasst uns mal andere Anforderungen stellen als bei vorherigen Projekten. Klar war: Die Website benötigt eine gute Suchmaschinen-Optimierung (SEO) und eine bessere Rendering-Zeit als unsere bisherige Website mit ihren vielen Design-Komponenten. AuĂerdem werden hauptsĂ€chlich Daten mit einer sehr begrenzten Interaktion abgerufen wie auch angezeigt und zusĂ€tzlich soll es einen Blog-Bereich geben. In Anbetracht all dieser Anforderungen haben wir uns fĂŒr NuxtJS entschieden. Es bietet einen guten Baustein fĂŒr serverseitiges Rendering, löst viele Probleme im Zusammenhang mit SEO und ermöglicht uns die FlexibilitĂ€t des VueJS-Frameworks. Da die meisten Daten fĂŒr die Website statisch sind und sich kaum Ă€ndern, hielten wir es fĂŒr klĂŒger, einen Dienst wie Contentful zu nutzen, um all unsere Daten zu speichern. So mussten wir auch gar nicht erst einen eigenen Backend-Api-Dienst aufbauen. Der Vorteil: Die Wartungskosten und der Aufwand fĂŒr das Projekt wurden dadurch reduziert.
Kommen wir zum Fazit: Bei denkwerk sind wir offen fĂŒr alle Arten von Ideen und Technologien. Wir glauben, dass erst dann das passende Toolset gefunden werden kann, wenn vorab alle Optionen bedacht wurden.