Ich war vor ein paar Wochen bei einer Firma zu Besuch, die für eines ihrer Produkte ein neues Webfrontend plant. Der JavaScript-Framework-Gretchenfrage stehe ich persönlich recht teilnahmslos gegenüber. Mein Eindruck ist, dass keins der populären Frameworks wesentlich schlimmer ist als die anderen populären Kandidaten. Entsprechend nutzlos ist es meistens, mich zu fragen, ob denn jetzt Angular, React, Aurelia oder Vue so sehr viel besser wäre. Aber im Fall dieser Firma hatte ich zu dieser Frage eine Meinung.
In besagter Firma gab es bei diesem Framework-Streit eine Fraktion, die für eine sogenannte „No-Framework“-Variante agitierte. Die Argumentation dieser Fraktion war, dass man sich sehr viel Lernaufwand und Stress sparen könnte, indem man einfach gar kein Framework verwendet, sondern sich ganz auf jQuery und native Features besinnt. Besonders dem wild vor sich hinmutierenden JS-Ökosystem stand man etwas skeptisch gegenüber und fürchtete sich vor bald schon nicht mehr gepflegten Frameworks und Dependencies. Dem Problem wollte man sich entziehen, indem man einfach kein Framework verwendet, dem die Weiterentwicklung versagt bleiben könnte.
Das Problem von „No-Framework“ ist, dass es diesen Ansatz für moderne Frontend-JS-Webapps gar nicht gibt und es etwas unaufrichtig ist, ihn als Null-Kosten-Alternative (Kosten im Sinne von Risiko, Einarbeitungszeit etc.) den populären JS-Frameworks gegenüberzustellen.
Was ist ein Framework? Ein Framework besteht aus Konventionen und Software, die bei der Arbeit im Rahmen dieser Konventionen assistiert. Verwendet man ein Framework, nimmt einem dieses im Idealfall die Arbeit an diesen zwei Punkten ab – Konventionen werden vorgegeben und passende Software wird bereitgestellt. Was passiert, wenn man kein Framework verwendet? Dann werden sich trotzdem Konventionen und Software herausbilden, die dann die Rolle des Frameworks übernehmen. Wer Programmcode schreibt, setzt naturgemäß Konventionen um und schafft Struktur und erzeugt über kurz oder lang sein eigenes Frameworks. Vielleicht ist dieses Framework ein dokumentiertes, getestetes Software-Modul, vielleicht ist aber nur ein Satz an über das Projekt verteilten, selbstgestrikten Funktionen mit Glue Code. Vielleicht sind die Konventionen in einem Styleguide festgehalten, vielleicht sind sie aber auch nur geheimes Templerwissen der wenigen Eingeweihten. Aber vorhanden sind Konventionen und Software in jedem Fall.
So gesehen kann man also nicht kein Framework verwenden. Man kann sich höchstens selbst eins schreiben. Macht man das gut, schreibt man ein explizites, getestetes, dokumentiertes Stück Software. Macht man es weniger gut, hat man sich am Ende trotzdem ein eigenes Framework geschaffen – nur eben ein implizites, das zwischen den eigentlichen Codezeilen lebt. Wer „No-Framework“ sagt, meint damit tatsächlich „ich schreibe mir selbst ein Framework“. Ich will auch gar nicht ausschließen, dass das unter entsprechenden Voraussetzungen eine gute Wahl sein kann. Nur wenn man die Nachteile der populären JS-Frameworks auflistet muss man diese gegen die Nachteile einer Eigenentwicklung (Zeitaufwand, Risiko usw.) aufwiegen und nicht einfach behaupten, man könnte auf Konventionen und Struktur verzichten oder die Entwicklung von Konventionen und Struktur wäre ein Selbstläufer.