Kompleksitas Berlebihan pada Tombol Radio Shadcn

(paulmakeswebsites.com)

2 poin oleh GN⁺ 2026-01-21 | 4 komentar | Bagikan ke WhatsApp

Meskipun tombol radio yang sudah bawaan di browser web hanyalah elemen HTML sederhana, di pustaka UI Shadcn elemen ini dibangun ulang menjadi beberapa lapisan komponen React
<RadioGroup> dan <RadioGroupItem> milik Shadcn kembali membungkus komponen dari Radix UI, serta memakai ikon lucide-react dan puluhan kelas Tailwind
Radix memanfaatkan atribut ARIA untuk aksesibilitas dan kustomisasi, tetapi dalam praktiknya justru mendaur ulang elemen tombol alih-alih memakai <input type="radio"> bawaan
Walau styling yang sama bisa dicapai dengan CSS sederhana, struktur ini menambahkan ratusan baris kode dan beberapa dependensi sehingga memicu kompleksitas yang tidak perlu
Karena tidak memanfaatkan kembali elemen HTML bawaan, pendekatan ini memperbesar penurunan performa dan beban pemeliharaan, serta merusak kesederhanaan pengembangan web

Analisis Struktur Tombol Radio Shadcn

Shadcn mengimplementasikan tombol radio melalui dua komponen: <RadioGroup> dan <RadioGroupItem>
- Masing-masing komponen membungkus primitive dari @radix-ui/react-radio-group, dan memakai CircleIcon dari lucide-react
- Terdapat lebih dari 45 baris kode dan 3 import eksternal, dengan styling menggunakan lebih dari 30 kelas Tailwind
Untuk menampilkan lingkaran sederhana, struktur ini memuat pustaka ikon SVG
- Padahal fungsi ini bisa digantikan dengan border-radius di CSS atau elemen <circle>

Peran Radix UI

Radix yang dipakai Shadcn adalah pustaka komponen UI level rendah yang berfokus pada aksesibilitas dan kustomisasi
- Implementasi radio group di Radix terdiri dari sekitar 215 baris kode React dan mengimpor 7 file
Radix menambahkan atribut ARIA pada elemen <button> agar berperilaku seperti tombol radio
- Namun prinsip pertama penggunaan ARIA menurut W3C menyatakan “gunakan elemen HTML bawaan jika memungkinkan”
- Radix tidak mengikuti prinsip ini, dan mendaur ulang tombol alih-alih memakai <input>
Struktur yang hanya menambahkan <input type="radio"> tersembunyi di dalam <form> membuatnya kurang konsisten

Alternatif Sederhana dengan CSS

Tombol radio HTML bawaan bisa dengan mudah di-styling menggunakan appearance: none, ::before, :checked, border-radius, dan lain-lain
- Pada contoh kode, kustomisasi penuh dicapai tanpa dependensi, JavaScript, maupun atribut ARIA
- Efek yang sama juga bisa dibuat dengan Tailwind
Anggapan bahwa “styling tombol radio itu sulit” adalah masalah masa lalu; sekarang CSS murni sudah cukup untuk kontrol penuh

Masalah Akumulasi Kompleksitas

Saat Shadcn dan Radix dipakai bersama, pengembang harus memahami dua pustaka dan ratusan baris kode
- Untuk satu tombol radio sederhana saja, beberapa KB JavaScript ikut dimuat
- Pengguna harus menunggu parsing dan eksekusi JS hanya untuk menyalakan tombol
Struktur seperti ini berujung pada beban kognitif yang lebih tinggi, peluang bug yang lebih besar, dan penurunan performa web

Kembali ke Kesederhanaan

Browser sebenarnya sudah menyediakan tombol radio secara bawaan, dan satu baris <input type="radio" name="beverage" value="coffee" /> sudah cukup
Abstraksi yang tidak perlu dan penggunaan pustaka berlapis merusak kesederhanaan dan efisiensi asli pengembangan web
Bahkan untuk elemen UI kecil sekalipun, desain yang memanfaatkan kembali fungsi bawaan lebih menguntungkan untuk pemeliharaan maupun performa

4 komentar

crawler 2026-01-21

Membosankan dan sok akademis:

function RadioGroup({  
  className,  
  ...props  
}: React.ComponentProps<typeof RadioGroupPrimitive.Root>) {  
  return (  
    <RadioGroupPrimitive.Root  
      data-slot="radio-group"  
      className={cn("grid gap-3", className)}  
      {...props}  
    />  
  );  
}  
...

Cepat selesai, lama diingat:

<input type="radio" name="beverage" value="coffee" />

slowandsnow 2026-01-22

Kalau lihat komponen tombol di react aria, rasanya bisa pingsan wkwk

preserde 2026-01-21

