Utility First, Komponen Kemudian

• Metodologi utility-first seperti tailwindcss dalam CSS sering dianggap sekadar menempelkan banyak kelas di HTML.

• Namun itu hanya tampilan luarnya; inti utility-first adalah persoalan kapan menyusun komponen.

• Pendekatan yang populer pada awal kemunculan CSS menimbulkan mimpi buruk dalam pemeliharaan.

• Arus OOCSS mencoba menyelesaikan masalah lewat penyusunan komponen. Reusabilitas meningkat, tetapi kemudian terbentur masalah sulitnya menetapkan batas cakupan komponen.

• Komponen dibuat untuk reusabilitas, tetapi masalahnya adalah kita tidak bisa tahu apa yang akan digunakan ulang di masa depan.

• Arus Atomic CSS mencoba menyelesaikan masalah dengan menetapkan hanya satu kelas untuk satu properti. Kecepatan pengembangan awal meningkat, tetapi masalah maintainability kembali muncul.

• Single Source of Truth terlalu mudah rusak — bergantung pada find-and-replace global (ketergantungan pada template eksternal merepotkan dan punya batas).

• Utility-first, berbeda dari atomic, menerima keberadaan komponen. Juga berbeda dari OOCSS, ia memulai dari utility. Komponen cukup disusun saat benar-benar dibutuhkan.

• Ini mengubah pertanyaan dari apa yang harus dijadikan komponen menjadi kapan komponen itu harus dibuat.

• Dengan kata lain, utility-first harus dipandang sebagai sintesis dari keduanya, sekaligus kelanjutan dan pengembangannya.

• Karena itu, dalam metodologi utility-first, komponen perlu lebih ditekankan. Bukan "kami mengizinkan komponen", melainkan "kami memaksimalkan reusabilitas dengan menundanya sampai titik ketika komponen benar-benar diperlukan".