Rilis Tailwind CSS v4.0

 (tailwindcss.com)
1 poin oleh GN⁺ 2025-01-24 | 1 komentar | Bagikan ke WhatsApp
  • Tailwind CSS v4.0 adalah rilis yang menulis ulang framework ini dari nol, secara signifikan meningkatkan performa build dan mengubah alur konfigurasi serta kustomisasi menjadi berpusat pada CSS
  • Berdasarkan Catalyst, build penuh menjadi 3,78x lebih cepat, dari 378ms di v3.4 menjadi 100ms di v4.0, dan build inkremental tanpa CSS baru meningkat 182x, dari 35ms menjadi 192µs
  • Instalasi disederhanakan menjadi satu baris @import "tailwindcss" dan nilai default tanpa konfigurasi, sementara pengguna Vite bisa memakai @tailwindcss/vite alih-alih PostCSS
  • v4.0 memanfaatkan fitur CSS modern seperti cascade layers, @property, color-mix(), dan logical properties, serta menghadirkan deteksi konten otomatis dan pemrosesan @import bawaan
  • Container query, 3D transform, API gradient yang diperluas, @starting-style, not-*, field-sizing, color-scheme, dan inert kini masuk ke fitur inti sehingga mengurangi ketergantungan pada plugin terpisah

Mesin berperforma tinggi yang ditulis ulang dari nol

  • Tailwind CSS v4.0 adalah versi yang ditulis ulang sepenuhnya dari nol berdasarkan pengalaman arsitektur selama bertahun-tahun
  • Dalam benchmark proyek internal, rebuild penuh menjadi lebih dari 3,5x lebih cepat, dan build inkremental menjadi lebih dari 8x lebih cepat
  • Waktu build median berdasarkan Catalyst adalah sebagai berikut
    • Build penuh: v3.4 378ms → v4.0 100ms, peningkatan 3,78x
    • Rebuild inkremental dengan CSS baru: 44ms → 5ms, peningkatan 8,8x
    • Rebuild inkremental tanpa CSS baru: 35ms → 192µs, peningkatan 182x
  • Build inkremental yang tidak perlu mengompilasi CSS baru menjadi lebih dari 100x lebih cepat dan selesai dalam satuan mikrodetik
    • Semakin lama sebuah proyek dikerjakan, semakin sering kelas yang sudah pernah dipakai seperti flex, col-span-2, dan font-bold digunakan kembali, sehingga jenis build ini akan makin sering ditemui

Memanfaatkan platform CSS modern

  • v4.0 secara aktif memanfaatkan kemampuan platform web yang berkembang sejak Tailwind CSS v3.0
  • Fitur CSS dasar yang menjadi fondasi utamanya adalah sebagai berikut
    • Native cascade layers: mengontrol dengan lebih rinci bagaimana aturan style yang berbeda saling berinteraksi
    • Registered custom properties: memungkinkan animasi gradient dan sangat meningkatkan performa pada halaman besar
    • color-mix(): dapat menyesuaikan opasitas semua nilai warna, termasuk CSS variable dan currentColor
    • Logical properties: menyederhanakan dukungan RTL dan mengurangi ukuran CSS yang dihasilkan
  • Fitur-fitur ini juga menyederhanakan implementasi internal Tailwind, mengurangi permukaan bug, dan mempermudah pemeliharaan

Penyederhanaan instalasi dan integrasi build

  • Alur instalasi dirapikan untuk mengurangi langkah dan boilerplate
    • npm i tailwindcss @tailwindcss/postcss
    • Tambahkan @tailwindcss/postcss ke plugin PostCSS
    • Gunakan @import "tailwindcss" di file CSS
  • Di v4.0, Tailwind kini bisa diimpor dan digunakan dengan satu baris CSS alih-alih direktif @tailwind
  • Tersedia alur tanpa konfigurasi yang bisa langsung dimulai tanpa pengaturan apa pun, termasuk path file template
  • Tanpa plugin eksternal terpisah, aturan @import dibundel, dan Lightning CSS digunakan secara internal untuk vendor prefixing serta transformasi sintaks modern
  • Pengguna Vite dapat memilih @tailwindcss/vite alih-alih PostCSS
    • Tailwind CSS v4.0 sudah cepat sebagai plugin PostCSS, tetapi plugin Vite dapat memberikan performa yang lebih baik

