Tailwind CSS: utility-first yaklaşımına neden geçtim

Tailwind CSS v1.0, Mayıs 2019’da yayınlandı. Daha önceden beta sürümünü denemiştim ama kararlı sürümle birlikte gerçek bir projede kullanmaya başladım. Sonucu paylaşmadan önce şunu söyleyeyim: başlangıçta direniş gösterdim. Sınıf listelerinin HTML’e gömülmesi bana yanlış geldi. Ama önyargıyı bir kenara bırakıp deneyince görüşüm değişti.

Neden utility-first?

BEM (Block Element Modifier), SMACSS, component-bazlı CSS — bunların hepsini kullandım. Her yaklaşımın temel problemi şuydu: bir bileşen için CSS yazarken iki dosya arasında gidip geliyorsunuz. Sınıf adı icat etmek, o sınıfın nerede tanımlandığını bulmak, var olan bir sınıfı değiştirince neyi etkilediğini anlamak. CSS büyüdükçe bu maliyet katlanıyor.

Utility-first yaklaşımda her sınıf tek bir CSS kuralı temsil ediyor: mt-4 dört birim üst boşluk, text-gray-700 belirli bir gri ton, flex esnek düzen. Bileşen için özel bir isim icat etmiyorsunuz; var olan yardımcı sınıfları bir araya getiriyorsunuz.

<!-- BEM yaklaşımı -->
<button class="button button--primary button--large">Gönder</button>

<!-- Tailwind yaklaşımı -->
<button class="px-6 py-3 bg-blue-600 text-white rounded-lg font-semibold hover:bg-blue-700">
  Gönder
</button>

İkinci versiyonu ilk gördüğünüzde “okunaksız” diyebilirsiniz. Ben de dedim. Ama bir süre sonra şunu fark ettim: o HTML satırını okuyunca butonun tam olarak nasıl göründüğünü ayrı bir CSS dosyasına bakmadan anlayabiliyorum.

Gerçek avantajlar

CSS büyümüyor. Geleneksel yaklaşımda, özellik ekledikçe CSS dosyası büyür. Tailwind’de ne kadar özellik eklerseniz ekleyin, kullandığınız sınıflar sabit bir havuzdan geliyor. PurgeCSS ile kullanılmayanları üretimde atan bir süreç kurduğunuzda son CSS dosyası birkaç KB olabiliyor.

Tasarım tutarlılığı kendiliğinden geliyor. Spacing, renkler, font boyutları — bunların hepsini özel değerlerle değil tailwind.config.js’deki skala ile kullanıyorsunuz. Bir geliştirici mt-4 yazarken başkası mt-[17px] yazmıyor; ya da yazıyorsa bu bir istisna olduğu için dikkat çekiyor.

Prototipleme hızı. Bir arayüzü hızlıca oluşturmak için Tailwind çok verimli. CSS yazıp kayıt edip tarayıcıya geçme döngüsü ortadan kalkıyor.

Trade-off’ları görmezden gelmemek

HTML kalabalıklaşıyor. Bu gerçek. Özellikle responsive (duyarlı) tasarım için breakpoint ön ekleri eklenince (md:flex lg:grid) sınıf listesi uzuyor. Tailwind’in @apply direktifi ile tekrar eden kalıpları sınıflara çıkarabiliyorsunuz ama bunu çok kullanırsanız “neden Tailwind seçtik?” sorusu tekrar geliyor.

İlk öğrenme eğrisi. Tailwind’in sınıf adlarını ezberlemeniz gerekiyor ya da sürekli dokümantasyona bakmanız. İlk haftalar yavaş geçiyor.

Tasarım sistemi yoksa karmaşa. Tailwind güzel bir araç ama onu da yanlış kullanmak mümkün. Renk paletini, spacing skalasını ve tipografiyi tailwind.config.js’de düzgün tanımlamadan başlarsanız her yerde inline overrides görürsünüz.

Ne zaman seçerim, ne zaman seçmem?

Projeyi tek başıma ya da küçük bir ekiple yürütüyorsam ve tasarım sistemi olgunlaşmamışsa Tailwind çok verimli. HTML’e yakın çalışmayı sevdiğim projelerde, özellikle Laravel Blade ve Vue bileşenlerinde iyi oturuyor.

Büyük bir front-end ekibi varsa ve tasarım sistemi bileşen kütüphanesi üzerine inşa edilmişse, utility-first yaklaşım sürtünme yaratabilir. Orada component-bazlı CSS daha iyi.

Tailwind’i “hype’ı olan bir araç” olarak değerlendirip geçiştirmek kolaydı. Ama arkasındaki fikri anlamak için kullanmak gerekiyordu. Benim için doğru bağlamda gerçekten verimli; başka bağlamlarda değil.