Bootstrap – Segen oder Fluch?

Nachdem lange Zeit CSS-Frameworks wie Pilze aus dem Boden schossen, scheint nun ein »Sieger« gefunden: Bootstrap. Für die einen ist es ein unverzichtbares Werkzeug, den anderen ist es ein Dorn im Auge. Welche Auswirkungen aber hat die Verbreitung von Bootstrap auf die Frontend-Entwicklung?

Bootstrap ist etwas bemerkenswertes gelungen: Es ist zu einem Industriestandard geworden. In einer Welt aus Projekt- und Stellenausschreibungen, in denen so etwas sonst nur komplexen PHP- oder JavaScript-Frameworks gelingt, finden sich heute Anforderungsprofile, in denen ausdrücklich Erfahrungen mit Bootstrap vorausgesetzt werden. Das ist so – vor allem in der Breite – noch keinem CSS-Framework gelungen. Es gibt einen eigenen Markt für Bootstrap-Themes und mittlerweile bieten auch erste grafische Werkzeugezum Prototyping an, Projekte auf Basis von Bootstrap zu starten.

Der Erfolg des ursprünglich nur für interne Verwendung bei Twitter gedachten Projektes ist schnell erklärt – neben einem responsiven Grid-System bietet Bootstrap eine nahezu komplette Bibliothek an User-Interface-Komponenten, einschließlich des dazu z.T. notwendigen JavaScripts; und zwar in einem handlichen, ausführlich dokumentierten und selbst für Teilzeit-Frontendler und Hobby-Webdesigner leicht nutzbaren Paket. In Zeiten, in denen Effizienz und Zeitersparnis ganz oben auf der Wunschliste einer immer noch jungen, sich professionalisierenden Branche stehen, hat Bootstrap aber auch in Agenturen und bei Freiberuflern Einzug gehalten.

Über die technischen Aspekte von Bootstrap lässt sich weiterhin trefflich streiten. Daran werden vermutlich auch die – recht radikalen – Änderungen der anstehenden Version 4 (derzeit noch in der Alpha-Phase) nichts ändern. Technische Angriffsfläche bietet das Framework auch in Version 3 bereits genügend – seien es in Pixeln gesetzte Schriftgrößen, wenig semantische Klassennamen, übermäßig spezifische CSS-Anweisungen oder die Tatsache, dass Boostraps JavaScript-Plugins sich nicht um ein sauberes Fallback bemühen. Reicht das nicht, lässt sich das uralte Argument, die meisten damit erstellten Seiten sähen »halt doch irgendwie wie Twitter« oder »alle irgendwie gleich« aus, auch nicht immer von der Hand weisen.

Die Auswirkungen kritischer Masse

Bootstrap hat quasi kritische Masse erreicht und dabei – was weit interessanter ist als technische Einzelheiten – Abläufe und Prozesse in der Industrie verändert und beeinflusst und wird das (vermutlich) auch in Zukunft tun. Dabei sind die Veränderungen nicht immer klar positiv oder negativ.

Responsive Webdesign brachte die Forderung mit sich, das Prototyping in den Browser zu verlagern – bislang rein grafisch orientierte Designer soll(t)en lernen, Entwürfe direkt in HTML anstatt in Photoshop zu bauen, damit der Gestaltungsprozess direkt im richtigen Kontext und Medium stattfindet. Aber natürlich spielt auch hier die Effizienz eine Rolle – was bereits HTML ist, kann einfacher weiterverarbeitet werden. Mit Bootstrap und seinen Möglichkeiten, ganze Interfaces ohne fundamentales Wissen aus Markupbeispielen, HTML-Klassen und data-*-Attributen zusammenzustellen, ist genau das durchaus möglich. Bedeutet das aber, dass z.B. Agenturen in der Praxis zumindest in der Prototyping-Phase auf »echte« Frontendler, die über solides und umfangreiches Wissen in HTML und CSS verfügen, verzichten können und werden?

Großflächiger Einsatz eines Frameworks bedeutet üblicherweise auch, dessen Konventionen und Vorgehensweisen zu übernehmen. Das gilt insbesondere für Frameworks, die sich als »opinionated« verstehen, die also durchaus mit der Absicht entwickelt werden, Meinungen zu prägen. Mit anderen Worten: Bootstrap definiert im Prinzip – auch durch seine ausführlich mit Beispielen versehene Dokumentation – die »best practices«. Es gibt vor, wie Dinge gemacht werden sollen, aber nicht nur, damit sie innerhalb des Frameworks auch funktionieren, sondern weil die Entwickler des Frameworks sie »für richtig halten«. Eine Folge: Zusätzliche Komponenten werden danach ausgesucht, wie einfach sie sich in Boostrap integrieren und wie gut sie zum Rest des Frameworks passen. Das Framework bestimmt also im Prinzip mit, welcher Aufwand in ein Projekt investiert wird.

