Montag,
02. März 2009

Seit heute ist die 15. Ausgabe des T3N Magazins verfügbar und dieses Mal habe ich mal wieder einen Artikel beigesteuert. Auf dem Berliner Barcamp im Oktober letzten Jahres war ich mit den yeebase-Jungs ins Gespräch gekommen und habe Anfang Januar habe ich dann in die Tasten gehauen. Wenig verwunderlich dreht es sich um Layout-Frameworks.

  Seit langem schon ärgert es mich, dass in Berichten über CSS-Frameworks immer wieder die z.T. grundverschiedenen Ansätze der verschiedenen Projekte undifferenziert in einen Topf geworfen und miteinander verglichen werden. Deshalb fasse ich alle aktuell existierenden Projekte zunächst unter dem übergeordneten Begriff Layout-Frameworks zusammen. Ausgehend vom gewählten Layoutansatz es Frameworks folgt dann eine Unterscheidung in Grid- und CSS-Frameworks (eine Einstufung, die ich auch schon beim in Webkongress in Erlangen vorgestellt habe).

Grid-Frameworks
Sinn und Zweck eines Grid-Frameworks sind schnelle Ergebnisse in der Anwendung in den Grenzen des vorgegebenen Rasters.
CSS-Frameworks
Sinn und Zweck eines CSS-Frameworks ist die Bereitstellung einer möglichst leistungsfähigen Entwicklungsumgebung

Den roten Faden durch den Beitrag bildet die Betrachtung der Entwicklungszeit eines Layouts, wobei sich Layout-Frameworks in Abhänhigkeit des Layoutansatzes und der gewährten Freiheiten recht gut zwischen den beiden Extremen, dem Einsatz von Fertigtemplates (minimaler Aufwand, kein Einfluss auf Codequalität) oder der vollständigen Handkodierung des Layouts (volle Codekontrolle, maximaler zeitlicher Aufwand zur Layouterstellung) einordnen lassen. Unabhängig von persönlichen Vorlieben für den einen oder anderen technischen Weg lässt sich über die Zeitschiene sehr deutlich zeigen, wo die maßgeblichen Vorteile von Layout-Frameworks liegen - in der geringeren Entwicklungszeit.

Die gewonnene Zeit kann für Verbesserungen von Usability und Accessibility und/oder Performanceoptimierungen genutzt werden, denn diese Eigenschaften professioneller Webseiten sind in erster Linie contentabgängig. Das umschließende Layoutgerüst von Layout-Frameworks bietet zwar ebenfalls Potential, jedoch weit weniger als oft vermutet. Bei typischen Größen von 200 ... 300 kB komplexer Webseiten hat das Seitenlayout (HTML und CSS) im Durchschnitt einen Anteil von 5-10 Prozent (unabhängig von der Entstehung).

Im zweiten Teil des Artikel dreht sich dann auch alles um Performance. Frameworks bieten hier aufgrund ihres modularen Aufbaus des CSS naturgemäß Angriffsfläche für Kritik. Kommentare im CSS bedeuten verlängerte Ladezeiten, jeder einzelne CSS-Baustein muss vom Server angefordert werden (HTTP-Requests), was zwangsläufig mit Wartezeiten verbunden ist. Vergessen wird bei dieser Diskussion zumeist, dass auch bei der Handkodierung von Webseiten kaum ein Entwickler auf Zeilenumbrüche, Einrückungen und den einen oder anderen erläuternden Kommentar verzichten kann. Worauf ich hinaus will: Ob Framework-Einsatz oder Handkodierung - die Komprimierung von CSS-Dateien und die Reduzierung von HTTP-Requests sind generelle Optimierungszenarien, um die Performance einer Webseite zu steigern. Wer Performance-Optimierung ernsthaft betreibt, der kommt um eine komprimierte Live-Version des Entwickler-CSS nicht herum.

 


Du kannst die Kommentare zu diesen Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.

Dieser Eintrag kann nicht mehr kommentiert werden.