Warum ich keine Frameworks verwende

Ein Framework ist kostenloser, vorgefertigter Programmcode von Drittanbietern. Jeder kann (s)ein Framework anbieten. Jeder Entwickler kann beliebige Frameworks bei der eigenen Arbeit verwenden. Es gibt zu jedem Zeitpunkt Dutzende Frameworks. Manche leben länger, manche sind Eintagsfliegen. Manche werden passabel gewartet, manche sind voller Bugs. Viele stammen von Hobbyprogrammierern, die das Programmieren letzten Sonntag für sich entdeckt haben. Manche werden von einem geschlossenen Personenkreis unterhalten, bei manchen kann jeder mitmischen. Manche sind (zu einem gegebenen Zeitpunkt) recht populär, manche werden nur von einer Handvoll Exoten genutzt. Wie dem auch sei: Frameworks sind für den Entwickler der sie nutzt kostenlos - der Endkunde aber zahlt dem Entwickler das normale Projekthonorar.

Warum gibt es Frameworks?

Weil heute jeder einen Computer zuhause hat. Spass beiseite: Frameworks meinen es ja gut mit dem überforderten Entwickler. Frameworks wollen Inkompatibilitäten zwischen den Plattformen verbergen. Sie wollen die Komplexität einer Programmiersprache bzw. einer Technologie verstecken, damit der Entwickler "ganz einfach und schnell" ein Projekt erstellen kann. Ein Framework will die eierlegende Wollmilchsau für alle Webprojekte sein, es soll also möglichst generell einsetzbar sein. Sie wollen Profis entlasten und erfahrungsfreien "Quereinsteigern" ermöglichen, ohne tieferes Studium der Technologie schnell ein (geldwertes) Web-Projekt aufzustellen. Sie wollen Quasi-Standards etablieren, wie bestimmte Aufgaben in der Webentwicklung am besten gelöst werden sollten. Hört sich gut an? Vergiss es, alles schöngeredete Theorie.

Kurzer Einschub...

Wunderst Du Dich, dass trotz immer schnellerer Glasfaser-Leitungen und immer schnellerer Computer unzählige Websites sooo laaange Ladezeiten beanspruchen, bis endlich alles angekommen ist? Fragst Du Dich, warum es tausendmal am Bildschirm ruckelt, bevor die Inhalte endlich fest an einer Position bleiben? Willst Du wissen, warum alle Websites scheinbar gleich aussehen, immer dieselben Nerv-Features haben, und eigentlich einfache Interaktionen so lange dauern? Spoiler Alert: die Website (bzw. App) wackelt auf einem Framework daher.

Abhilfe bei Inkompatibilitäten?

Früher waren Inkompatibilitäten zwischen den Browsern (also den Clients) tatsächlich ein Problem. Jeder Browser hatte seine Eigenheiten, wie er Websites darstellt, welche Programm-Features er kann, und wie er clientseitige Programme ausführt. Es war daher nicht leicht, eine Website / Webanwendung auf jeder Plattform flüssig zum Laufen zu bringen. Daher hat man versucht, von den Inkompatibilitäten weg zu abstrahieren. Geboren wurden die ersten Frameworks. Der Entwickler musste eine Routine nicht mehr in der "reinen" Programmiersprache schreiben, sondern so, wie es das Framework vorgab. Und das FW hat sich unter der Haube um die Funktionstüchtigkeit auf allen Plattformen gekümmert. Nun gut, aber irgendwer hat sich um die Inkompatibilitäten gekümmert. Also sollte ein Entwickler, der vom Kunden Geld verlangt, das auch selbst können.

Später haben sich die Browserhersteller zusammengesetzt, um die clientseitigen Webtechnologien plattformübergreifend zu standardisieren. Und siehe da: es wurden Standards und Regeln geschaffen, wie ein Browser implementiert sein muss, was er können muss, und wie eine einheitliche Javascript-Syntax aussieht. Ergebnis: Alle relevanten clientseitigen Webtechnologien (HTML, CSS, JavaScript) sind heutzutage zu fast 100% in allen Browsern und auf allen Plattformen standardkonform implementiert. Und alle Webtechnologien sind heute an offiziellen Stellen lückenlos und professionell wie in einer Universitätsbibliothek dokumentiert. Der Entwickler muss halt nur die Willenskraft aufbringen, sein Handwerk anständig zu lernen und die Dokumentationen auch zu lesen. Es gibt es keinen Grund mehr, einem Projekt tausende Zeilen Extracode anzuhängen. Denn der ist heute nicht nur überflüssig, sondern bremst ein modernes System sogar noch aus.

