Sneller bouwen met TailwindCSS

Iedereen die mij een klein beetje kent weet dat ik niet zo heel erg goed ga op veranderingen. Ik kan een halve week van slag zijn als mijn vriendin de wasmand thuis een nieuw plekje heeft gegeven. Soms moet ik net even wat langer wennen aan veranderingen dan anderen om mij heen. En soms moet ik dan achteraf ook bekennen dat de nieuwe situatie beter is dan de oude.

Iedereen die leert om websites te bouwen, maakt vroeg of laat (vaker vroeg trouwens) kennis met CSS. Deze stijlbestanden staan vol met definities van hoe elementen op de website er uit zien. In de HTML-code definiëren we kale lege elementen op onze webpagina, die we vervolgens met CSS vorm geven.

.savebutton {
	border-radius: 12px;
	padding: 4px 8px;
	background: #10B981;
	color: #ffffff;
	font-weight: bold
}
<button class="savebutton">opslaan</button>

In dit voorbeeld creeëren we met HTML een knop die we de klasse 'savebutton' meegeven. Met css vertellen we de browser vervolgens hoe elementen met de klasse savebutton er uit moeten zien. In dit geval hebben we een groene koopknop opgemaakt.

Er zijn de afgelopen jaren veel manieren ontwikkeld om het schrijven van CSS gemakkelijker te maken. Met SASS en LESS kunnen we bijvoorbeeld stukjes voorprogrammeren en vervolgens importeren in onze stijlbestanden en kunnen we onze stijlbestanden opbouwen met variabelen. Daarmee kunnen we vervolgens gemakkelijk een kleur op de hele website wijzigen, wat ons weer een hoop werk uit handen neemt ten opzichte van de oude situatie waarin we netjes elk regeltje css zelf schreven.

Je kunt je vast voorstellen dat zo'n css-bestand snel in formaat toeneemt. Voor elke link op de website die er anders uit ziet dan de andere linkjes maken we namelijk een nieuwe klasse aan in het bestand. Voor een gemiddelde website of webshop telt je stijlbestand al snel enkele duizenden regels die maken dat het bestand ook groter wordt om te laden bij het openen van de webpagina. Daarnaast wordt je als ontwikkelaar niet perse enthousiast om iedere keer in duizenden regels opzoek te gaan naar een bestaande klasse voor iets dat je wilt ontwikkelen. Je schrijft sneller de regels die je nodig hebt onderin het CSS-bestand en geeft je klasse een originele naam. Doordat het bestand na een aantal jaar vol staat met stijldefinities van bijvoorbeeld knoppen of afbeeldingen die helemaal niet meer bestaan. Het bestand blijft daardoor enkel groeien en neemt nooit in grootte af. Als je daarnaast gebruik maakt van een framework zoals bootstrap, is een css-bestand van meer dan 140 kilobyte geen uitzondering.

Nu kunnen we stellen dat het internet momenteel snel genoeg is om een bestand van 140 kilobyte te downloaden zonder daar (lang) op te hoeven wachten. Met een 3G verbinding is je css-bestand bijvoorbeeld in een seconde geladen. Toch is er in ieder geval één goede reden om je wel zorgen te maken over de bestandsgrootte van je css-bestand (of andere 'assets' op je website): Google.

Het is een publiek geheim dat Google bij het indexeren van je website rekening houdt met de laadsnelheid van je pagina's en je daarvoor beloont óf op afrekent. Als jouw website meer en grotere bestanden moet inladen voordat je bezoeker je website kan gebruiken, wordt je lager opgenomen in de zoekresultaten dan je concurrent met een snelle(re) website.

Tailwind css

Er ontstaan dus een paar uitdagingen met onze goede oude werkwijze. Websites duren langer om te laden, worden minder goed geïndexeerd en zijn voor de ontwikkelaars lastiger om te onderhouden aangezien de code een steeds onoverzichtelijke chaos wordt.

Opzoek naar een oplossing kwamen mijn collega's uit bij Adam Wathan, een Canadese ontwikkelaar die bezig was met het ontwikkelen van Tailwind css: een utility first framework. Zijn aanpak is fundamenteel anders dan die van andere css-frameworks. In plaats van standaard opgemaakte elementen bestaat zijn framework uit niets anders dan heel veel 'simpele' klassen met slechts één waarde. Zogenoemde 'utility-classes'.

