Missverständnis Framework

Vor kurzem veröffentlichte das britische .net magazine ein Interview mit ein paar anglo-amerikanischen Web-Celebrities. Es ging um ihren Ansatz für responsive Webdesign. Eine der Fragen war, ob sie ein Framework nutzen würden. Eine unbeholfene Zustimmung war zu verzeichnen, aber meist war Ablehnung die Antwort.

Typisch ist die Antwort von Brad Frost. Er wolle sich nicht die Vorgehensweise eines anderen zu Eigen machen. Und er wäre evtl. nicht in der Lage, mit einem Framework das Gewünschte zu erreichen.

So in der Art höre und lese ich immer wieder Statements zu CSS-Frameworks. Akzeptiert werden sie hingegen im Bereich JavaScript, App-Erstellung oder bei serverseitigen Skriptsprachen. Da beschwert sich auf einmal niemand, dass man sich auf eine fremde Notation einlassen müsse. Warum ist die “not invented here”-Manie in Sachen HTML und CSS so verbreitet?

Ich bin ein überzeugter Framework-Nutzer. Ich nutze seit dem Beginn meiner Selbständigkeit YAML. Bei meinem letzten Arbeitgeber hatte ich mir eine Art Framework für die überschaubaren Grid-Konstrukte selber geschrieben. Das kann recht schnell gehen. Doch mittlerweile geniesse ich, dass ich einfach nur Regeln anwenden muss und schon funktioniert alles. Und es ist auch noch bis hinunter zum IE6 getestet.

Und trotzdem möchten die meisten meiner Bekannten lieber immer wieder alles selber schreiben. Ich hoffe, sie haben auf die eine oder andere Art ein eigenes Framework. Denn wenn sie bei jedem Projekt aufs Neue ein Grid konstruieren oder über die Fallstricke eines dreispaltigen Layouts sinnieren, dann verschwenden sie unnötig ihre Zeit und Geld ihres Kunden.

Gerne wird davon gesprochen, Frameworks sein so aufgeblasen, man würde so viel unnötiges Zeug mitnehmen. Für einzelne Frameworks mag das gelten. Speziell für die UI-Frameworks wie Bootstrap wird das gelten. Aber mittlerweile besitzen wir praktische Techniken, um eine sinnvolle Selektion aus einem grossen Ganzen zu erstellen. YAML bietet sie all denjenigen, die Sass nutzen.

Frameworks sind Werkzeugkästen, keine fertigen Bausätze. Sie ermöglichen uns eine einfache und effektive Arbeit. Sie sollten aber immer auf Herz und Nieren geprüft werden. Ich bin beispielsweise gespannt zu erfahren, auf welche Weise jemand ein dreispaltiges Layout oder ein individuell erweiterbares Gridkonstrukt effektiver und schmaler hinbekommen kann, als dies bei YAML der Fall ist. Ich fürchte, dass dies nicht geht.

So bleibt als einziger Kritikpunkt, dass man sich die Klassenbenamung eines anderen zu eigen machen muss. Als Kritik finde ich das nicht besonders erwachsen. Die Kritiker vergessen dabei, dass Frameworks eine Dokumentation besitzen, wie gross oder schmal sie auch sein mag. Gibt man seine Arbeit weiter oder holt neue Leute ins Team, hilft diese Dokumentation ungemein.

Niemand benötigt für Webentwicklung ein Framework. Trotzdem sind diese Codesammlungen ein Beitrag für effektives Arbeiten. Sie ermöglichen es uns, früher mit unserer eigentlichen Arbeit, der Lösung individueller Designideen, zu beginnen. Es ist wie mit einem CMS: natürlich kann man sich für jedes Projekt ein eigenes schreiben, manchmal erscheint dies auch angebracht. Effektiv ist dies aber nicht.