Deteksi konten otomatis dan import bawaan

  • Pengaturan array content yang diperlukan di v3 digantikan oleh heuristik deteksi otomatis di v4.0
  • Item yang ada di .gitignore akan otomatis diabaikan sehingga dependensi atau file hasil generate yang tidak dikelola version control tidak akan dipindai
    • Contoh: /node_modules, /coverage, /.next, /build
  • Ekstensi biner seperti gambar, video, dan .zip juga otomatis diabaikan
  • Jika perlu menambahkan sumber yang secara default dikecualikan, direktif @source dapat digunakan di dalam file CSS
    • @source "../node_modules/@my-company/ui-lib";
    • @source juga memakai heuristik yang sama, sehingga tipe file biner tetap dikecualikan tanpa perlu menentukan ekstensi terpisah
  • Sebelum v4.0, untuk meng-inline file CSS lain dengan @import, dibutuhkan plugin terpisah seperti postcss-import, tetapi sekarang hal itu tidak lagi diperlukan berkat dukungan import bawaan
    • Sistem import ini dibuat khusus untuk Tailwind CSS dan terintegrasi erat dengan mesinnya sehingga bekerja lebih cepat

Konfigurasi CSS-first dan theme variables

  • Salah satu perubahan besar di v4.0 adalah proyek kini dikonfigurasi langsung di CSS, bukan di JavaScript
  • Alih-alih file tailwind.config.js, kustomisasi dapat dilakukan dengan @theme di file CSS yang mengimpor Tailwind
    • Mengatur design token
    • Mendefinisikan utility kustom
    • Mendefinisikan variant kustom
  • Design token yang didefinisikan di @theme secara default diekspos sebagai CSS variable
    • Contoh: --font-display, --breakpoint-3xl, --color-avocado-500, --ease-fluid
  • CSS variable yang dihasilkan ini dapat dirujuk dari CSS biasa saat runtime
    • Menggunakan ulang inline style
    • Meneruskannya ke library seperti Motion untuk menangani animasi

Nilai utility dinamis dan variant

  • v4.0 menyederhanakan banyak utility dan variant agar dapat menerima nilai arbitrer tertentu tanpa konfigurasi
  • Grid dapat memakai ukuran apa pun tanpa konfigurasi tambahan
    • Contoh: grid grid-cols-15
  • Atribut data boolean kustom juga dapat ditargetkan tanpa perlu didefinisikan terlebih dahulu
    • Contoh: data-current:opacity-100
  • Utility spacing seperti px-*, mt-*, w-*, h-* diturunkan secara dinamis dari satu variabel skala spacing
    • Contoh: --spacing: 0.25rem
    • w-17 akan dihasilkan dalam bentuk calc(var(--spacing) * 17)
  • Tool upgrade yang dirilis bersama v4.0 akan secara otomatis menyederhanakan sebagian besar sintaks nilai arbitrer yang sudah tidak diperlukan

Palet warna dan container query

  • Seluruh palet warna bawaan ditingkatkan dari rgb ke oklch
    • Warna menjadi lebih hidup dengan memanfaatkan gamut yang lebih luas di luar batas ruang warna sRGB
    • Karena keseimbangan antarwarna dari v3 tetap dipertahankan, upgrade proyek lama seharusnya tidak terasa seperti breaking change
  • Dukungan container query kini menjadi fitur inti di v4.0 sehingga plugin @tailwindcss/container-queries tidak lagi diperlukan
  • Variant @max-* baru dapat digunakan untuk container query max-width
  • Seperti variant breakpoint biasa, @min-* dan @max-* dapat ditumpuk untuk mendefinisikan rentang container query

3D transform dan perluasan API gradient

  • v4.0 menambahkan API untuk 3D transform
    • rotate-x-*
    • rotate-y-*
    • scale-z-*
    • translate-z-*
  • Fitur gradient juga diperluas sehingga lebih banyak efek dapat dibuat tanpa CSS kustom
  • Linear gradient kini dapat menerima sudut sebagai nilai
    • Contoh: bg-linear-45
    • bg-gradient-* lama diganti namanya menjadi bg-linear-*
  • Mode interpolasi warna gradient dapat dikontrol dengan modifier
    • bg-linear-to-r/srgb
    • bg-linear-to-r/oklch
    • Interpolasi default v4.0 adalah OKLAB, dan modifier ruang warna lain juga dapat digunakan
  • Utility bg-conic-* dan bg-radial-* baru memungkinkan pembuatan conic dan radial gradient
    • Bekerja bersama from-*, via-*, dan to-* yang sudah ada
    • Termasuk dukungan nilai arbitrer untuk kontrol detail seperti pengaturan metode interpolasi warna dan posisi gradient