Karena saya bekerja di bidang frontend, ini adalah masalah yang sudah lama saya alami; entah bagaimana, ini memang masalah yang sangat sulit diselesaikan. Implementasinya terus berubah seiring zaman, tetapi tidak menyelesaikannya dengan input type tetap sama di era mana pun...
Saya benar-benar tidak mengerti sebenarnya mau apa dengan mengimplementasikan sendiri spesifikasi terkait aksesibilitas hanya demi meniru perilaku tombol radio checkbox di browser web... Seperti yang tertulis di artikel, sekarang pun ada alternatif dengan CSS, jadi melihat mereka ngotot mati-matian ingin mengimplementasikannya sebagai komponen terasa agak lucu.

GN⁺ 2026-01-21

Opini Hacker News

Saya tidak terlalu sering mengerjakan frontend, tetapi sejak React mulai menjadi arus utama, tanda-tanda meningkatnya kompleksitas sudah terlihat
Lapisan abstraksi lain cenderung menyederhanakan, tetapi React justru menghasilkan abstraksi yang jauh lebih kompleks daripada teknologi dasarnya
Rasanya, para pengembang yang hanya mengenal React terus menumpuk lapisan yang makin tinggi dan akhirnya menghasilkan desain yang berlebihan
- Sekarang, menurut saya masalah yang lebih besar adalah suasana di mana semua orang menganggap React sebagai pilihan default
  Misalnya, Shadcn atau Radix adalah pustaka UI khusus React, tetapi dari kalimat pemasarannya terlihat seperti pustaka UI umum
- Saya sudah lebih dari 15 tahun membuat UI dengan JavaScript murni dan DOM API
  Saat skalanya membesar, pada akhirnya saya membuat framework sendiri atau merasa tidak puas dengan framework yang sudah ada, dan React menyelesaikan masalah itu sampai taraf tertentu
  Menurut saya, masalahnya bukan React itu sendiri, melainkan kompleksitas berlebihan dari ekosistemnya. Jika hanya memakai React dengan baik, itu masih menyenangkan untuk digunakan
- Ini bukan cuma masalah React; menurut saya masalah yang lebih besar adalah orang-orang tidak mau mempelajari CSS modern
  Mereka hanya mencoba menghindari CSS dengan alat seperti Tailwind. Saya mengelola state dengan React, tetapi untuk styling saya lebih suka langsung memakai CSS
  Hal tersulit adalah meyakinkan rekan satu tim agar mau belajar CSS
- Abstraksi pada dasarnya seharusnya menjadi alat filosofis untuk menyembunyikan kompleksitas, tetapi belakangan ini justru sering membuatnya makin rumit
  Saya menghindari framework yang “modern” seperti ini, dan sebisa mungkin lebih memilih teknologi dasar
- Inti React adalah abstraksi komponen
  React hanya menyediakan “kotak”, dan pengembanglah yang memutuskan apa yang dimasukkan ke dalamnya. Itulah kekuatan React yang sebenarnya
Contoh radio button ini lucu sekaligus mengesankan
Hasil akhirnya tidak bisa dibedakan dari radio button CSS dasar, jadi saya bertanya-tanya kenapa harus dibuat serumit ini
Saya penasaran apakah ada contoh situs berskala besar yang dibuat tanpa kompleksitas yang tidak perlu seperti ini
- Situs McMaster-Carr sering disebut sebagai contoh yang bagus. Ada juga thread Hacker News terkait
- Saya pernah membuat web app kolaborasi video 15 tahun lalu, dan frontend-nya hampir sepenuhnya berupa struktur vanilla berbasis jQuery
  Jumlah kodenya memang lebih banyak daripada sekarang, tetapi antarmukanya terasa sangat responsif secara instan
  Lihat kode proyek Takeoff
- “Kalau situs ini bagaimana?” — mungkin Hacker News sendiri adalah contoh seperti itu
- Semakin besar skala perusahaan, semakin para manajer menginginkan stack yang terstandarisasi
  Seperti ungkapan “tidak ada yang dipecat karena memilih React”, ini telah menjadi pilihan yang aman
- Karena UI bisa dilihat semua orang dan semua orang punya pendapat, kompleksitasnya tumbuh seperti tragedi kepemilikan bersama
Pengembang harus ingat bahwa mereka selalu bisa menentang persyaratan desain
Ada pengembang yang membuang 4 jam untuk masalah layout sederhana di React Native; ketika diminta bertanya “bolehkah desainnya sedikit diubah?”, masalahnya selesai dalam 10 menit
- Belakangan ini saya lebih menyukai framework UI tanpa JS (Pico.CSS, Skeleton, Bulma, Tailwind/daisyUI)
  Dengan CSS saja pun hasilnya bisa sangat baik. Saya penasaran dengan rekomendasi dari orang-orang yang pernah memakai pendekatan seperti ini