10 Kommentare

  1. Das die „Web-Celebrities“ nicht fremde Frameworks nutzen finden ich verständlich. Von ihnen erwartet man eher, dass sie selbst welche schreiben. Für alle anderen ist das aber kein Argument. Ganz heilsam kann die Lektüre dieses Artikels sein, in dem ein Programmierer beschreibt, wieso in jeder Firma in der er gearbeitet hat, jemand sein eigens Framework schreiben wollte (und damit gescheitert ist): http://mooneyblog.mmdbsolutions.com/index.php/2010/12/07/the-framework-myth
    Mein Lieblingszitat: „…you […] are not going to build the next great framework. You’re not going to build a good one. You’re not even going to build an acceptable one.“

    • Also ich erwarte von den Web-Celebrities nicht, dass sie selber welche schreiben. Das ist nicht jedermanns Sache. Ich bin aber enttäuscht, dass einer planlos mehrere nutzt und alle anderen glauben, auf eigenen Füssen besser voranzukommen.

  2. Nichts läge mir ferner als Bootstrap zu verteidigen, aber der Fairness halber sollte man erwähnen, dass es durchaus auch eine Sass-Version von Bootstrap gibt, für die Ähnliches gelten dürfte wie für die Sass-Version von YAML.

    Ich kenne und nutze beide nicht selbst, weil ich auch zu der Gruppe gehöre, die nicht gerne mit HTML/CSS-Frameworks arbeitet. Beziehungsweise: Tue ich schon, aber mit einem „eigenen“, was den Namen Framework nicht verdient. Das ist mehr ein Boilerplate, was ich als Projektbasis (für jedes meiner Projekte) verwende. Das enthält natürlich ein paar SCSS-Annehmlichkeiten, die ich immer wieder verwende, auch ein paar jQuery-Plugins usw.

    Der Unterschied zu einem Framework ist sehr simpel: Mein Boilerplate enthält nur das, was ich ständig brauche. Die meisten HTML/CSS-Frameworks (ja, auch YAML) enthalten viel mehr, als ich in einem durchschnittlichen Projekt benötige. Klar, ich muss das alles nicht verwenden, und wenn es über Sass-Mixins bereit gestellt wird, habe ich noch nicht einmal die Arbeit, zu entfernen, was ich nicht brauche.

    Aber: Ich habe dann das Gefühl, mit (Fremd-)Code zu hantieren, den ich nicht vollständig verstehe. Und der Aufwand, eines der gängigen HTML/CSS-Frameworks so zu verinnerlichen, dass ich es vollkommen verstehe, ist einfach so hoch, dass ich es (für mich, das muss niemand so handhaben) einfacher fand, mir meine eigene Projektvorlage zusammen zu stellen.

  3. Eine interessante Überlegung. Ich habe sie nie laut gestellt, denn aus meinem Mund besteht immer die Gefahr als „Prediger der Framework-Lehre“ missverstanden zu werden.

    Die Frage, die ich mir stelle? Woher kommt die Angst, Fremdcode nicht voll zu durchdringen? CSS ist leicht zu debuggen, die browserspezifischen Macken überschaubar und Framework-Code in der Regel dokumentiert. Die überwiegende Zahl an CSS-Frameworks da draußen hat zudem einen Funktionsumfang, der sich in 30min überblicken lässt. Daneben gibt es ein, zwei Hände voll an Projekten, bei denen es nicht so ist – dafür sind diese gut dokumentiert.

    Ich verstehe, dass es Mühe macht, browserspezifische Details in fremdem Code bis ins Kleinste zu durchschauen. Doch gerade hier liegen die Stärken der CSS-Frameworks als Werkzeugkästen, die von zahllosen Anwendern in verschiedensten Situationen getestet wurden. Gerade bei Grids, Formularen, Navigationsbausteinen gibt es keinen Grund, das Rad jedes Mal neu zu erfinden. Ich hier viel häufiger Probleme, die sich aus unstetigen Eigenentwicklungen ergeben – die Qualität leidet. Es liegt mir fern, das zu verallgemeinern. Dennoch bleibt festzustellen, dass zahlreiche Accessibilityprobleme erst durch „Vergesslichkeiten“ oder Nichtwissen entstehen.

    Wer denkt in Zeiten von CSS3 denn darüber nach, ob eine perfekt animierte CSS-only Tab-Lösung oder die neueste OffCanvas-Lösung für mehrstufige Dropdown-Menüs tastaturbedienbar ist? Werden diese Probleme vor dem Einsatz korrigiert? Ist dieser CSS-Code nicht gleichermaßen kryptisch wie der eines CSS-Framework?

    Die volle Kontrolle zu haben, bringt in der heutigen Zeit auch eine enorme Verantwortung mit sich. Denn volle Kontrolle bedeutet auch, die volle Verantwortung hinsichtlich der Qualität des Endproduktes zu haben. Wer sich diesem Qualitätsanspruch stellt, für den ist es letztlich zweitrangig, in welchem Umfang ein Framework diesem Ziel dienlich ist. Stellt man sich diesem Anspruch jedoch nicht und stempelt CSS Frameworks dennoch als „bloated“ ab, läuft man Gefahr, sich selbst zu belügen. Mit den daraus erwachsenen Konsequenzen müssen in der Regel in erster Linie die Kunden. Dieser Gedanke kommt in dieser Diskussion für meinen Geschmack zu wenig vor.

  4. Ich denke, das liegt zumindest teilweise* an Selbstüberschätzung („ICH brauche kein Framework“) und mangelndem Verständnis der eigenen Grenzen:
    1. Anfänger verstehen weder die Frameworks noch können sie einschätzen, was diese ihnen ersparen.
    2. Fortgeschrittene denken, sie könnten das schon selbst alles besser.
    3. Profis nutzen Frameworks, wo angebracht.
    4. Top-Experten denken, es verträgt sich nicht mit ihrem Status, die Arbeit anderer zu nutzen.

    Im übrigen, Jens, kenne ich die Ablehnung auch für Javascript-Frameworks – nämlich von JS-Developern – oder für CMS – von „erfahrenen“ Programmierern. Ich habe gerade einen Kunden, da hat die IT-Abteilung einer großen Organisation beschlossen, das vorhandenen Mainstream-CMS durch eine komplette Eigenentwicklung zu ersetzen, weil die neueste Version keine ISO-Kodierung mehr akzeptiert…

    *Selbstverständlich will ich damit nicht sagen, alle Framework-Ablehner leiden an Selbstüberschätzung oder kennen ihre eigene Grenzen nicht.

  5. Es geht auch darum, dass sich gerade HTML/CSS Coder etwas genieren, wenn sie auf etwas „Fremdes“ zurückgreifen müssen/sollen/dürfen. Ihre ureigenste Aufgabe ist ja eigentlich auch, diesen Code herauszuhauen. Dafür werden sie bezahlt. Und nicht wenige Kunden mit etwas Kenntnis von der Materie blubbern schnell mal herum: ach, sie machen das auch nur mit YAML? Na DAS hätte ich noch selbst hinbekommen! (inwieweit diese Selbstüberschätzung gerechtfertigt ist, steht auf einem anderen Blatt)

  6. Frameworks finde ich prinzipiell super. Meine einzige Sorge ist, dass sie die Lebenszeit meiner Projekte nicht überdauern…

  7. Ich kann mich noch an meine Zeit vor CSS-Frameworks erinnern und auch an meinen Antrieb mich mit Frameworks auseinander zu setzen. In erster Linie ging es mir vielmehr darum mir etwaige Problemlösungen und Workarounds – damals war der IE6 noch eine Voraussetzung – anzuschauen und daraus zu lernen.

    Auch wenn ich am Anfang nicht direkt Projekte auf CSS-Frameworks aufgesetzt habe, so habe ich deren CSS oft als Spickzettel missbraucht. Bei mir waren das hauptsächlich YAML und das 960gs. Das Grundproblem, warum ich nicht direkt ein vollständiges Framework verwendet habe, war zunächst die Tätigkeit in der Agentur gepaart mit der unterschwelligen Angst: Was machen, wenn ich bei 80% an einen Punkt komme, der mich vor kaum lösbare Aufgaben stellt und die Deadline dennoch näher rückt?

    Im Agenturalltag kann man sich schlecht die Zeit nehmen und sich in ein CSS-Framework vollends einarbeiten, bis man sich so sicher ist es auch in einem Projekt zu verwenden. Das Risiko etwas zu verwenden, was man noch nicht wirklich beherrscht, ist aber dann auch zu hoch. Ein Teufelskreis!

    Abgesehen davon wird wohl jeder Webentwickler auch auf eigene Schnipsel zurück greifen, so wie es Matthias oben schreibt. Auch ohne Framework fängt man nicht immer bei Null an.

    Was ich an CSS-Frameworks sehr schätze ist die einfache Art und Weise einer Übergabe an andere Entwickler, weil der individuelle Code nicht ganz so umfangreich ist und man direkt auf eine fertige Doku verweisen kann.

    Mir hat die Arbeit mit Frameworks allerdings bisher nur Vorteile gebracht:
    1. Lernhilfe und Quelle für Workarounds
    2. verschiedene Lösungsansätze vergleichen
    3. auch in Fremdprojekten kann man aushelfen bzw. diese übernehmen

  8. Ich möchte kurz Bootstrap verteidigen, es befindet sich vom Code in der gleichen Kategorie wie YAML, hat SASS oder LESS-Portierungen und ist modular aufbaubar. Es gibt mittlerweile viele weitere gute Frameworks z. B. auch Zurb http://foundation.zurb.com/ oder pure http://purecss.io/.

    Ich nutze CSS Frameworks, weil die Anzeigefehlerquote auf den unterschiedlichen Browser- und System-Plattformen deutlich niedriger ist. Außerdem ist die Entwicklungszeit deutlich kürzer. Das Mehr an Code kann ich gut verschmerzen.

    • Nein, Bertram, Bootstrap ist nicht in der gleichen Kategorie wie YAML. Kann sein, dass man mittels Sass das unglaublich grosse CSS zurechtstutzen kann. Ohne Sass bekommt man nur eineinziges grosses CSS-File. Es gibt keine Trennung zwischen Layout (Pflicht) und Design (Kür). Deshalb ist es für mich auch nur ein UI-Framework.

      Die unglaubliche Vielfalt an fertigen Modulen ist ein grosses Argument für Bootstrap. Nutzt man nicht Sass – und die wenigsten nutzen es leider – bekommt man allerdings dafür ein viel zu grosses CSS und muss alle Styles mehrfach überschreiben. So richtig klug ist das nicht, wenn man mehr möchte, als mal eben schnell einen Klickdummy zusammenzuschustern.

      Und alle Frameworks unterscheidet eine Sache von YAML: sie kennen nur Grids, keine Spalten. Und keines hat ein so ausgefeiltes Formularframework. Sie haben nur alle den Vorteil, von Anfang an auf Englisch erschienen zu sein und gutes Marketing zu haben.