Die Sache mit der Komplexität

Der Shift zu einheitlichen Standards hat dem Internet völlig neue Nutzungsmöglichkeiten gegeben: übers Web läuft heute komplexe webbasierte Software, Cloud-Computing, Apps, Web-Plattformen uvm. Und natürlich sind auch die Programmiersprachen umfangreicher und komplexer als früher. Neue Web-Technologien kommen ständig hinzu. Sie entwickeln sich schnell weiter. Ein Fachmann braucht Jahre an Erfahrung, um einigermassen marktfähig zu sein. Man muss ständig lernen, am Ball bleiben und üben. Das gilt für clientseitige und serverseitige Technologien gleichermassen.

Und genau hier haben wir die nächste Entschuldigung, Kundenprojekte auf kostenlose Frameworks zu stützen. Frameworks sollen dem Entwickler, der keinen Bock hat, sich ernsthaft mit der Technologie auseinander zu setzen, schnelle Abhilfe bieten. Das Framework gibt vor, wie ein Projekt entwickelt sein muss, und stellt dafür vorgefertigte Bausteine zur Verfügung. Der Projektentwickler muss nun nicht mehr den Umweg gehen und lernen, wie man eine Funktionalität mit der 'rohen' Programmiersprache entwickelt. Er muss nur die Dokumentation des Frameworks lesen und schauen, wie der Baukasten zu verwenden ist. Na hoffentlich bietet das Framework die benötigte Funktionalität auch an. Falls nicht? Lies weiter, Du ahnst es nicht.

Code-Bloating

Frameworks sollen in möglichst vielen verschiedenen Projekten einsetzbar sein. One size must fit all. Die Schlagworte sind 'robust' und 'skalierbar'. Also kommen sie mit einer Unzahl an Klassen und Dateien, sie sind umfangreich und aufgebläht. Müssen sie auch, schliesslich sollen sie ja für alles passen. Jedes Framework hat zudem seine eigene Logik und eigene Vorgaben, wie eine Aufgabe zu lösen ist. Um trotzdem für möglichst viele Projekte geeignet zu sein, verfügt es über eine Menge an Routern, Zusätzen, Hierarchien und Verbindungsgliedern. Kurz: es ist komplex. Und der Code ist oft schwammig organisiert, da "skalierbar sein" bedeutet, dass immer wieder etwas angebaut wird, und man die letzten 100 Versionen ja auch noch unterstützen muss.

Ein einziges Framework fügt einem Projekt schon jede Menge Code hinzu und bremst die Geschwindigkeit spürbar. Ich habe Projekte gesehen, dessen Code-Last um 90% reduziert werden konnte, indem man die nötigen Programm-Funktionalitäten passend zum Projekt selbst programmiert hat. Dasselbe gilt für die Schnelligkeit: Frameworks benötigen Arbeitsspeicher, da sie selbigen mit tausenden unnötigen Objekten zustopfen, und Festplattenspeicher und Festplattenzugriffe, da der Framework-Code auf viele Dateien verteilt ist...

Code-Bloating next Level

Und jetzt aufgepasst: kein Framework kann alles, so gross es auch sein mag. Falls nun das Framework der Wahl die gewünschte Funktionalität nicht kann, sei sie noch so irrelevant, dann muss eben ein weiteres Framework übers Projekt geklotzt werden, kein Witz. Da werden dann Frameworks übereinander gestapelt auf Teufel komm raus, um aus jedem das Passende heraus zu holen. Ausserdem müssen Frameworks ja von Haus aus interoperabel sein, denn das eine Team kann nur Framework X und das andere Team kann nur Framework Y. Im Klartext heisst das: zusätzlich zum eigentlichen Framework-Code kommt nochmal eine Tonne Code für Schnittstellen zwischen den verschiedenen Frameworks. Also weitere Plugins, weitere Dateien, weitere Plattenzugriffe. Es ist irgendwie wie beim Tetris: man stapelt, bis der Bildschirm voller Steine ist, und hofft, dass es am Ende irgendwie läuft.

