Matti Mäkitalo: Frameworks - hot or not?

Beitrag lesen

Hi,

ganz allgemein: Wenn ich ein Framework, eine Klassenbibliothek oder irgendwas in der Art sinnvoll und effizient einsetzen möchte, muss ich mich in dieses System einarbeiten. Ich muss mich schlau machen, wie man es in eigene Projekte einbindet, welche Möglichkeiten es bietet und wie ich sie nutze. Und diese Einarbeitung kostet Zeit.

Deshalb verzichte ich liebend gern auf solche Frameworks, wenn die geschätzte Einarbeitung deutlich länger ist als die Zeit, die ich brauche, um den für das aktuelle Projekt nötigen Funktionsumfang selbst zu implementieren. Meine Software- und Webprojekte sind meist so klein, dass "zu Fuß" da zeitlich besser abschneidet.

Aber das macht man i.d.R. nur einmal (mehrmals, wenn man ein schlechtes Gedächtnis hat). Die längere Lernphase hat man bei vielen Frameworks doch bei einem zweiten/dritten Projekt recht schnell ausgeglichen und in der Folge hat man nur noch Zeit-Vorteile.

Umso mehr, weil viele Frameworks darauf ausgelegt sind, Code wiederverwendbar zu machen. (Als Beispiel nenne ich mal Symfony mit den vielen Bundles oder AngularJS, wo Code auch sehr modular gestaltet ist). Dies erlaubt es, Code, den man für ein Projekt schreibt, u.U. wiederzuverwenden (und das ohne C&P). Als Beispiel nenne ich mal eine angular-Direktive, die Drag&Drop-File-Upload erlaubt. Einmal ordentlich geschrieben (wobei angular mir das sehr einfach macht) und schwupps kann ich die Funktionalität überall einbauen.

Was in dem Zusammenhang auch noch erwähnt werden sollte, aber nicht deckungsgleich mit der Frage "Framework ja oder nein" ist: eine gute Toolchain hilft ebenfalls. Ich bin gerade dabei, bower in meinen Arbeitsfluss aufzunehmen, als nächstes steht dann grunt.js an (und in ferner Zukunft dann yeoman, wo noch Project-Scaffolding hinzukommt). Mit bower erhoffe ich mir, meine Abhängigkeiten zu (anderen) Bibliotheken (und das können ja auch eigene sein) gut verwalten zu können.

Bis die Tage,
Matti