Variant dan utility baru

  • Variant starting baru mendukung CSS @starting-style
    • Dapat membuat transisi properti saat elemen pertama kali ditampilkan
    • Memungkinkan animasi elemen yang muncul di halaman tanpa JavaScript
    • Dukungan browser mungkin masih belum cukup untuk sebagian besar tim, tetapi sudah semakin dekat
  • Variant not-* baru mendukung pseudo-class CSS :not()
    • Contoh: not-hover:opacity-75
    • Media query dan query @supports juga dapat dinegasikan
  • v4.0 juga menambahkan utility dan variant berikut
    • inset-shadow-*, inset-ring-*: dapat menumpuk hingga 4 layer box shadow pada satu elemen
    • field-sizing: mendukung pengubahan ukuran textarea otomatis tanpa JavaScript
    • color-scheme: dapat menghilangkan scrollbar terang di dark mode
    • font-stretch: menyesuaikan variable font yang mendukung berbagai lebar
    • inert: memberi style pada elemen noninteraktif yang ditandai dengan atribut inert
    • nth-*: mendukung styling seri nth
    • in-*: bekerja mirip group-* tanpa kelas group
    • :popover-open: juga menargetkan popover yang terbuka dengan variant open yang ada
    • descendant variant: memberi style pada semua elemen turunan

Memulai dan jalur upgrade

Bacaan terkait

