Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Bootstrap – Segen oder Fluch?

UI-Frameworks

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 Werkzeuge zum Prototyping an, Projekte auf Basis von Bootstrap zu starten.

Eine Auswahl an UI-Elementen, wie Bootstrap sie standardmäßig bereit stellt
Eine Auswahl an UI-Elementen, wie Bootstrap sie standardmäßig bereitstellt

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.

Bootstrap 4 bietet keinen Support mehr für IE8 und bringt u.A. Sass (libsass) statt Less, (r)em statt px und optional ein Flexbox-basiertes Gridsystem mit.

Ü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 automatisierter Massenproduktion ohne Liebe zum Detail.

Screenshots von mehreren optisch sehr ähnlichen Bootstrap-Themes
Screenshots von mehreren optisch sehr ähnlichen Bootstrap-Themes

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 …

Kommentare

Matthias Apsel
am 08.12.2015 - 10:54

Danke für den gelungenen Überblick. Ich schenk dir noch ein "die" für "Bootstrap hat quasi kritische Masse erreicht" und möchte dich darauf aufmerksam machen, dass es keine CSS-Klassen gibt. ;-)

Permanenter Link
Matthias Mees

Matthias Mees (Autor)
am 08.12.2015 - 11:02

Danke für den Hinweis – die Artikel schreibenden Wichtel und Korrektur lesenden Elfen in der Webkrauts-Redaktion haben im Dezember immer sehr viel zu tun, da kann man schon mal etwas übersehen. ;-)

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Webkraut)
am 08.12.2015 - 12:02

Bei »Bootstrap hat quasi kritische Masse erreicht« muss nicht unbedingt ein »die« rein.

Permanenter Link
Michael Kühnel

Michael Kühnel (Webkraut)
am 08.12.2015 - 13:56

Danke für diesen Artikel. Er beschreibt ziemlich genau meine Gefühle^^

Trotzdem noch ein bisschen was als Kommentar / Ergänzung.

Vielleicht ließe sich der Punkt »übermäßig spezifische CSS-Anweisungen« noch darum erweitern das es das unmöglich macht sowas wie BEM mit Bootstrap zu mischen. Auf die Spitze getrieben wird die Sache mit der Spezifität bei den Tabellen. Siehe tables.less

Das alle Bootstrap Seiten gleich aussehen mag zutreffen, wenn man »nur« an den Variablen schraubt. Will man jedoch ein wirklich eigenes Design bspw. einer Navbar (Hautpnavigation) haben, ist man letzlich fast so viel am überschreiben, das man die Navigation von der Code-Menge her auch fast von Grund auf selbstgeschrieben hätte ; ]

Also in manchen Fällen ist man vielleicht tatsächlich besser und auf jeden Fall schlanker aufgestellt, wenn man einfach ein Grid-System nimmt und sich den Rest selbst schreibt bzw. andere isolierte Komponenten verwendet.

Eine Sache noch zu den »wenig semantische Klassennamen«. Das springt doch vor allem beim Grid ins Auge. Und da lassen sich nun mal keine Default Klassennamen mit ernsthafter Bedeutung festlegen. Aber das lässt sich über den Einsatz von Mixins und Variablen bei Verwendung von LESS durchaus realisieren.

Beispiel:

  1. <div class="wrapper">
  2.   <div class="content-main">...</div>
  3.   <div class="content-secondary">...</div>
  4. </div>

Siehe Doku.

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

Genau das haben wir uns auch gedacht und einen auf Grunt basierenden Workflow als Open Source veröffentlicht: Bootstrap Kickstart bzw. den dazugehörigen Yeoman Generator.

Neben dem Überprüfen von Markup nach HTML5 Standard wird das Markup hier z.B. auch mit einem Tool namens Bootlint überprüft ob man »fehlerhaftes« Bootstrap Markup verwendet.

Und beim erzeugen eines «Builds« wir nicht verwendetes CSS mit einem Tool namens UnCSS optional entfernt so dass man von 160 KB Bootstrap Standard CSS auf unter 40 KB kommen kann.

Auch automatische verlustfreie Bildkomprimierung und vieles andere mehr ist enthalten.

Permanenter Link
Matthias Mees

Matthias Mees (Autor)
am 08.12.2015 - 14:06

Vielleicht ließe sich der Punkt »übermäßig spezifische CSS-Anweisungen« noch darum erweitern das es das unmöglich macht sowas wie BEM mit Bootstrap zu mischen. Auf die Spitze getrieben wird die Sache mit der Spezifität bei den Tabellen.

RIchtig, die Tabellen sind besonders übel. Als jemand, der BEM nicht mag, stört mich der Aspekt relativ wenig ;) – man hat Mark Otto auch schon mal irgendwo™ gefragt, ob er Bootstrap auf BEM umstellen würde, und die Antwort war ein sehr vehementes Nein. :D

Das alle Bootstrap Seiten gleich aussehen mag zutreffen, wenn man »nur« an den Variablen schraubt.

Nicht nur. Es gibt bestimmte UI-Patterns, die Bootstrap letztlich definiert hat, und die erkennt man wieder. Obwohl es natürlich meistens daran liegt, dass sich jemand nicht die Mühe gemacht hat, individuell anzupassen.

Danke auch für Deine Hinweise zu Bootstrap Kickstart – sehr löblich, aber ich bin mir nicht sicher, ob das die „Zielgruppe“ erreicht bzw. es wäre vermutlich effektiver, wenn all das im Bootstrap-Kern wäre.

Permanenter Link

Gunnar Bittersmann
am 08.12.2015 - 14:45

TL;DR: „Bootstrap ist das Ikea der Webentwicklung,“ wie der Erklärbär so schön sagte.

Permanenter Link
Matthias Mees

Matthias Mees (Autor)
am 08.12.2015 - 14:50

… was mich daran erinnert, dass ich jemanden kenne, der sich als selbständiger Tischler darauf spezialisiert hat, Küchen, die sich Leute im dortigen Küchenplaner »nach Maß« zusammengestellt haben, vor Ort dann so zu bearbeiten, dass sie auch wirklich passen.

Permanenter Link

Gunnar Bittersmann
am 09.12.2015 - 09:11

Aber macht das Spaß?

“Bootstrap (noun): a CSS library applied to a site when the developer has lost heart in their profession.” —@iamdevloper

Wie ich schon mal erwähnte, denke ich, dass Bootstrap nichts für Frontend-Entwickler ist. Unternehmen, die ihre Website damit umzusetzen gedenken, können sich den Frontender auch sparen und einen Werkstudenten dafür einstellen.

Permanenter Link

Kai Dorschner
am 10.12.2015 - 17:06

Lustige Kommentare von Leuten die Bootstrap's Grundlagen ganz offensichtlich verstanden haben.

Wenn jene Kommentatoren ihre Bootstrap Anpassungen genauso realisieren wie die von wrapbootstrap oder bootswatch ihre Themes bauen habe ich sogar vollstes Verständnis für diese Aussagen und streichle mitleidig ihre Köpfchen.

Ain'ters gonna ain't...

Permanenter Link

Die Kommentare sind geschlossen.