Frameworks reduzieren keine Komplexität, sie fügen welche hinzu. Und sie fügen schiere Masse hinzu. Von der Natur ihrer Sache kann das gar nicht anders sein. Ein Projekt, das in ein Framework gequetscht wurde (und oft ist es ja nicht nur ein Framework) kann niemals "schlank und schnell" sein. Aber jeder Entwickler wirbt damit, wie "effizient programmiert" seine Projekte sind. Finde den Fehler...

Zwangsjacke fürs Projekt

Ein Framework ist ein Kit-Set, welches mit der Logik des Projektes nichts zutun hat. Da das Framework feststeht, muss das Projekt so konzipiert werden, dass es mit dem Framework realisierbar ist, und nicht so, wie es für das Projekt am besten wäre. Da ein winziger Teil des Programmcodes, nämlich bis zu 90%, vom Drittanbieter stammt, herrscht eine starre Vorgabe, und der Verwender ist darauf beschränkt, was das Framework kann. Man kann es nicht ans Projekt anpassen. Der Projektersteller muss schon in der Planungsphase und beim Design der Software zusehen, dass seine Pläne dann mit dem Framework auch machbar sind. So sollte die Planung einer Software nicht aussehen müssen, niemals! Das Konzept sollte am Projekt orientiert sein, und nicht an den Hausmitteln, die zur Umsetzung herangezogen werden.

Zeiterscheinung, und keine Lösung

Jedes Jahr ist ein anderes Framework der Brüller. Sie kommen und gehen. Es sind Hunderte zu einem gegebenen Zeitpunkt, die um die Gunst besonders der Novizen buhlen. Es gibt dann im Web einen Hype und unzählige Tutorials, wie man mit dem neuen Alleskönner schnell sein Projekt realisiert. Natürlich muss man sich nicht wirklich mit dem Programmieren auskennen, das wurde einem ja abgenommen, so das Versprechen. Und dann flacht der Hype irgendwann ab, das Framework ist veraltet, oder schlimmer noch, ganz verwaist. Ich erinnere mich, als jQuery hochgehypt wurde. Dann kam Angular 1, und jQuery wurde für tot erklärt. Dann kam Angular 2, und alles mit Angular 1 ging den Bach runter. Dann kam React, und keiner wollte mehr 'in Angular machen'. Und das nächste tonnenschwere Zeug ist sicher schon in der Mache.

Hilfe!

Und die Fachforen im Web sind immer voll von dringenden Hilferufen: Wie kann ich mit dem Framework X das Problem Y lösen? Wie kann ich das Framework meinen Anforderungen anpassen? Wie kann ich meine Projekt-Anforderungen an das Framework anpassen? Freilich sind die Hilferufe immer dringend, denn der zahlende Endkunde wartet. Ich kenne eine Antwort, die immer passt: lerne selbst und verstehe. Lerne zu programmieren, dann bist Du für immer frei, und Deines Titels würdig. Deine Kunden werden es Dir danken, versprochen.

Keine Garantie, keine Haftung!

Ernsthaft: Scharen von bezahlten Entwicklern verlassen sich auf Code, der von wenigen unbezahlten Freiwilligen ohne Verbindlichkeiten kommt. Jeder kann ein Framework unter die Leute bringen. Es gibt keine Mindestanforderungen an Ausbildung und Erfahrung, keine Reglementierung, keine Qualitätssiegel - und keinerlei Haftung. Erfolg hat die Sau, die gerade durchs Dorf läuft. Eine Funktionsgarantie gibt der Ersteller des Frameworks explizit nicht. Falls das Framework Fehler enthält, Pech gehabt. Der Framework-Code wird zwar schon auch gepflegt, aber solange ein Bug nicht behoben ist, hat jeder, der das Framework nutzt, den Bug im eigenen Projekt. Man muss warten, bis der Code im Framework repariert wird, dann schlimmstenfalls etliche Updates am Projekt tätigen. Da der Framework-Code öffentlich ist, sind seine Schwächen schnell bekannt, und man kann ein Projekt absichtlich torpedieren, welches mit dem Framework arbeitet. Alles schon passiert. Der Endkunde verlangt zwar vom Entwickler, den Fehler zu beheben - aber der Entwickler kann ja nicht viel tun. Die Lösung liegt ausserhalb seines Wirkens, beim Drittanbieter. Und letzter schuldet ja offiziell nichts! Schlimmstenfalls wird ein Framework gleich ganz eingestellt.