1 komentar

 
GN⁺ 2025-01-24
Pendapat Hacker News

  • Dulu saya pernah mengkritik keras berbagai kekurangan Tailwind dan ketidakcocokannya dengan cara web “murni” yang benar-benar modern, tetapi kemajuan besar di v4 sangat menggembirakan
    Perubahan bahwa tema Tailwind bisa diakses sebagai variabel CSS native, dan dokumentasinya bahkan memuat contoh komponen tombol yang ditulis dengan variabel native di stylesheet eksternal, adalah perubahan yang luar biasa
    Kemampuan untuk melakukan konfigurasi hanya dengan CSS juga bagus, dan sekarang Tailwind terasa seperti utilitas yang bisa ditambahkan ke proyek apa pun, bukan framework “viral” ala JavaScript yang menelan arsitektur yang masuk akal
    Entah kritik selama beberapa tahun terakhir memang berdampak, atau mereka sendiri sampai pada kesimpulan yang baik, banyak perdebatan pro-kontra Tailwind kini tampak kurang relevan, dan itu hal yang sangat baik. Sekarang kita bisa fokus membuat produk

    • Dari sisi penggunaan nyata, saya masih kritis, tetapi mengejutkan bahwa Tailwind sangat cocok dengan alur kerja yang dihasilkan AI
      Karena apa pun bisa diekspresikan secara sistematis, ini bekerja sangat baik, dan ada sesuatu yang sangat berguna di sana
    • Sulit setuju bahwa perdebatan pro-kontra Tailwind sudah tidak relevan, dan sebagai desainer/design engineer ada dua masalah
      Pertama, engineer JavaScript/Tailwind telah mendominasi diskusi desain. Mereka lebih fokus pada “utility-first”, “menghapus kode yang tidak dipakai”, “CSS yang type-safe” daripada sistem desain, misalnya apakah dalam tipografi harus memakai Perfect Fifth atau Perfect Fourth
      Kedua, Tailwind membuat proses produksi nyata sulit diikuti. Keputusan desain terkubur di dalam ekspresi komponen React yang sulit dibaca seperti flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)]
      Mungkin bisa dipahami oleh engineer JavaScript, tetapi menjadi penghalang bagi desain yang sistematis. Alih-alih mengekspresikan relasi matematis yang presisi dengan CSS, ini seperti memakai inline style yang lebih nyaman
    • Saya hanya ingin palet warna Tailwind CSS

  • CSS sudah jauh lebih mudah digunakan dibanding dulu, dan sebagian besar browser sekarang juga berperilaku konsisten
    Ini layak dipelajari karena tidak perlu tahap build dan tidak mengotori markup dengan kode berlebihan
    Kita juga bisa menulis atribut style langsung di HTML, yang dulu dihindari demi pemisahan concern. Jadi saya heran mengapa ingin memperkenalkan kembali pendekatan serupa. Rasanya hanya demi mengurangi beberapa karakter saja
    Atribut style malah terlihat lebih intuitif karena tidak perlu menerjemahkan kode di kepala. Saya kurang melihat daya tariknya

    • Ada cukup banyak hal yang tidak bisa dilakukan dengan atribut style. Misalnya pseudo-class :hover, :focus, pseudo-element ::before, ::after, media query, keyframe, dan animasi
      Pengalaman developer di proyek besar juga tidak bagus
      Di sisi lain, @scope yang akan segera menjadi standar adalah tambahan bagus untuk menempatkan style di dekat tempatnya: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
    • Tailwind sekarang sering dipakai bersama sistem abstraksi komponen yang berperan sebagai lapisan abstraksi, alih-alih sebagai class CSS
      Abstraksi komponen memisahkan makna dan style dengan lebih kuat. Dalam kedua kasus kita tetap harus mencari abstraksi “hero”, tetapi di dunia komponen, bukan hanya style, nama tag HTML pun ikut diabstraksikan
      Bagaimanapun, “detail style” dipisahkan dari “konten”, yaitu file sumber halaman. Demi pemisahan concern—yakni pemisahan konten dan presentasi yang lebih baik—tahap build bisa diterima
    • Daya tariknya adalah tidak perlu menamai class CSS, mudah dibaca karena berdampingan dengan HTML, dan cara penamaannya distandardisasi sehingga aturan yang sama dipakai di mana-mana
      Kebutuhan untuk mengelola file terpisah dan menghapus komponen yang tidak dipakai juga berkurang
      Kita bisa memakai media query yang tidak bisa dilakukan dengan tag style, dan tidak ada risiko mengubah class yang dipakai di tempat lain. Scope global CSS punya kelebihan, tetapi juga berbahaya
    • Ini hasil dari anggapan yang terlalu wajar bahwa semuanya sangat terikat dengan React
      Style dianggap milik komponen, bukan sistem desain. Ekosistem engineering yang JavaScript-first membutuhkan lebih banyak perusahaan yang digerakkan oleh desain yang memahami kekuatan CSS modern dan desain sistematis
    • Kalau melihat jumlah file yang harus ditangani di proyek besar, Tailwind terlihat cukup menarik
      Pendekatan .css biasa memunculkan nama-nama aneh, duplikasi, dan kemungkinan konflik. css modules juga bisa jadi pilihan, tetapi jumlah file per komponen/halaman praktis menjadi dua kali lipat
      sass atau less terasa seperti menggabungkan masalah css modules dan .css biasa
      Saya tidak secara mendasar menyukai atau membenci Tailwind, dan awalnya sangat tidak suka, tetapi dalam proyek yang terdiri dari komponen dan halaman dengan lebih dari 200 file, nilainya terasa

  • Reaksi pertama terhadap Tailwind adalah “merepotkan”. Rasanya seperti sudah tahu CSS, tetapi sekarang harus belajar CSS lagi
    Ini mirip situasi ketika orang tua mencoba membantu PR matematika anaknya, tetapi cara yang diajarkan di sekolah sudah sangat berbeda dari dulu; cara penyelesaiannya sendiri masih benar, tetapi tidak diterima, dan si anak kesal karena harus mencocokkan dua sistem
    Saya paham suasana di tim yang menganggap kita sebaiknya pakai saja karena bekerja dengan baik dan mudah diskalakan, dan saya juga pernah mengalaminya
    Namun saya masih lebih suka stylesheet biasa yang menargetkan class atau tag. Apalagi sekarang CSS sudah mendukung selector bersarang
    Memang ada masalah pengelolaan stylesheet, dan saya suka pendekatan seperti Remix/React Router yang mendefinisikan dan menerapkan file CSS di level route. Kalau itu kurang, atau style dinamis menjadi terlalu rumit di file .css, style={{...}} juga selalu bisa dipakai
    CSS itu kuat, fleksibel, dan dapat diskalakan, jadi Tailwind terasa seperti pembatasan, bukan perbaikan. Saya tidak benar-benar tahu kenapa tetap populer, tetapi menurut saya dalam 3–4 tahun semua orang akan pindah lagi ke hal lain

    • Awalnya rasa seperti harus belajar ulang CSS memang menyebalkan, dan dulu saya juga berpendapat begitu
      Namun setelah berkontribusi ke proyek open source yang memakai Tailwind, saya jadi terbiasa, dan sekarang rasanya berbeda
      Pada dasarnya Tailwind lebih dekat ke shorthand untuk style={{…}}. Hal-hal yang di file .css atau objek style butuh beberapa baris bisa selesai dengan satu utility sekitar 15 karakter
      Waktu yang terbuang untuk mencari hal seperti “visual text replacement css”, membuka cheat sheet CSS, atau mengubek artikel CSS-Tricks 8 tahun lalu jauh berkurang. Sebagai gantinya, saya selalu melihat dokumentasi Tailwind dan cepat menemukan utility class yang melakukan hal yang saya inginkan
      Mengejutkan, banyak sekali yang masuk ke cache di kepala, dan rasanya jauh lebih baik daripada mencoba menghafal semua CSS yang dibutuhkan untuk pekerjaan layout
    • Menurut saya karena sekarang seluruh komponen masuk dalam satu file
      Tidak perlu menyentuh CSS terpisah, dan style berada tepat di atas elemen yang diberi style, jadi tidak perlu membandingkan bolak-balik
      Sebenarnya ini bisa dilakukan hanya dengan properti css, tetapi masalahnya kita semua sudah diajari bahwa itu cara yang salah, dan daftar string berisi banyak utility juga lebih mudah daripada memakai objek CSS murni
    • Pembatasan mengurangi kompleksitas yang mungkin terjadi, dan karena itu Tailwind menang
      Ini adalah wrapper modular yang dapat dikomposisi dan terstandardisasi di atas sistem yang besar dan kompleks, jadi merupakan kemajuan besar
    • Saya sedang belajar matematika bersama anak, dan caranya tidak berbeda dari yang saya pelajari; saya masih bisa menyelesaikannya dengan cepat
      Sebaliknya, di media sosial ada posting yang mencampur perkalian dan pembagian lalu mengatakan hanya ada satu jawaban benar. Tailwind tidak seburuk itu, tetapi dari sudut pandang orang tua, arahnya tampak lebih dekat ke sana

  • Saya suka Tailwind. Selama 4 tahun terakhir saya memakainya di 3 proyek, dan terasa intuitif, dokumentasinya bagus, serta sederhana
    Saya tidak merindukan masa emotion dan styled-components ketika setiap div yang diberi style di proyek harus diberi nama
    Di Tailwind, container hanyalah div dengan beberapa class. Perdebatan soal penamaan berkurang, begitu juga tenaga pikiran dan waktu review yang dipakai untuk memberi nama

    • Saya sering melihat masalah bahwa setiap styled div harus dipikirkan namanya, dan itu agak membuat saya heran
      Rasanya hampir tidak pernah saya memikirkan penamaan sesuatu lebih dari 1 detik. Apakah ini benar-benar titik buntu bagi sebagian orang? Saya penasaran apakah orang benar-benar sampai lumpuh di bagian itu
    • Kalau menyebutnya “beberapa class”, sepertinya Anda bekerja dengan product owner yang sangat baik
      Orang-orang yang saya temui biasanya menentukan setiap detail yang mungkin tanpa henti. Mereka memperlakukan form web seperti proyek renovasi HGTV pribadi
      Saat saya mencoba Tailwind sekali, jumlah class menjadi satu orde magnitudo lebih banyak daripada markup, dan cepat sekali sulit dibaca
    • Saya sudah mencobanya di beberapa proyek, tetapi tidak suka. Di proyek besar, ini cepat menjadi berantakan, dan terasa seperti Bootstrap baru
      Sekarang saya puas dengan workflow CSS-in-JS. Caranya menulis CSS gaya lama dengan bantuan LLM. Tunjukkan gambar ke LLM dan minta komponen, maka hasilnya langsung keluar dengan nama yang juga masuk akal
    • Jika bisa memilih, ini salah satu alasan utama saya menghindari React
      Styling di React kurang bagus, dan bahkan kalau memakai Tailwind, itu hanya opsi yang sedikit tidak terlalu buruk
      Kalau memakai framework frontend dan tahap build, Svelte dan Astro bagus tergantung kebutuhan. Keduanya bisa diberi style dengan CSS biasa, dan jika komponen dijaga tetap kecil, hampir tidak perlu memakai nama class
      Cukup gunakan selector elemen dan biarkan framework melakukan scoping style saat build

  • Saya mencoba Tailwind di situs saya dan cukup menyukainya, meski mungkin alasannya agak berbeda dari yang sering disebut
    Nilai sebenarnya dari Tailwind adalah semua style yang memengaruhi satu elemen bisa dibaca di satu tempat
    Nama class memang bisa menjadi panjang, tetapi membaca satu baris panjang jauh lebih cepat daripada setiap kali membuka developer tools browser atau bolak-balik naik turun di satu atau lebih stylesheet
    Ketika nanti kembali ke kode itu, saya bisa mengubahnya dengan percaya diri tanpa khawatir mengubah elemen lain tanpa sengaja
    Sifat cascading CSS masih berguna, tetapi biasanya saya ingin membatasi style hanya pada satu elemen. Untuk hal lain saya kembali ke CSS, tetapi CSS yang benar-benar saya tulis sangat sedikit. Biasanya karena saya hanya ingin menyesuaikan spacing

    • Justru itulah alasan Tailwind terasa bagus dan nyaman
      Saya juga suka bahwa “bagaimana cara melakukan X?” tidak menjadi riset 30 menit, melainkan selesai dengan pencarian dokumentasi singkat
    • Alat yang menampilkan semua style yang diterapkan ke suatu elemen juga ada di IDE. Misalnya “Show Applied Styles for Tag” di Intellij atau Chrome developer tools juga menampilkannya dengan enak dibaca
      Potongan Tailwind yang muncul di tulisan HN ini terlihat cukup menakutkan dibandingkan itu
    • Saya cukup setuju, tetapi masalah yang sama tetap ada
      Jika Anda menambahkan text-xl ke div dan di dalamnya ada div serta span bersarang, semuanya mewarisi text-xl, jadi untuk melihat apa yang menyebabkan text-xl pada elemen bersarang, pada akhirnya Anda tetap harus menelusuri naik hierarki elemen
      Meski begitu, secara keseluruhan memang sedikit lebih mudah

  • Frasa seperti “waktu build lebih singkat”, “tidak ada lagi direktif @tailwind”, “tanpa konfigurasi JavaScript”, dan “dirancang untuk web modern” terdengar seperti ini
    CSS sekarang bisa melakukan semua hal yang dulu kita lakukan sendiri, tetapi rasanya kita tetap berpura-pura bahwa kita masih dibutuhkan

    • Kalau mau membencinya, setidaknya cobalah memahami apa itu dan mengapa orang memakainya
    • Nilai jual Tailwind sejak awal adalah “hampir seperti CSS inline, tetapi tidak seribet atribut style dan jauh lebih mudah dioptimalkan”
    • Saya penasaran, dulu apa yang tidak bisa dilakukan dengan CSS biasa sehingga Tailwind dibutuhkan?
      Bukankah Tailwind hampir berpadanan 1:1 dengan CSS?
    • Saya ragu apakah memang benar begitu cara memahaminya
      Saya paham kalau tidak suka Tailwind, tetapi menurut saya lebih baik mengatakan bagian mana dari Tailwind yang tidak disukai daripada menyerang straw man
      Menjelek-jelekkan proyek open source orang lain dan orang-orang yang menggunakannya dengan berguna juga bukan hal yang baik

  • Saya ingin bertanya kepada orang-orang yang paham CSS. Saya sendiri tidak begitu paham
    Saya sedang memutakhirkan proyek Phoenix pribadi ke 1.7, dan karena Phoenix sekarang memakai Tailwind secara default, saya mencoba memakainya alih-alih Bootstrap
    Sejauh ini versi Bootstrap terlihat “cukup oke”, sedangkan versi Tailwind terlihat berantakan
    Apa cara termudah untuk mendapatkan default yang terlihat lumayan tanpa harus mencoba menjadi desainer? Atau sebaiknya saya cukup memasang Bootstrap lagi dan selesai?

    • Dalam kasus itu, saya akan memasang Bootstrap lagi
      Tailwind memberi alat ketika Anda ingin mengontrol desain, tetapi pada akhirnya Anda memang harus mengontrol desain sendiri
      Kalau Anda hanya ingin sesuatu yang terlihat bagus dan bernuansa Bootstrap, maka Bootstrap adalah pilihan yang tepat
      Secara teori ada proyek-proyek yang mengimplementasikan ulang Bootstrap di atas Tailwind, sehingga bisa memberi titik awal seperti Bootstrap sekaligus kekuatan Tailwind, tetapi dalam praktiknya saya belum melihat yang bekerja lebih baik daripada sekadar memakai Bootstrap
    • Untuk tujuan itu saya memakai DaisyUI. Situs demo contohnya ada di sini: https://nwk-landing-kit.netlify.app
      Dokumentasi DaisyUI ada di sini: https://daisyui.com
    • Kalau mencari komponen seperti Bootstrap, https://flowbite.com/ layak dicoba secara gratis
      Tailwind juga punya komponen berbayar, dan Anda tinggal menyalin-tempel. Hal yang bagus adalah setelah terbiasa, Anda bisa mulai mengubah komponen Flowbite sedikit demi sedikit
    • Tergantung siapa yang membayar
      Kalau punya keamanan kerja dan ingin mengutak-atik berbagai hal, silakan bermain-main dengan Tailwind. Orang-orang yang peka tren dan bersuara lantang tampaknya umumnya menyukai Tailwind
      Namun jika itu proyek sendiri, didanai sendiri, atau ada tenggat, lebih baik memakai Bootstrap yang sudah Anda kenal dan fokus menyelesaikan pekerjaan daripada berperang habis-habisan soal UI
    • Membandingkan Tailwind dan Bootstrap lebih seperti membandingkan apel dengan pai apel
      Tailwind menyediakan kelas-kelas yang perlu disusun untuk membuat komponen
      Akan lebih mudah jika dipakai bersama sumber komponen UI. Saya pernah memakai TailwindUI, tetapi itu berbayar, dan sepertinya ada alternatif gratis yang bagus juga

  • Dalam percakapan “Tailwind atau bukan”, ada pola yang jelas. Ini berulang setiap kali Tailwind disebut
    Ada orang-orang yang belum pernah benar-benar memakainya lebih dari 30 menit, hanya mencoba sebentar atau sekadar melihat dokumentasinya. Mereka tidak menyukai Tailwind dan lebih menyukai hal seperti “CSS murni”
    Sebaliknya ada orang-orang yang pernah memakainya dalam proyek nyata, di dalam tim yang beranggotakan lebih dari satu orang. Mereka memahami nilainya, menerima trade-off-nya, dan menyukainya
    Saya sering melihat orang berpindah dari kelompok pertama ke kelompok kedua, tetapi hampir tidak pernah melihat orang kembali dari kelompok kedua ke kelompok pertama
    Itulah sebabnya Tailwind berhasil. Di mata kaum puris mungkin tidak indah, tetapi di mata pembuat dan kaum pragmatis, ini benar-benar hebat

    • Saya rasa saya tidak benar-benar cocok dengan salah satu dari dua kelompok itu
      Saya tidak menentang Tailwind, tetapi alasan saya belum mencobanya adalah karena saya belum melihat dengan jelas mengapa pendekatan ini lebih baik daripada pilihan lain seperti Web Components atau React Styled Components
      Masalah terbesar adalah Tailwind membuat HTML berantakan dengan sangat banyak utility class, sehingga sulit dibaca dan dipelihara
      Saya paham itu lebih baik daripada file CSS global yang besar dan CSS klasik berbasis nama tag, tetapi sudah ada cara untuk memakai CSS yang di-scope ke komponen tanpa mencemari namespace global. Web Components dan Styled Components adalah contohnya
      Keduanya mengikat style langsung ke komponen, atau lebih umum lagi ke kumpulan tag HTML tertentu, sehingga lebih mudah melihat style mana diterapkan di mana
      Tidak perlu nama class global, dan kekhawatiran tentang efek samping atau konflik yang tidak diinginkan juga berkurang. Jika komponen dihapus, style terkait ikut terhapus, sehingga tidak perlu khawatir CSS yang tidak terpakai tertinggal. Berkat shadow DOM, risiko style satu komponen secara tidak sengaja memengaruhi komponen lain juga tidak ada
      Saya menganggap penting menjaga HTML tetap singkat dan mudah dibaca, tanpa mencampur style presentasional langsung ke markup. Jika semua style masuk ke atribut class seperti Tailwind, akan muncul daftar class panjang dalam satu baris, dan jika harus menambahkan nama class asli juga, HTML menjadi berantakan
      Sulit memahami sekilas style apa yang diterapkan, dan sulit juga melakukan indentasi dengan benar. Ini mengingatkan saya pada berbagai alasan mengapa dulu kita beralih dari atribut style inline di HTML
      Saya tidak membenci Tailwind, tetapi dari sisi keterbacaan, kemudahan pemeliharaan, dan pemisahan concern, saya belum melihat keunggulan yang jelas dibanding Web Components atau Styled Components, dan kekhawatiran saya yang belum terjawab masih besar
      Saya sudah membaca dokumentasinya tetapi belum mencobanya, dan sulit memahami mengapa harus memilih Tailwind alih-alih pilihan lain. Banyaknya class di tengah HTML biasa membuat keduanya sama-sama sulit dibaca bagi saya

  • Saya mengakui ada orang-orang yang menggunakan Tailwind dengan berguna dan produktif, tetapi karena sekarang Tailwind ada di mana-mana, tampilan yang rapi tetapi umum terlihat di banyak tempat

    • Ini adalah kebingungan antara Tailwind dan TailwindUI/shadcn
      Pada umumnya, Tailwind tidak lebih banyak memengaruhi gaya dibanding CSS biasa. Ada sedikit pengecualian. Hal-hal seperti shadow memang sedikit lebih terstandardisasi, dan palet warna indigo belakangan juga cukup memengaruhi pihak luar
    • Tailwind memberikan default yang masuk akal, tetapi tidak banyak memengaruhi desain
      Orang-orang hanya cenderung mendesain situs dengan cara tertentu. Terutama saat menggunakannya bersama ShadCn
    • Justru terasa seperti hal yang baik. Pilihan-pilihan Tailwind dirancang dengan baik dan berfungsi baik
      Saya melihatnya mirip dengan Inter yang dipakai sebagai Helvetica baru untuk font situs web. Kalau banyak orang memakainya dan terlihat bagus, rasanya tidak ada alasan khusus untuk tidak menggunakannya
    • Dulu saya juga mendengar hal semacam ini tentang Bootstrap, tetapi situs-situs Bootstrap yang saya buat tidak mirip satu sama lain
      Bootstrap sudah menyediakan banyak utility class jauh sebelum Tailwind, sehingga banyak menghemat waktu, dan tidak memaksakan tampilan tertentu
      Tinggal memuat class yang diinginkan. Tentu ceritanya berbeda jika Anda tidak mengunduh file sumber Sass, tetapi itu pasti pilihan yang bodoh
    • Pandangan saya tentang masalah ini adalah bahwa framework UI yang bagus, yaitu kombinasi Tailwind dan komponen, masih jarang
      Karena itu, sebagian besar proyek memakai segelintir framework saja. Jika muncul 4–5 proyek UI berkualitas tinggi lagi, terutama dengan arah gaya yang lebih berbeda, keragaman akan bertambah
      Seperti banyak pekerjaan kreatif lainnya, desain pun tampaknya arahnya ditentukan oleh jumlah orang yang mengejutkan sedikit
      Saya berharap lebih banyak orang mengetahui hal ini. Mungkin ada orang-orang berbakat yang tidak membuat sesuatu karena berpikir “kalaupun saya membuatnya, tidak ada yang akan mendengarkan”
      Namun jika sebagian dari mereka mencoba, saya rasa mereka bisa membuka UI baru untuk bagian besar web

  • Tailwind adalah bukti yang menunjukkan kelebihan inline style, yaitu cara menata gaya sesuatu tanpa memberinya nama, universalitas string, sekaligus keterbatasan string
    Saya menantikan apa yang akan datang berikutnya, dan sampai saat itu saya akan memakai Tailwind dengan setengah hati