25. September 2007
Die Diskussion bezüglich CSS-Frameworks bleibt nicht stehen. Wenn Sie das Thema interessiert, finden Sie in dem Essay “Was Sie über CSS-Frameworks wissen sollten!” eine ausführliche thematische Fortsetzung der Diskussion
In den letzten Wochen sind im englischen Sprachraum zwei interessante Artikel erschienen, die im Bezug auf die Argumentation pro/conta CSS Frameworks polarisieren. Da wäre “Why I don’t use CSS Frameworks” (Kyle Neath) und “Please do not use CSS framworks” (Jonathan Christopher). Das Smashing Magazine hat diese Diskussion im Rahmen eines Überblicks aktuellen CSS-Frameworks aufgegriffen und prägnant zusammengefasst.
Danach gelten als Vorteile ...
- Steigerung der Produktivität
- Vermeiden von alltäglichen Fehlern
- Einheitliche Code-Basis
- Verbesserter Workflow bei Team-Arbeit
Dem gegenüber stehen einige Nachteile ...
- Erlernen der Arbeitsweise des Frameworks kostet Zeit
- Verstehen der Code-Architektur kostet Zeit
- Fehler in der Codebasis werden unerkannt mitgeschleift
- Man vertaut dem Framework, nicht seinen eigenen CSS-Kenntnissen
- Frameworks erzeugen Overhead im Code
- CSS Frameworks und semantische Codeauszeichnung stehen im Gegensatz zueinander
- Man ignoriert die Einzigartigkeit eines Webprojekts
Nun bin ich als Framework-Entwickler natürlich kein Außenstehender, ungeachtet dessen habe ich natürlich zu diesem Thema eine Meinung. Den Vorteilen stimme ich zu (War ja klar, oder?). Zu den genannten Nachteilen möchte ich jedoch etwas anmerken. Nicht, um sie weg zu diskutieren, sondern weil denke, dass die Ursachen dafür woanders zu suchen sind.
Das Kennenlernen ist schwierig
Jeder Mensch hat seine persönliche Handschrift. Ähnliches gilt für die Erstellung HTML-, CSS-Code sowie die Art und Weise, in der der eigene Code dokumentiert und gepflegt wird. Der Einsatz eines CSS-Frameworks erfordert das Arbeiten mit fremdem Code und vorgegebenen Strukturen. Das Verstehen und der Umgang mit einer fremden Codebasis kosten den Nutzer verständlicherweise Zeit. Innerhalb einer Webagentur, sollte dieser Prozess allerdings zum Alltag gehören, denn Zusammenarbeit mehrerer Abteilungen/Firmen und damit auch mehrerer Webdesigner ist ja nichts neues. Der mögliche Vorteil eines Frameworks: Die Einarbeitung in dessen Arbeitsweise ist ein einmaliger Aufwand - anschließend kommt der Vorteil einer einheitlichen Codebasis und einer einheitlichen Sprache bei der Umsetzung von Projekten zum tragen. Speziell bei Teamarbeit oder dem Agentur/Kunden-Verhältnis (Support) kann Arbeit und Pflege damit einfacher/leichter werden.
Es ergeben sich damit keine ungewollten Zwänge. Ansätze mit einer willkürlichen Struktur werden auf Dauer kaum Bestand haben. Logische und praxisorientierte Strukturen in die eigene Arbeit zu übernehmen, fällt hingegen leicht. Den meisten Webseiten liegen solche abstahierbaren Stukturen zu Grunde. Je universeller und logischer diese durch das Framework abgebildet werden, desto einfacher lässt sich damit arbeiten.
Der oft geäußerte Aussage “Das bekommt man (i.d.R gemeint: der Autor selbst) selbst schneller und mit weniger Code hin!” kann ich als Framework-Entwickler pauschal nichts entgegnen. Allerdings es eine rein subjektive Einschätzung der eigenen Fähigkeiten und Ansprüche an den erzeugten Code, sodass es als objektives Kriterium pro oder contra Frameworks in meinen Augen nicht taugt, denn sie basieren nicht auf einem konkreten Anwendungsfall. Frameworks wie YUI Grids, Blueprint oder YAML setzen jeweils unterschiedliche Schwerpunkte. YUI Grids ist klar auf fixe Layouts und die Zusammenarbeit mit der Javascript-Bibliothek von Yahoo ausgelegt. Blueprint verfolgt ein streng visuelles Konzept und kombiniert ein pixelbasiertes Grid-Baukastensystem mit typographischen Gestaltungsvorgaben. YAML hingegen setzt auf flexible Layouts und Gestaltungfreiheit für den Entwickler. Sie haben demzufolge auch ihre individuelle Stärken und Schwächen.
Die Bedenken, Fehler in der Codebasis unerkannt mitzuschleifen, sind nachvollziehbar. Die Chance auf bugfreien Code stehen jedoch für den Anwender sehr gut, denn Fehler in der Codebasis werden von der Community meist schnell entdeckt und gemeldet. Ich sehe hierin daher keinen Kritikpunkt für Frameworks sondern eine Aufforderung zur besseren Dokumentation. Wie jede Software müssen sich auch CSS-Frameworks ihre Reputation in der Community zunächst verdienen. Und das kann nur über fehlerfreien Code und eine entsprechende Dokumentation erfolgen. Es ist ein Unterschied, ob ich eine Blackbox bediene und dem Ergebnis blindlings vertraue oder ob ich alltäglich wiederkehrende Arbeitsschritte automatisiere und doch genau weiß, was dabei passiert. Wer keine Browsertest mit fremdem Code macht, macht vermutlich auch keine mit dem eigenen Code.
Zum Thema Overhead habe ich mich bereits in der Vergangenheit geäußert und meine Meinung hat sich nicht geändert. Bezüglich YAML kann ich sagen, dass der durch die Framework-Nutzung generierte Overhead (HTML+CSS) verhältnismäßig gering ist und anspruchsvolleren CSS-Layouts in Verbindung mit CMS-Einsatz praktisch nicht Gewicht fällt. Wenn Ladezeiten und Traffic wirklich systemkritisch sind, bestehen sowohl bei CSS-Frameworks als auch bei indivuellem Code ähnliche Optimierungspotentiale, denn auch die Erstellung von Hand führt nicht im automatisch zur optimalen Lösung. Und damit möchte ich diesen Teil abschließen, denn die letzten beiden Punkte kann ich ehrlich gesagt wirklich nicht nachvollziehen.
Es geht noch besser
Sind Frameworks der Heilige Gral der Webentwicklung? Vielleicht werden sie es eines Tages, wer weiß? Derzeit sind sie es jedoch sicherlich noch nicht. Dazu ist zu ergänzen, dass auch noch niemand so richtig weiß wie dieser Gral aussehen könnte. Ungeachtet dessen stellen sie schon heute eine enorme Arbeitserleichterung für Webentwickler dar.
Was ich persönlich als Nachteil vieler aktueller Frameworks empfinde - und was die angesprochenen Kritikpunkte durchaus verständlich macht - ist die mangelhafte Dokumentation vieler aktueller Frameworks. So hat man oftmals den Eindruck, eine Blackbox zu bedienen. Diese Tatsache ist für den produktiven Einsatz nicht vertrauensfördernd und führt zu den geäußerten Bedenken. Hier sind die Framework-Entwickler gefragt, Ihre Lösungen vollständig und für Anwender verständlich zu dokumentieren.
Gerade bei den heutigen Anforderungen in Sachen Usability, Zugänglichkeit und den Anforderungen an modernes Webdesign sollten der inhaltliche Schwerpunkt professioneller Arbeit nicht mehr im mühsamen Erstellen von validem Markup und dem Fixen von Bugs liegen. CSS Frameworks greifen dem Webdesigner in genau diesem Punkt unter die Schultern, damit der Blick wieder frei wird für das Wesentliche der Arbeit.
Donnerstag, 27.09.07 (01:30 Uhr)
Hallo Dirk ! Grüsse aus dem Ostwestfälischen nach Sachsen !
Dieser Dein Blog-Thread trifft auch genau meinen derzeitigen Nerv ...
Denn im Zuge des (erneuten) Schlaumachens in Sachen CSS - kann sich zu einem Fass ohne Boden auswachsen - bin ich erstmals auch über CSS-Frameworks gestolpert:
- YAML, Blueprint, YUI Grids, Elements, Tripoli
Da hat man also mal wieder die Qual der Wahl - oder auch Nichtwahl ...
Und dann gibt’s da ja auch noch die Layout-Werkzeuge:
- WestCiv’s StyleMaster
- Dreamweaver Extensions:
- CSS Layout Magic von Project VII
- Brandneu: Eric Meyer’s CSS SCULPTOR 1.0.1; erschaffen in Zusammenarbeit mit WebAssist
Gibt es schon irgendwo einen Vergleich der Werkzeuge mit den Frameworks ?
Als Nicht-CSS-Insider steht man bei der Auswahl gleichsam auf verlorenem Posten ...
Was mich an YAML reizt:
- Es ist auf die Erstellung FLEXIBLER Layouts ausgelegt. Frage: Kann man damit wirklich BELIEBIGE flexible Layouts erstellen ? Also auch sogenannte Non-Slicing-Layouts (Layouts, die sich nicht komplett durch Spalten und Zeilen beschreiben lassen) ?
- Es bietet den umfangreichen Online-Builder.
- Erschaffen von einem “Landsmann” :-)
Und hast Du schonmal die teilweise Symbiose mit anderen Frameworks untersucht ?
Freue mich schon auf weitere Reaktionen bezüglich dieses heissen Diskussionsthemas.
Tschüss
Kai
Freitag, 28.09.07 (09:42 Uhr)
Hallo,
ich kann einige oben genannte Kritikpunkte gut nachvollziehen, jedoch denke ich, dass, vor allem wenn man häufiger Projekte mit einem Framework erstellt, die Vorteile überwiegen.
Da fällt auch die Einarbeitungszeit weniger ins Gewicht. Möchte man nur mal schnell ein Projekt realisieren ist der Aufwand meiner Meinung zu groß, es sei denn man setzt eine mitgelieferte Vorlage 1zu1 um.
Die Gefahr, dass Fehler im Quellcode unerkannt bleiben ist meiner Meinung größer wenn man den gesamten Quellcode selbst schreibt, da wie Du schon erwähnt hast, bei Frameworks meist eine größere Community besteht.
Ich habe von den oben genannten Frameworks bis jetzt nur YAML kennengelernt und bin damit auch recht zufrieden. Die Dokumentation ist auch sehr gut.
Was mich persönlich stört sind eher so die Kleinigkeiten. So hat jeder Programmierer so seinen eigenen individuellen Stil. Dies betrifft z.B. das Einrücken, die Kommentare und der generelle Aufbau der Css Dateien.
Speziell bei YAML sind dies z.B. die Fehlenden Strichpunkte bei Klassen/ids mit nur einer Anweisung oder auch die Leerschritte nach bzw. vor den Klammern. Obwohl dies von der Syntax her korrekt ist und so auch funktioniert, stört es mich schon sehr und ich ertappe mich immer wieder dabei, wie ich Strichpunkte nachträglich einfüge.
Aber wie gesagt, das ist dann wohl eher ein persönliches Problem (vielleicht Anzeichen einer Zwangsneurose? :-) )
Liebe Grüße
Georg
Mittwoch, 20.08.08 (18:11 Uhr)
Hallo,
für mich ist der wichtigste Grund ein Framework wie YAML einzusetzen, dass ich einfach keine Lust mehr habe, Fixes für die unendlichen Bugs des IE zu bauen. Ich bin Dirk sehr dankbar für diese Schinderei! So um IE Version 3. herum hat mich das schon so geärgert, dass ich mich für einige Zeit nicht mehr für Webentwicklung interessiert habe. Erst neuere Ansätze haben mich 2007 wieder zurück finden lassen.
Zurück zur ursprünglichen Frage. Nach 25 Jahren Beobachtung bin ich davon überzeugt, dass der Einsatz von Frameworks in der Entwicklung von komplexeren Softwarelösungen immer mehr in der Vordergrund treten wird. Je nach Umfang eines Projektes ist eine Realisierung heute oft nur noch durch Einsatz von Baukästen etc. wirtschaftlich möglich. Alles eigentlich nur das Ergebnis moderner Softwaretechnologie und logische Fortsetzung der Modularisierung. Man betrachte einfach die Inhalte des Informatikstudiums von heute und von etwa 1985, um zu sehen, welche Bedeutung Frameworks heute gewonnen haben.
Letztlich möchte ich noch etwas zum Aspekt “persönlicher Stil” hinzufügen. Natürlich geht der Stil der Programmierer von “Huddel und Brassel” bis zum echten Code-Kunstwerk. Für mich ist ordentlich strukturierter Code manchmal einfach schön, egal ob er von mir oder einem anderen Tastenknecht stammt. Leider hat aber auch jeder von uns schlechte Angewohnheiten und Fehlerquellen. Arbeiten mit dem Code Dritter lehrt aber oft erst die kritische Auseinandersetzung mit dem Produkt Software. Durch den Einsatz von Frameworks lernt man weiter und verbessert den eigenen Stil.
Ohne einige existierende Frameworks und APIs wären viele Webdienste gar nicht möglich.
Ich möchte zB. nicht mehr auf YAML verzichten.
Gruß
mak
Montag, 24.11.08 (00:54 Uhr)
Danke für die ausführliche Meinung! Ich habe selbst sehr viele Projekte im Webdesign mit eigen gestricktem CSS umgesetzt. Und nur bei einem YAML versucht einzusetzen. Leider wirklich nur versucht, denn die Realität sieht im beruflichen Alltag leider so aus, dass man kaum Zeit für das Erlernen so eines Frameworks überhaupt hat. Ich fand die Ordnerstruktur und die Dateibenennung tatsächlich als Hindernis. Auf jeden kann man so ein Framework nicht auf die Schnelle mal einsetzen. Das war meine Erfahrung. Doch über Umwege kam ich auf dan ZEND Framework von PHP und musste erkennen, dass je komplizierter eine Computersprache wird (ok, CSS ist keine Computersprache, aber die Anzahl der Formatierungen wird in der Zukunft eher zunehmen, als abnehmen), umso wichtiger wird es so ein Framework einzusetzen. Und die Gründe Teamarbeit, keine Abhängigkeit an den Urentwickler sind sehr starke Argumente dafür.