Frameworks – braucht’s die eigentlich noch?
Von Brennpunkten in der IT-Landschaft und neuen Interpretationen alter Probleme
Von: Katja Potensky
Ich bin zwar nicht bekannt dafür, aus der Bibel zu zitieren, aber hin und wieder passt eine Passage einfach:
Es gibt nichts neues unter der Sonne. – Prediger 1,9
Daran fühlte ich mich letzte Woche erinnert bei einer Diskussion zur Frage, ob es Frameworks noch brauche. Du kannst dir sicher vorstellen, wie lebhaft solch ein Diskurs geführt wird. In den folgenden Absätzen möchte ich die verschiedenen Blickwinkel sowie meine Two Cents zum Thema Frameworks mit euch teilen.
Was ist überhaupt ein Framework?
Ein Framework ist eine Sammlung von Software mit einer zugehörigen Sammlung an Kompromissen. – Peter Kröner
Diese Definition kam zu Beginn der angesprochenen Diskussion auf und ich halte sie für die erste sinnvolle überhaupt. Denn sie deutet bereits darauf hin, dass wir es hier nicht mit einer rein technischen Fragestellung zu tun haben. Dennoch möchte ich den technischen Blickwinkel als Ausgangspunkt wählen.
Worin liegt der technische Bedarf?
Gibt es einen technischen Bedarf für C oder Java? Warum programmieren wir nicht alle einfach Assembler? Der Bedarf richtet sich nicht nur nach den Zielen, sondern auch nach den Aufwänden. Man wollte irgendwann nicht mehr in Assembler programmieren, also haben schlaue Menschen begonnen, die typischen Aufgaben zu abstrahieren und irgendwann kam unter anderem C dabei raus. Später hat sich herausgestellt, dass man auch in C viele wiederkehrende Aufgaben lösen musste, also hat sich über ein paar Umwege Java ergeben. Du siehst also, das Ganze ist ein iterativer Prozess.
Auf solchem Wege wurde auch die Aufgabe, ein buntes Kästchen im Browser zu bauen, in das man etwas reintippen kann, immer mehr abstrahiert. Diese Abstraktionen wurden zu den Frameworks, die wir heute kennen. Mittlerweile sind wiederum viele bis alle typischen Aufgaben zum Erstellen einer BLOBA (Boring Line-of-Business Application), bei denen ein Framework in den letzten zehn Jahren geholfen hat, durch Erweiterungen der Webstandards ohne größere oder sogar mit weniger Problemen umsetzbar.
Ich rate hier dringend dazu, auf MDN die Liste der HTML-Elemente alle paar Jahre durchzugehen, genauso wie die Liste der Web-APIs. Dialoge, Dropdowns oder auch die meisten Validierungen sollte man im Jahr 2024 wirklich nicht mehr mit einer teuren Component Library umsetzen.
Auch wenn es um das Thema Bundling und CI/CD geht, lohnt sich ein Blick über den Tellerrand. Gerade hier führt der Einsatz schwergewichtiger Lösungen gerne zu unvorhergesehenen Problemen.
Tipp: „Code is a liability, not an asset“ gilt auch für jenen Code, den wir nicht selbst schreiben. Wenn sich Abhängigkeiten ungünstig verhalten, ist meistens das einzige, was wir heutzutage tun können, einen Bug Report zu erstellen und die Ohren steif zu halten. Oder hast du schon mal probiert, eine geforkte Version von Angular auszurollen? ;)
Aber gut, dieses Argument schaut auf die bisherigen Umstände. Was ist, wenn wir in die Zukunft blicken?
Der Blick nach vorne
Gehen wir rein theoretisch davon aus, dass Angular, React, Vue etc. ihre Repositories und Packages löschen und wir alle unsere BLOBAs mit HTML und gezielt eingesetztem Javascript bauen.
Einer der Trends unserer Zeit ist ganz klar KI, man kann heutzutage im Browser mittels WebGPU Zugriff auf die GPU erlangen. Jetzt wäre es nicht allzu weit hergeholt, dass für diverse Use-Cases auf vielen Websites Chatbots implementiert werden sollen. Und zwar auf so vielen, dass es sich zur Vereinfachung des Anwendungsfalls auszahlt, Libraries darum herum zu schreiben. Vielleicht kommen auch Bezahlmöglichkeiten mittels Payment Request API dazu und ein paar andere Dinge, die so typisch werden, dass wir wiederum eine Reihe von Libraries unter der Annahme von gewissen Kompromissen auf eine spezifische Art und Weise verbinden, die wir gut finden… und prompt haben wir unser nächstes Framework geschaffen.
Wir können also davon ausgehen, dass es immer (neue) Frameworks geben wird. Denn so wunderbar die Webstandards sind, sie können und sollen eben nicht meinungsgetrieben sein. Selbst die Gamepad API existiert, weil es ausreichend Bedarf dafür gab und nicht umgekehrt. Neue Bedürfnisse sollten nicht durch Webstandards verprobt werden, sondern durch Libraries und Frameworks. Aber wer würde solche neuen Frameworks wohl verwenden?
„Apes together strong“
Wie viele Frameworks, die uns geholfen haben Formulare und Seitennavigationen zu bauen, gibt es wohl?
2011 habe ich einige JS-Files geschrieben, die mittels beliebiger Attribute an HTML-Elementen diese Elemente um eine beliebige Funktionalität erweitern können. Das weiß kaum jemand, da ich diese Idee zum einen nicht verbreitet habe. Zum anderen wurde ich ein paar Wochen später mit AngularJS konfrontiert und dachte mir: „Hey, die Idee hatte schon jemand.“ Also habe ich meinen eigenen Code verworfen und stattdessen AngularJS eingesetzt, weil es zum damaligen Zeitpunkt genau das tat, was ich zum damaligen Zeitpunkt brauchte. Es gibt Ideen, um die Menschen sich versammeln, und das hat gleich mehrere Auswirkungen.
Brennpunkte
Egal ob man diesen Ansatz gut findet oder nicht, egal ob man React oder Angular mag – durch die Existenz von Frameworks bilden sich gewissermaßen Brennpunkte in der IT-Landschaft. Orte, an denen Menschen zusammen kommen, ihre Ideen einbringen und Richtlinien rund um die vermeintlich korrekte (idiomatische) Verwendung der jeweiligen Lösung erarbeiten.
Diese Richtlinien mögen uns gefallen oder nicht, sie ermöglichen einen effizienteren Austausch in Projekten und ein schnelleres Onboarding von neuen Personen. Durch die kontinuierliche Anwendung dieser Richtlinien werden sie innerhalb gewisser Grenzen laufend verbessert. Aber was, wenn man an diese Grenzen stößt und sich nicht damit abfinden will?
Dissonanz
Zu Deutsch: Unstimmigkeit, Missklang. Stell dir vor, du kannst nicht damit leben, dass AngularJS die Änderungen an Objekten periodisch und recht teuer auf den Bildschirm bringt. Ganz egal, wie viel optimiert wird, hier ist das grundlegende Konzept das Problem und irgendwann stößt man an die Grenzen des technisch Möglichen.
Wenn das ein Knockout-Kriterium ist, muss man besagten Brennpunkt verlassen, zurück ans Zeichenbrett und von Null auf neue Wege gehen. Das mag erst mal unglaublich schwer klingen, aber man hat einige gewaltige Vorteile dabei: Man weiß, was das Problem ist, wie man es nicht löst und was die Erwartungshaltungen sind.
Und nach ein paar Monaten Hin und Her, Recherche und Trial-and-Error hat man dann wahrscheinlich einen Weg, um den Anwendungsfall, an dem die vorige Idee gebrochen ist, besser umzusetzen. Um es mit den Worten von Soichiro Honda zu sagen:
„Racing improves the breed.“
Die Frage ist dann eher, ob das, was wir jetzt besser machen können, die Verbesserung überhaupt verdient hat.
Ein alter Hut?
Sind Frameworks also bloß immer neue Interpretationen von ewig alten Problemen? Nun, irgendwie schon, aber irgendwie auch nicht. Mir fällt hierzu eine Anekdote ein. Ich fand Liebeslieder immer kitschig und sinnlos, bis ich mal einen Musiker bei einer Show sagen hörte: „Natürlich wurden die Worte ‚I love you‘ schon tausende Male vertextet, natürlich ist jedes Liebeslied irgendwie gleich. Aber vielleicht, nur vielleicht, wurde es ja noch nicht mit den selben Gefühlen gesungen, die du dabei spürst. Und selbst wenn, warum sollte dich das davon abhalten, ‚I love you‘ zu sagen?“
Vielleicht können wir darüber hinweg sehen, welches Framework technisch besonders ausgefeilt ist, und einfach das verwenden, das am besten zur aktuellen Situation passt. Und wenn die aktuelle Situation bloß erfordert, eine Reihe von Formularen zu erstellen, könnte man ‚I love you‘ mal ganz ohne jegliche Schnörkel sagen. Denn der größte Brennpunkt in der IT-Landschaft sind immer noch die Webstandards.
Über die Autorin: Katja Potensky
Katja ist Software Engineer bei adesso und seit 2012 in einem professionellen Setting tätig. Sie lässt sich nicht auf einzelne Aspekte eines Systems limitieren, und hat von daher schon eine Vielzahl an Projekten in unterschiedlichsten Rollen und Teamgrößen umgesetzt. Aus der Arbeit mit unterschiedlichsten Webtechnologien hat sich ein fundierter Anspruch an Codequalität und korrektes Programmverhalten entwickelt den sie auch weitergeben möchte. Sie brennt für Code der leicht zu lesen ist und nicht bedingt die halbe Codebase im Kopf zu behalten um zu verstehen was “da gerade passiert”.