T3N Magazin 15: Layout-Frameworks für Webentwickler http://www.highresolution.info/weblog/entry/t3n_magazin_15_layout-frameworks_fuer_webentwickler/   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-FrameworksSinn und Zweck eines Grid-Frameworks sind schnelle Ergebnisse in der Anwendung in den Grenzen des vorgegebenen Rasters.CSS-FrameworksSinn 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.   de-de Dirk Jesse Copyright 2009 2009-03-02T;09:47:59+00:00 Kommentar von Project-MAC http://www.highresolution.info/weblog/entry/t3n_magazin_15_layout-frameworks_fuer_webentwickler/ Frameworks hat sich irgendwie in die falsche Richtung entwickelt. Ich zumindest habe meine Probleme damit! LG Frameworks hat sich irgendwie in die falsche Richtung entwickelt. Ich zumindest habe meine Probleme damit! LG

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Denny Schäfer http://www.highresolution.info/weblog/entry/t3n_magazin_15_layout-frameworks_fuer_webentwickler/ Sehr guter Beitrag. Dieser hat mich dazu angeregt, endlich einmal ein CSS Framework auf eines der nächsten Projekte anzuwenden. Sehr guter Beitrag.

Dieser hat mich dazu angeregt, endlich einmal ein CSS Framework auf eines der nächsten Projekte anzuwenden.

]]> 2012-01-18T;11:39:34+00:00