5 redenen waarom ik geen Bootstrap meer gebruik

-

Bootstrap is een open source frontend framework, ontwikkeld door een aantal medewerkers van Twitter. Hoewel dit een geweldig initiatief is van deze Twitter guys, ben ik er een tijd geleden volledig gestopt met het gebruik ervan, en raad ik het tegenwoordig zelfs af bij klanten en collega’s.

Vijf redenen waarom ik Bootstrap afraad:

1. Meer dan nodig

Omdat je met Bootstrap, in theorie, in staat moet kunnen zijn om je volledige website te bouwen met componenten uit de ‘blokkendoos’, zit er enorm veel in.

Echter zal het zelden voorkomen dat een developer alle beschikbare componenten uit het framework zal gebruiken. Waardoor er dus veel overbodige regels code in de CSS en Javascript bestanden van Bootstrap zitten. Overbodige KB’s zijn zonde van de performance.

Hier heeft Bootstrap wel wat op verzonnen. Je kan namelijk vrijwel alles customizen en componenten aan- of uitschakelen op de Bootstrap website en vervolgens het pakket downloaden dat precies op jouw wensen is afgestemd.

Opgelost dan, toch? Niet helemaal. Wanneer je in een langdurig project zit en bijvoorbeeld met SCRUM werkt, zullen er regelmatig wijzigingen in de wensen van de klant of in de designs voorkomen. Wat nu? De basis van je website zit opgesloten in twee gigantische Bootstrap bestanden. Er zit dan niks anders op dan teruggaan naar de Bootstrap website, de nieuwe wijzigingen doorvoeren en nieuwe bestanden downloaden en toevoegen aan je project. Niet iets wat je elke week wil doen. De SASS versie van Bootstrap geeft je wel meer vrijheid maar lost dit probleem niet op voor javascript en maakt bovendien de structuur van je project weer complexer. Een andere oplossing is gewoon de standaard Bootstrap styling overschrijven met je eigen custom CSS. Maar ook dit is niet optimaal;

2. Overwrites, overwrites en… overwrites

Als je voor klanten werkt, dan is er bijna altijd een design gemaakt voordat de ontwikkelaars aan de slag gaan (in het gunstigste geval ben je hier als ontwikkelaar al bij betrokken geweest). Dit vormt een nieuw probleem voor Bootstrap. Afgezien van een aantal aspecten die wel customizable zijn, heeft Bootstrap een standaard styling (die je ook steeds meer terugziet in websites). De kans dat de designers rekening hebben gehouden met een framework als Bootstrap is nihil.

Om de default styles aan te passen moet je in je eigen CSS de klassennamen van Bootstrap overnemen en dan overwrites doen van de default Bootstrap styles, of het design zodanig aanpassen dat het met Bootstrap werkt, maar hier zullen de designers waarschijnlijk niet blij van worden.

580-bootstraped1
Leuke illustratie van zingdesign.com

Dit was voor mij de voornaamste reden om te stoppen met Bootstrap. Toen ik wat meer ervaren werd met CSS en Javascript merkte ik dat het minder tijd kostte om een eigen header of een button te bouwen, dan een component uit Bootstrap gebruiken en deze vervolgens met overwrites naar het design aan te passen.

[css].navbar-default .navbar-nav > li.active > a:focus {
background: none;
color: black;
}[/css]

Voorbeeld van een overwrite van Bootstrap styles. Niet erg efficiënt.

Bovendien scheelt dit ook duplicate code en ben je een stuk flexibeler in het maken van aanpassingen later in het project.

3. Design patterns en semantiek

Bootstrap maakt het bijna onmogelijk om een CSS pattern als BEM of SMACSS te gebruiken in je markup, omdat de componenten van Bootstrap worden gekoppeld aan de HTML met klassennamen. Hiermee koppel je dus ook styling aan markup. Naast de styling koppel je ook nog het gedrag(javascript) van je website aan je HTML (klassennamen en data attributen). De bovengenoemde CSS patterns proberen juist het ontkoppelen van markup en styling en markup en gedrag zo veel mogelijk te bevorderen. Dit omdat het in een later stadium (na oplevering en live-gang) enorm scheelt in onderhoud als de markup zo min mogelijk gewijzigd hoeft te worden, omdat dit in veel gevallen templates voor een CMS zijn geworden (JSP, ASPX, PHP etc.). Design wijzigingen in een laat stadium zullen hiermee dus ook backend gaan raken. Daarnaast is ook semantiek lastig te behouden met Bootstrap. Bootstrap vereist dat je je markup volzet met te veel klassennamen, enkel om een bepaald Bootstrap component te kunnen gebruiken. Voor sommige componenten heb je soms wel 3 of 4 klassennamen nodig. Vervolgens is het voor een ‘buitenstaander’ nog steeds niet duidelijk welke rol dit component precies heeft in jouw website.