Kesalahan terbesar pada 2025 adalah memilih Shadcn
Saat melihat Radix terus di-import, saya merasakan peringatan pertama, dan ketika melihat komponen radio, saya mendapat peringatan kedua
Proyeknya sudah terlanjur berjalan, jadi saya menyerah dan memperbaikinya dengan Copilot, tetapi pada akhirnya saya juga tidak suka ketergantungan pada AI itu
POC sebelumnya jauh lebih sederhana dan efisien. Suatu hari saya ingin membangun semuanya ulang dengan HTML vanilla
- Kombinasi React+NextJS+Tailwind+Shadcn adalah bentuk puncak dari kompleksitas
  Remix atau React Router 7 setidaknya masih berusaha tetap lebih dekat dengan standar web
  Di Tailwind saya merasa “ini bukan buat saya”, dan kalau teman-teman bilang itu tetap bagus setelah refactor, mungkin nanti saya akan melihatnya lagi
- Sebenarnya Tailwind dan React tidak begitu cocok
  React punya styling berbasis props, jadi tidak ada alasan kuat untuk memakai tumpukan kelas CSS
  Jika yang diutamakan adalah aksesibilitas, memakai Radix UI saja sudah cukup
Masalahnya adalah elemen <input> di browser, terutama radio dan select, memang sulit dikustomisasi
Radio button bawaan kurang nyaman digunakan di perangkat mobile
- Sebenarnya kontrol native juga cukup bisa di-styling dengan CSS
  Saya ingin tahu lebih spesifik masalah apa yang ditemukan di mobile
- Artikel itu juga menjelaskan cara menghias radio button dengan CSS. Apakah itu masalahnya?
- Jika dibungkus dengan <label> dan diberi padding, itu sudah cukup layak dipakai di mobile
- Khusus “select” memang masih sulit di-styling, tetapi sisanya cukup fleksibel untuk dikustomisasi
Kebanyakan proyek dimulai dengan niat baik, tetapi tanpa terasa akhirnya penuh dengan kode radio button 200 baris dan 7 import
Dari situlah code rot dimulai
Saya baru-baru ini memakai daisyUI dan cukup menyukainya
Karena berbasis CSS murni, ia bisa memanfaatkan fitur browser baru (seperti dialog) dengan baik
- Tetapi dari sisi aksesibilitas, masih banyak kekurangan
  Misalnya, Drawer tidak bisa mengunci fokus, dan Accordion menyalahgunakan radio button sebagai pengganti JS
  Karena alasan seperti inilah pustaka seperti Radix mau tak mau menjadi kompleks
Saya setuju dengan inti artikelnya, tetapi jika ingin menerapkan gaya persis seperti yang dibuat desainer di Figma di semua browser, saya penasaran apakah itu bisa dilakukan dengan CSS vanilla
Apakah sesuatu seperti demo Radix bisa direplikasi sepenuhnya?
- Dengan sedikit penyesuaian, hasilnya bisa dibuat cukup mirip
  Lihat contoh CodePen
- Pada akhirnya, bahkan di bawah framework yang rumit itu, CSS tetaplah inti utamanya
  Cukup ekstrak CSS-nya lalu tempelkan ke komponen React sederhana
- Seperti contoh ini, jika menerapkan CSS yang sama pada input vanilla, kompatibilitas browser juga bagus
- Penulis aslinya sendiri muncul dan menjelaskan bahwa “contoh dasarnya hanya disesuaikan dengan gaya Shadcn, dan jika mau, semuanya bisa dikustomisasi sesuka hati”
- Tetapi tetap muncul pertanyaan: sejauh mana kita harus mengejar kesempurnaan?
  Apakah benar layak menambahkan puluhan KB kode dan beban pemeliharaan hanya demi menghindari sedikit ketidaksesuaian visual?
  Seperti kata Nam June Paik, “kalau terlalu sempurna, Tuhan akan marah”
Biaya yang sebenarnya bukanlah kode, melainkan waktu onboarding
Pengembang baru yang bergabung butuh berminggu-minggu untuk memahami radio button 47 baris berbasis Radix
Sementara pendekatan vanilla bisa dibuat dalam sehari dan dijelaskan dalam 20 menit
Tentu saja, untuk produk seperti Figma atau Linear di mana aksesibilitas dan navigasi keyboard sangat penting, kompleksitas itu bisa dibenarkan
- Muncul pertanyaan apakah pustaka yang baik seharusnya bisa dipakai tanpa harus memahami struktur internalnya
Banyak komentar mengkritik Shadcn, tetapi saya justru merasa ia mendorong struktur komponen dan reusabilitas dengan baik
Inti Shadcn adalah filosofi “miliki dan modifikasi sendiri komponennya”
Ini adalah pendekatan yang secara mendasar berbeda dari pustaka UI tradisional