Modulare Programmierung

Natürlich kann man als Entwickler eine saubere Bibliothek an eigenen, wiederverwendbaren Klassen bereithalten. Das sind Module, die eine wiederkehrende Teilaufgabe lösen - doch sie stammen aus der eigenen Feder jenes Entwicklers, der dem Endkunden die Leistung erbringt - und können ans Projekt angepasst werden, ohne Code-Overhead. Nach Studium der Programmiersprache und Erfahrung kann man eine eigene Code-Basis schaffen, die man versteht, die man schnell updaten kann und die man wirklich selbst beherrscht. Und jedes Projekt wird nur mit dem Notwendigen beladen, und trägt keinen schwer wartbaren, unnötigen Ballast.

Alle Programmiersprachen, client- und serverseitige, sind an offiziellen Stellen sehr gut dokumentiert. Das ist kein geheimes Wissen. Jeder, der lernen möchte, hat Zugang. Und einer, der sich Fachmann nennt, hat keine Entschuldigung, wenn er nicht die Technologie erlernt.

Der Anbieter eines Frameworks

Die ganz dilettantischen Eintagsfliegen mal ausser Acht gelassen: Ich sage nicht, dass der Ersteller eines Frameworks doof ist und nicht programmieren kann. Ich als Webentwicklerin selbst könnte ja auch jederzeit ein Framework erschaffen. Aber kein Dritter und kein Baukasten-System kann mir meine Projektarbeit abnehmen! Das gilt für alle Komponenten meines Projektes. Nur derjenige, der ein Projekt von Grund auf konzipiert und den Projektentwurf schafft, kann es mit dem besten, passendsten, und effizientesten Programmcode realisieren. Anders wird das nie ein Schuh nach Maß. Da kann ich noch so fit sein als Entwickler: ich kann mit einem behäbigen eins-für-alles Fertigsystem mit seinen starren Bauklötzen und Gesetzmässigkeiten ein Projekt nicht mal halboptimal herstellen, Punkt.

Framework nutzen heisst nicht, programmieren können

Viele 'Entwickler' schnauben beim Anblick der 'rohen' Programmiersprachen und denken: Warum soll ich das lernen, wenn ich doch Frameworks habe? Ich lüge nicht, wenn ich sage: Viele wissen nicht einmal, dass ein Framework nur ein Mantel um die zugrunde liegende Programmiersprache ist. Besonders sogenannte Quereinsteiger meinen, das Framework IST die Programmiersprache. Mit der eigentlichen Programmiersprache sind viele nicht ein einziges Mal in Berührung gekommen, kein Scherz. Die Hilflosigkeit dieser Leute ist enorm. Viele langjährige Framework-Verwender bekommen Riesenaugen, wenn sie sich zum ersten Mal ernsthaft mit der Technologie auseinander setzen. Sie betrachten Code in der Sprache, mit der sie Jahre lang gearbeitet haben - und verstehen 90% davon nicht. Sie fühlen sich, als würden sie bei Null anfangen. Und so ist es auch.

Ja, es dauert bis man als Webentwickler für den modernen Markt fit ist. Keiner sagt, dass moderne Webentwicklung ein Spaziergang im Park ist. Aber langfristig lohnt sich das tiefgreifende Verständnis. Eine Programmiersprache richtig zu lernen und eine Technologie zu verstehen ist wie ein Haus von Grund auf selbst bauen zu können. Man ist nicht auf Bausteine angewiesen, die auf lange Sicht ungenügend sind. Man kann jede gewünschte Funktionalität allein und effizient programmieren. Man kann jedes Projekt realisieren, ohne sich vorher nach einem 'geeigneten' Framework umsehen zu müssen. Ganz einfach: man kann nur gut programmieren wenn man selbst gut programmieren kann. Nur ein Mechaniker kann ein Auto bauen und instandhalten. Nicht der Fahrer - nur weil der auch weiss wo das Öl ist.