Belajar Tailwind CSS - Sejarah, Latar Belakang & Mengapa Membutuhkan Tailwind CSS

#Pendahuluan

Sebelum memahami teknik Tailwind, penting untuk memahami mengapa Tailwind ada. Episode 1 menelusuri perjalanan styling di web: dari CSS monolith, preprocessor, pola arsitektur seperti BEM, hingga lahirnya utility-first CSS. Konteks sejarah ini membuat kalian menghargai desain Tailwind sekaligus tahu kapan pendekatan lain lebih cocok.

Setiap teknologi dipakai karena menjawab masalah masanya. BEM dan OOCSS memecahkan masalah naming convention di CSS besar; CSS-in-JS memecahkan masalah scoping; Tailwind memecahkan masalah konsistensi dan produktivitas. Memahami masalah mana yang dipecahkan oleh apa akan menuntun kalian dalam keputusan arsitektur di project nyata.

Di akhir episode, kita akan melihat studi kasus kecil: memigrasi satu komponen tombol dari CSS tradisional ke utility class Tailwind.

#Evolusi Styling di Web

#Era CSS Monolith dan Preprocessor

Pada awal web, gaya ditulis dalam satu stylesheet besar dengan selector berbasis elemen dan class. Seiring aplikasi membesar, file menjadi sulit dirawat, nama class berbenturan, dan cascade sering menjadi sumber bug. Preprocessor seperti Sass dan LESS membantu dengan variabel, mixin, dan nesting, tetapi tidak menyelesaikan akar masalah: naming convention dan skalabilitas selector.

#Pola Arsitektur CSS

Kemudian lahir pola arsitektur. OOCSS memisahkan struktur dan skin, SMACSS membagi kategori aturan, dan BEM memaksa naming convention block__element--modifier. BEM sangat populer karena membuat CSS lebih dapat diprediksi, tetapi menuntut disiplin tinggi dan menghasilkan markup yang verbose.

#Kelahiran Utility-First

Pada 2017, Tailwind Labs merilis Tailwind CSS, dipelopori oleh Adam Wathan dan tim. Gagasan utamanya sederhana: alih-alih memberi nama abstrak pada komponen, sediakan utility class kecil yang memetakan satu properti CSS, lalu kombinasikan langsung di markup. Pendekatan ini merevolusi cara tim memikirkan styling.

#Apa Itu Utility-First CSS?

Utility-first adalah strategi styling di mana kelas-kelas kecil dan fokus — seperti p-4, flex, bg-blue-500 — dipakai langsung untuk membentuk UI, tanpa menulis CSS komponen sendiri. Perbandingannya dengan CSS tradisional:

CSS tradisional vs utility-first

<div class="card">
  <h2 class="card__title">Kartu</h2>
</div>
 
<div class="rounded-lg border border-gray-200 p-4 shadow-sm">
  <h2 class="text-lg font-semibold">Kartu</h2>
</div>

Perhatikan: di versi utility-first, tidak ada CSS kustom yang perlu ditulis atau dipelihara. Semua deklarasi dibangkitkan Tailwind dari class yang dipakai di markup.

#Perbandingan Pendekatan

#Tailwind vs CSS Tradisional

CSS tradisional memisahkan styling dari markup; Tailwind menyatukannya. CSS tradisional unggul dalam file yang kecil untuk kasus sederhana, tetapi Tailwind unggul dalam konsistensi karena kalian tidak pernah menulis nilai hex baru — semua warna dan spacing berasal dari design token yang sama.

#Tailwind vs BEM

BEM memberikan nama yang deskriptif pada komponen dan bagus untuk dokumentasi, tetapi nama panjang block__element--modifier sering dipakai hanya sekali. Tailwind meniadakan kebutuhan naming convention sekaligus: gaya dan struktur hidup di satu tempat, dan tidak ada style yang "yatim" — didefinisikan tapi tak pernah terpakai.

#Tailwind vs CSS-in-JS

CSS-in-JS seperti styled-components menawarkan scoping dan theming runtime yang kuat, tetapi menambah runtime JavaScript ke bundle. Tailwind membangkitkan CSS statis saat build — tanpa runtime sama sekali. Untuk aplikasi yang mementingkan performance, ini keunggulan besar; koeksistensinya akan dibahas di episode 18.

#Tujuan dan Trade-offs

Tujuan Tailwind: produktivitas karena tidak berpindah file, konsistensi karena token terpusat, dan pengurangan CSS kustom yang mudah membusuk. Trade-off yang harus dipahami:

• Ukuran HTML bertambah karena banyak class di tiap elemen, walau hasil akhirnya sering lebih kecil dalam keseimbangan.
• Markup terlihat lebih "berisik" bagi yang belum terbiasa, meski developer berpengalaman membacanya lebih cepat.
• Determinisim tinggi: hasil akhir sangat dapat diprediksi, tapi kalian harus mempelajari lebih banyak nama kelas.

#Studi Kasus: Migrasi Komponen

Bayangkan komponen tombol dengan CSS tradisional:

Komponen sebelum migrasi

<button class="btn btn-primary">Simpan</button>

Dengan stylesheet terpisah:

CSS lama

.btn {
  padding: 0.5rem 1rem;
  border-radius: 0.25rem;
}
.btn-primary {
  background: #3b82f6;
  color: #fff;
}

Migrasi ke Tailwind menghapus dua aturan CSS dan memindahkan semuanya ke satu markup:

Komponen setelah migrasi

<button class="rounded bg-blue-500 px-4 py-2 text-white hover:bg-blue-600">
  Simpan
</button>

Kelas hover:bg-blue-600 menambahkan variasi hover tanpa menulis satu baris CSS. Nilai #3b82f6 dipakai bg-blue-500, sehingga tidak ada lagi hardcoded color yang tersebar di banyak file.

#Penutup

Episode 1 memberi konteks sejarah dan alasan mengapa Tailwind CSS menjadi standar de facto pengembangan frontend modern. Kalian sekarang memahami perjalanan dari CSS monolith ke utility-first, perbedaan Tailwind dengan BEM dan CSS-in-JS, trade-offs yang perlu dipertimbangkan, serta gambaran migrasi komponen.

Inti yang harus dibawa pulang:

• Utility-first memetakan satu properti CSS ke satu kelas kecil.
• BEM memberi nama pada komponen; Tailwind menghilangkan kebutuhan naming convention.
• Tailwind menghasilkan CSS statis tanpa runtime, berbeda dari CSS-in-JS.
• Trade-off utama: markup lebih verbose, tetapi konsistensi dan produktivitas naik.
• Migrasi ke utility class menghapus CSS kustom dan nilai warna yang tersebar.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama Tailwind — bagaimana JIT engine dan content scanning bekerja, struktur tailwind.config.js, direktif @tailwind base, components, utilities, hingga plugin resmi pertama yang perlu kalian kenal. Ini adalah fondasi teknis sebelum kalian menulis utility class pertama di episode 3.