Da die Basis eines UI-Frameworks im Gegensatz zu einfachen Layout-Frameworks viel breiter ist, neigen Entwickler und Designer zudem dazu, wesentliche Komponenten (z.B. das Grid-System) wenig oder nur minimal anzupassen. Dies bestätigt der Eindruck, man könne die Verwendung von Bootstrap erkennen, ohne in den Quelltext gucken zu müssen. Das Design konzentriert sich auf die Anpassung kleiner Details und großer visueller Alleinstellungsmerkmale, da alles andere durch das UI-Framework stets ein »sauberes Fallback« hat – in einem UI-Framework ist nichts »ungestaltet«. Auch diese Vorgehensweise unterstützt natürlich den Eindruck der »Gleichschaltung« vieler Seiten – den Eindruck, sie stammten aus automatisierterMassenproduktion ohne Liebe zum Detail.

Man könnte sagen, Bootstrap propagiere eine »Kultur des Überschreibens«. Durch den Unterbau aus LESS bzw. Sass lassen sich kleine Anpassungen z.T. rein durch das Setzen von Variablen vornehmen; wer die CSS-Version verwendet, überschreibt diese »einfach« in einer zusätzlichen CSS-Datei. Diese Vorgehensweise betont noch zusätzlich den Aspekt, dass mit Bootstrap oft ein komplexes System für wenig komplexe Seiten verwendet wird. Da leider nicht alle Teile des Frameworks in Präprozessor-Mixins gekapselt sind, schleppen selbst Entwickler, die einen angepassten Build des Frameworks verwenden, immer ein paar nicht verwendete Klassen mit. Das ist natürlich alles andere als optimal.

Alle genannten Punkte haben letztlich eines gemein – sie führen zumindest potenziell dazu, dass der handwerkliche »Wert« von sauberem HTML und CSS gemindert wird und dass spezifisches Fachwissen in diesen Technologien an Bedeutung verlieren könnte. Bootstrap erzeugt in der Frontend-Entwicklung schon jetzt zumindest teilweise ein Monopol.

»Wenn Du einen Feind nicht besiegen kannst, umarme ihn.«

Vielleicht hat Bootstrap schon weit mehr erreicht als nur kritische Masse, sondern ist aufgrund seiner Größe und seines Umfangs schon längst an einem Punkt angelangt, an dem es nicht mehr ausreichend kritisch hinterfragt wird, weil es dazu – insbesondere für Einsteiger in die Materie – bereits zu komplex geworden ist. Vielleicht hat es aufgrund seiner weiten Verbreitung (auch und gerade als »3rd-Party-Komponente«) und seiner enormen Akzeptanz in der Industrie aber auch einen ganz anderen Einfluss auf die, die es benutzen. Wie wäre es, wenn Bootstrap tatsächliche »best practices« vorleben würde, welche Auswirkungen hätte es dann? Regen sich die »Handwerker« letztlich nur über Bootstrap auf, weil es technisch nicht hundertprozentig den Standards entspricht, die sie sich erarbeitet haben?

Bootstrap hat zweifelsohne das Potenzial, die Bedeutung von HTML und CSS in der Frontend-Entwicklung weiter zu schmälern. Es hat aber ebenso das Potenzial, mit einer unvergleichlichen Reichweite »vernünftige« Frontends zu propagieren und sehr mächtige Werkzeuge zu liefern, um eben diese zu erstellen. Da es ein Open-Source-Projekt ist, steht die Möglichkeit, es dahingehend zu beeinflussen, jedem Entwickler offen – in der derzeitigen Alpha-Phase auf dem Weg zu Version 4 vielleicht sogar noch mehr als sonst. Vielleicht ist es sinnvoller, sich an der Entwicklung dieses Frameworks zu beteiligen, anstatt sich darüber zu ereifern, dass jede damit erstellte Seite vermeintlich gleich aussähe?

Schließlich muss man jedoch auch feststellen, dass man zwar mit Bootstrap sehr schnell starten kann, aber auch recht schnell an Grenzen stößt. Zusätzliche Komponenten und individuelle Sonderlösungen ebenso wie Performance-Optimierungen brauchen Frontend-Fachwissen und praktische Erfahrungswerte, die man nicht aus der Bootstrap-Dokumentation ableiten kann. Es besteht also durchaus Hoffnung, dass auch in Bootstrap-Projekten weiterhin »echte« Frontendler gebraucht werden …