[html]

[/html]

HTML voorbeeld van een footer met Bootstrap

[html]

[/html]

HTML voorbeeld van een footer zonder Bootstrap, met BEM notatie

4. What about the grid?

Een argument wat ik zelf vaak hoor is “Ja maar, we hebben een grid nodig”. Natuurlijk zit er een prima grid in Bootstrap en is het vrijwel onmogelijk een responsive website te bouwen zonder grid. Echter zijn hier –naar mijn mening– alternatieven voor die nog een veel betere grid aanbieden dan Bootstrap, waarbij een grid ook het enige is wat ze bieden (niet meer dan nodig). Mijn favoriet is op dit moment Susy, omdat deze het mogelijk maakt met SASS een grid te bouwen, zonder dat dit gekoppeld is aan specifieke klassennamen (bijv. col-lg-2).

[css]
.product {
@include span(2 of 10);

@include breakpoint(980px) {
// 4 in a row
@include span(2.5 of 10)
}
@include breakpoint(980px) {
// 3 in a row
@include span(3.33 of 10)
}
@include breakpoint(600px) {
// 2 in a row
@include span(5 of 10)
}
@include breakpoint(380px) {
// 1 in a row
@include span(10 of 10)
}
}
[/css]

Voorbeeld van een grid met product blokken, gebouwd met Susy en SCSS

Nog een belangrijke reden om niet een grid zoals die van Bootstrap te gebruiken is dat ik zelf in de praktijk merk dat ik steeds meer breakpoints nodig heb voor een website en dat deze breakpoints kunnen verschillen per pagina. Een vooraf ingestelde set van bijvoorbeeld vijf breakpoints vervult dus niet meer altijd mijn behoeftes voor het bouwen responsive websites.

5. Dan is er nog javascript

Alle punten hierboven zijn vooral aan HTML en CSS gekoppeld. Maar zoals in het begin al genoemd, heeft de javascript van Bootstrap ook een aantal minpunten. Allereerst is de javascript altijd 1 groot bestand, waar je alleen via de Bootstrap website componenten uit kunt schrappen. AMD of browserify gebruiken is dus niet mogelijk voor de javascript van Bootstrap.

[javascript]
var progressElement = document.querySelector(‘#progress-bar’);
if (progressElement) {
var Progressbar = require(‘./components/Progressbar’);
new Progressbar(progressElement);
}
[/javascript]

Voorbeeld van hoe ik componenten inlaadt met browserify. Componenten worden pas geladen als ze aanwezig zijn op een pagina om memory te besparen.

Een nog groter minpunt vind ik het verplicht gebruiken van jQuery voor de meeste componenten uit Bootstrap. jQuery is namelijk ook een framework waar ik recent vanaf ben gestapt (maar dit is een ander verhaal). Het gebruiken van de javascript van Bootstrap belemmert je dus enorm in je flexibiliteit en zorgt vrijwel altijd voor overbodige KB’s.

Is Bootstrap ergens wél goed voor?

Ja zeker. Naast dat Bootstrap, ondanks alle minputen, sowieso een geweldig initiatief is, zijn er een aantal scenario’s waar Bootstrap enorm goed van pas kan komen. Zoals wanneer je extreem snel een prototype moet bouwen (bijvoorbeeld binnen 1 dag). Of als je een applicatie gaat bouwen waar de interface totaal onbelangrijk is (bijvoorbeeld een applicatie voor intern gebruik).

Waar ik Bootstrap misschien wel het beste voor vind, is voor de beginnende frontend developers. Toen ik zelf net begon met HTML en CSS was Bootstrap een soort springplank voor mij, die mij het gevoel gaf dat ik veel meer kon bouwen dan voorheen. Vervolgens ging ik daarna uitzoeken hoe Bootstrap dat nou eigenlijk doet op de achtergrond.

Bootstrap is dus een hartstikke mooi en handig framework, maar alleen voor heel specifieke situaties. Ik merk in de praktijk dat het een buzz-word is en dat het te vaak genoemd of gebruikt wordt, zonder dat er echt goed is over is nagedacht of het echt wel besparing oplevert in ‘the long run’. Zelf probeer ik het in ieder geval voortaan te vermijden.