.text-sm { 
	font-size: 10px;
}
.text-base {
	font-size: 13px;
}
.text-lg {
	font-size: 16px;
}
.text-xl {
	font-size: 21px;
}
.text-2xl {
	font-size: 24px;
}
.text-red {
	color: #F87171;
}
.text-orange {
	color: #FB923C;
}

In plaats van de stijlregels te bundelen in klassen en deze te koppelen in de html, stylen we de elementen met één of meerdere utility-classes per element. Het voorbeeld van de groene knop ziet er met Tailwind css bijvoorbeeld als volgt uit:

<button class="bg-green text-white px-4 py-2 rounded-lg font-bold">
	opslaan
</button

Hoewel mijn collega's vrij snel overtuigd waren van deze nieuwe methode, was ik (natuurlijk) wat terughoudend over deze verandering. Ik had bijvoorbeeld geleerd dat je de structuur (html) en opmaak (css) nooit door elkaar heen moet gebruiken en dat je code zo clean mogelijk zou moeten zijn. Uiteindelijk is het zelfs de bedoeling dat er helemaal geen css geschreven wordt met tailwind css. Ik was vooral bang dat alle websites er nu hetzelfde uit gingen zien en maatwerk vrijwel onmogelijk was nu we alle websites zouden gaan baseren op dezelfde stijl. Eigenlijk was ik absoluut geen fan van een nieuwe werkwijze die iedereen zichzelf eigen moet maken.

Meestal, als ik een paar dagen heb geprotesteerd, trek ik wel een beetje bij en klim ik 's avonds thuis op de bank en geef ik het een kans. Of je het echt een kans mag noemen weet ik overigens niet, want ik ben dan meestal meer opzoek naar de bevestiging van mijn argumenten. Zo ook met tailwind css.

Ik besloot op Adams youtube kanaal een paar tutorials te volgen en had eigenlijk al snel de smaak te pakken. Ik hoefde niet meer steeds te schakelen naar mijn eigen css bestanden en was niet constant meer opzoek naar nieuwe namen voor mijn klassen. Snel ontdekte ik dat je in een configuratiebestand het hele framework naar je eigen hand kan zetten en dat je dus absoluut niet vast zit aan de voorgedefinieerde stijlen. Sterker nog: daar is het framework voor ingericht. Wanneer we wijzigingen hebben aangebracht in de standaardconfiguratie kunnen we met één druk op de knop een nieuw css-bestand genereren. Eigenlijk moet ik toegeven dat het realiseren van ontwerpen met tailwind css een stuk sneller en efficiënter geworden is. Ik schrijf minder code en kan me meer focussen op de opbouw van de pagina in plaats van het bedenken van passende namen voor mijn klassen.

We hebben inmiddels dus het onderhoudsprobleem opgelost: mijn collega's en ik hoeven niet meer door talloze klassen te zoeken naar de code waar de kleur van de menuknoppen worden gedefinieerd. We kunnen nu bij in de html al lezen welke styling het element meegekregen heeft.

Google

Tailwind css genereert in de basis een serieus groot css bestand. Dat komt voornamelijk doordat er honderden klassen gegenereerd worden die een ontwikkelaar eventueel kán gebruiken. Het css-bestand van deze website is ruim 4 megabyte groot. Dat is 28 keer groter dan het bestand waar ik het net nog over had. Gelukkig is daar ook een oplossing voor in de vorm van postcss. Met postcss kunnen we het tailwind css bestand filteren op klassen die we daadwerkelijk gebruiken in de website. Wanneer we ons css-bestand door postcss heen halen, houden we nog slechts 6 kilobyte aan css over. Deze winst in bestandsgrootte scheelt een enorme slok op een borrel als we het over laadtijd (en dus ook indexering binnen zoekmachines) hebben. Tweede uitdaging getackeld!

De voordelen op een rijtje

• sneller en efficienter opbouwen van webpaginas

• minder 'context switchen' tussen html en css bestanden

• kleinere en schonere bestanden

• gemakkelijke configuratie

Soms moet ik eerlijk zijn en toegeven dat een nieuwere methode beter is dan mijn vertrouwde methoden. Soms moet je dan zeggen ik zat er heel erg naast. En nu moet ik zelfs zeggen dat ik er van baal dat we dit niet weken, maanden of zelfs jaren eerder hebben gevonden. Iedere keer als ik een non-tailwind project open voor wat wijzigingen schrik ik ervan als ik zie dat ik hier niet weg kom met de tailwind utilities. Voorlopig is tailwind onze best-practice.