Bevor wir genauer hinschauen, was es mit dem Framework-Hype dieser Tage auf sich hat, definieren wir erst mal sauber, was ein Framework überhaupt ist. Schaut man sich die diversen Definitionen im Weltennetz an, dann lässt sich wohl folgendes als kleinster gemeinsamer Nenner ausfiltern:

Ein Framework bildet ein Grundgerüst für eine Anwendung oder eine Gestaltung oder beides. Es legt immer Strukturen fest, an der Entwickler und Designer sich bezüglich der Funktionalität oder des Designs orientieren können. Dabei will ein Framework stets möglichst umfassende Strukturen zur einfachen Wiederverwendung liefern.

So. Auffallend ist sicherlich, dass unter dieser Definition betrachtet vieles, was sich heutzutage so nennt, im Grunde gar kein Framework ist, sondern vielmehr ein Toolkit, ein rudimentärer Ansatz, ein peripheres Hilfsmittel. Wir haben es auf einen Schlag mit weit weniger Frameworks zu tun, als wir vielleicht zunächst dachten.

Da haben wir schon den ersten Erkenntnissatz gefunden: Nicht alles, was als Framework bezeichnet wird, ist auch eines.

Und wenn es denn dann keines ist, brauchen wir uns auch nicht darüber aufzuregen, dass es nicht als solches zu gebrauchen ist. Ärgerlich ist dann vielmehr, dass jeder mittelbegabte Entwickler schnell von seinem Framework spricht, anstatt sein kleines Helferlein als das zu bezeichnen, was es tatsächlich ist.

Sicherlich stellt sich generell die Frage, warum Entwickler offenbar gerne in großem Stile ihre Zeit damit verblasen, das Rad neu zu erfinden und unzählige Werkzeuge für den gleichen Task zu erstellen. Das erschließt sich mir auch nach langem Nachdenken nicht. Ich versuche, Projekte stets so rationell wie möglich abzuwickeln.

Da sind wir nämlich schon bei der Aufgabe eines guten Frameworks angekommen. Die Verwendung eines Rahmengerüsts soll den Bau des Hauses beschleunigen und in Struktur bringen, also gleichermaßen neben der Geschwindigkeitssteigerung eine Art Qualitätssicherung gewährleisten.

Frameworks bieten homogene Vorgehensweisen, wiederverwendbare Komponenten und manchmal auch ein Designkonzept. So wird die Abwicklung eines Webprojektes in mehrerlei Hinsicht rationeller.

Wird ein Framework auf breiter Front eingesetzt, besteht zudem ein Vorteil darin, dass es eine große Community gibt, mit der man sich über optimale Vorgehensweisen erbaulich austauschen kann. Am Ende ist die Verwendung eines etablierten Frameworks so tatsächlich einfacher. Das gilt umso mehr, je weniger Grundkenntnisse der Verwender hat.

Wobei in letzterem Aspekt wieder ein Risiko liegt, denn wird ein gutes Framework schlecht angewendet, bringt es mit großer Wahrscheinlichkeit kein gutes Ergebnis. Aufgrund der teils überdeckenden Wirkung des eingesetzten Gerüsts fällt die miserable Projektqualität unter Umständen erst auf, wenn es zu spät ist. Ich musste mal ein Projekt übernehmen, das mit Zend realisiert worden war, was im PHP-Bereich eigentlich als etabliert gelten darf. Das blanke Entsetzen suchte mich heim, als ich den Code inspizierte.

Ist man nun ein Webentwickler auf dem aktuellen Stand des Wissens, so wird man in Projekten immer wieder vor der Frage stehen, welches Framework man zu welchem Zweck sinnvollerweise einsetzen könnte. Das ist in Ordnung. Leider wird das aber nicht die Regel sein.

Meiner Beobachtung nach ist die weitaus größere Zahl an Webentwicklern eben nicht auf dem aktuellen Stand des Wissens und dementsprechend genau nicht in der Lage, eine qualifizierte Auswahl hinsichtlich des einzusetzenden Frameworks zu treffen. Vielmehr wird wahlweise das neuste, gerade gehypete Framework, das am einfachsten zu erlernende oder das gewählt, das man schon immer eingesetzt hat und das man dementsprechend am besten beherrscht. Mit qualifizierter Auswahl hat das alles nichts zu tun.

Immerhin muss man konstatieren, dass jedes Framework erschaffen wurde, um ein bestimmtes Ziel zu erreichen. Dieses Ziel muss noch lange nicht dem Ziel deines Projekts entsprechen. Und weil das so ist, kann es durchaus passieren, dass dich ein Framework mehr einschränkt, als es dir nützt, weil es halt schlichtweg nicht auf deinen Anwendungsfall passt. So kommt es, dass du versuchst, eine Schraube mit der Grillzange in die Wand zu drehen. Das mag am Ende funktionieren, aber irgendwer oder irgendwas wird darunter leiden.

„Komm bloß nicht auf die Idee, ein Framework zu programmieren!“

Es geht also immer wieder neu darum, das richtige Framework für den passenden Anwendungsfall zu finden. Schlag den Nagel mit einem Hammer in die Wand, dreh die Schraube mit einem Schraubendreher rein – niemals umgekehrt. Das bedeutet nicht, dass Hammer oder Schraubendreher schlechte Werkzeuge sind, im Gegenteil. Für ihren jeweiligen Anwendungsfall gibt es nichts Besseres.

So verhält es sich auch mit Frameworks. Schau genau hin, welches was leisten will und dann tatsächlich kann. Versuch nicht, ein Framework für eine Aufgabe zu verbiegen, für die es nicht geschaffen wurde, bloß weil dir jemand erzählt hat, coole Entwickler würden heute nur noch mit XYZ arbeiten.

Nachdem wir gemeinsam festgestellt haben, dass es eigentlich gar nicht so viele Frameworks gibt, können wir uns diesbezüglich schon mal entspannen. Für ein neues Projekt schauen wir jetzt qualifiziert, welche Frameworks für den Anwendungsfall zur Wahl stehen und testen sie anhand der Basisanforderungen kurz durch. Wir stellen uns auch die Frage, ob es überhaupt eines Frameworks bedarf. Kleine Projekte erstellen wir freihändig, wir wollen schließlich nicht mit Kanonen auf Spatzen schießen.

Was wir auf keinen Fall machen? Ein Framework erstellen! ;-)