Kenapa shadcn/ui Menggusur Library Web Tradisional?

Dunia pengembangan antarmuka web selama bertahun-tahun didominasi oleh library seperti Bootstrap, Material UI, Ant Design, dan Chakra UI. Library tersebut menawarkan komponen siap pakai yang dapat digunakan hanya dengan memasang paket, mengimpor komponen, lalu menempatkannya di dalam aplikasi.

Pendekatan tersebut sangat membantu ketika developer ingin membangun aplikasi dengan cepat. Namun, masalah biasanya mulai muncul ketika desain produk berkembang menjadi lebih spesifik. Developer harus menimpa CSS bawaan, mempelajari sistem tema library, membuat komponen pembungkus, atau mencari jalan keluar dari API yang terlalu membatasi.

Di tengah persoalan itulah shadcn/ui memperoleh perhatian besar. Ia menawarkan tombol, dialog, formulir, tabel, dan berbagai komponen siap pakai, tetapi menggunakan model distribusi yang berbeda. Kode komponen ditempatkan langsung ke dalam proyek sehingga dapat dibaca, diubah, dan dimiliki oleh developer.

Karena itu, menyebut shadcn/ui sekadar sebagai “library komponen baru” sebenarnya kurang tepat. Dokumentasi resminya bahkan menegaskan bahwa shadcn/ui bukanlah component library tradisional, melainkan cara untuk membangun component library milik kita sendiri.

Masalah yang Dibawa Library UI Tradisional

Developer hanya menjadi konsumen komponen

Pada library tradisional, kode utama komponen berada di dalam paket NPM. Aplikasi hanya mengimpor dan menggunakan API yang disediakan library tersebut.

import Button from "@mui/material/Button";

export default function SaveButton() {
  return <Button variant="contained">Simpan</Button>;
}

Model ini memiliki beberapa keuntungan. Proses instalasinya sederhana, perilaku komponen relatif konsisten, dan pembaruan bisa diperoleh dengan menaikkan versi paket. Untuk aplikasi yang ingin mengikuti bahasa desain tertentu, solusi seperti Material UI juga sangat produktif.

Kelemahannya, developer tidak sepenuhnya menguasai implementasi internal komponen. Ketika kebutuhan produk tidak sesuai dengan API yang tersedia, developer harus bekerja melalui mekanisme ekstensi yang disediakan library.

Kustomisasi dapat berubah menjadi pertarungan melawan abstraksi

Library modern sebenarnya tidak sepenuhnya kaku. Material UI, misalnya, menyediakan sx, styled(), ThemeProvider, serta styleOverrides. Jadi, anggapan bahwa library tradisional sama sekali tidak dapat dikustomisasi merupakan informasi yang keliru.

Persoalannya adalah tingkat kustomisasi tersebut tetap mengikuti abstraksi milik library. Developer harus memahami struktur slot, sistem tema, spesifisitas CSS, properti komponen, serta aturan internal lainnya. Dokumentasi Material UI bahkan membedakan mekanisme kustomisasi berdasarkan cakupannya, mulai dari perubahan satu komponen hingga global theme override.

Untuk perubahan ringan, sistem ini sangat efektif. Namun, ketika desain produk berbeda jauh dari desain bawaan, developer bisa menghabiskan banyak waktu untuk menyesuaikan library alih-alih membangun komponen sesuai kebutuhan.

Ketergantungan terhadap keputusan pihak ketiga

Komponen yang berasal dari paket eksternal mengikuti siklus hidup paket tersebut. Perubahan API, penghentian dukungan fitur, pembaruan peer dependency, atau major release dapat memengaruhi aplikasi.

Hal ini tidak berarti dependency selalu buruk. Dependency justru menghemat banyak waktu dan memungkinkan perbaikan didistribusikan secara terpusat. Akan tetapi, semakin besar abstraksi yang dimiliki dependency, semakin besar pula pengaruh keputusan maintainernya terhadap aplikasi pengguna.

shadcn/ui Mengubah Cara Komponen Didistribusikan

Bukan paket komponen yang tinggal di node_modules

shadcn/ui mendeskripsikan dirinya sebagai kumpulan komponen yang dirancang dengan baik, mudah diakses, dan didistribusikan melalui sebuah platform kode. Prinsip utamanya adalah open code: lapisan atas komponen tersedia sebagai kode yang dapat dimodifikasi.

Ketika developer menambahkan sebuah komponen melalui CLI, berkas komponen tersebut disalin ke proyek. Hasil sederhananya kurang lebih seperti berikut:

src/
└── components/
    └── ui/
        ├── button.tsx
        ├── dialog.tsx
        └── input.tsx

Setelah berkas berada di dalam proyek, developer tidak hanya menggunakan komponen tersebut. Developer memiliki implementasinya dan dapat mengubah struktur JSX, class, variant, perilaku, ataupun API-nya.

Inilah perbedaan mendasarnya:

• Pada library tradisional, proyek menggunakan implementasi milik library.
• Pada shadcn/ui, proyek menerima kode awal untuk dijadikan implementasi milik sendiri.

Model tersebut menyerupai proses menyalin kode, tetapi dilakukan secara terstruktur melalui CLI dan registry. Registry dapat mendistribusikan komponen, hook, utility, konfigurasi, halaman, bahkan aturan pengembangan.

Memberikan abstraksi awal tanpa mengunci developer

Membangun semua komponen dari nol memang memberikan kontrol penuh, tetapi membutuhkan biaya besar. Developer harus memikirkan keyboard navigation, focus management, state, struktur semantik, responsivitas, styling, dan berbagai edge case.

Sebaliknya, library yang sangat abstrak dapat mempercepat pengembangan awal tetapi membatasi perubahan mendalam.

shadcn/ui mengambil posisi di antara keduanya. Developer memperoleh implementasi awal yang sudah dapat digunakan, kemudian bebas membentuknya menjadi bagian dari design system aplikasi.

Pendekatan ini dapat diringkas sebagai berikut:

Komponen siap pakai + akses terhadap source code + kebebasan modifikasi

Dengan demikian, developer tidak selalu harus memilih antara “membangun semuanya sendiri” dan “mengikuti seluruh aturan library”.

Mengapa Pendekatan Ini Disukai Developer?

Kode komponen dapat dibaca secara langsung

Transparansi merupakan salah satu kekuatan utama shadcn/ui. Jika sebuah dialog berperilaku tidak sesuai harapan, developer dapat membuka berkas dialog dan memeriksa implementasinya.

Hal ini memberikan beberapa keuntungan:

• Proses debugging menjadi lebih langsung.
• Tidak perlu menelusuri abstraksi yang terlalu jauh ke dalam node_modules.
• Komponen dapat disesuaikan untuk kebutuhan domain aplikasi.
• Tim dapat menetapkan standar internalnya sendiri.
• Tidak ada API publik eksternal yang harus selalu dipertahankan di dalam proyek sendiri.

Bagi software engineer pemula, sifat terbuka ini juga menawarkan nilai edukasi. Komponen bukan lagi kotak hitam. Developer dapat mempelajari bagaimana variant, utility class, composition, dan primitive aksesibilitas digabungkan menjadi komponen tingkat aplikasi.

Kustomisasi dilakukan pada sumber masalahnya

Pada pendekatan tradisional, perubahan visual sering dilakukan melalui override. Pada shadcn/ui, perubahan dapat dilakukan langsung pada class atau struktur komponen.

Sebagai contoh, sebuah tim dapat mengubah tombol agar selalu menggunakan aturan loading internal:

interface ButtonProps {
  loading?: boolean;
  children: React.ReactNode;
}

export function Button({ loading, children }: ButtonProps) {
  return (
    <button disabled={loading}>
      {loading ? "Memproses..." : children}
    </button>
  );
}

Developer tidak harus menunggu library upstream menyediakan properti yang sesuai. Komponen dapat dikembangkan mengikuti kebutuhan produk.

Namun, kebebasan tersebut membawa konsekuensi: setelah komponen dimodifikasi, tim bertanggung jawab merawat perubahan tersebut.

Styling lebih dekat dengan struktur komponen

shadcn/ui menggunakan sistem token tema dan utility class. Dokumentasinya merekomendasikan CSS variables dengan nama semantik seperti background, foreground, primary, dan primary-foreground.

:root {
  --primary: oklch(0.205 0 0);
  --primary-foreground: oklch(0.985 0 0);
}

Komponen kemudian menggunakan token tersebut melalui class semantik:

<button className="bg-primary text-primary-foreground">
  Simpan
</button>

Dengan pendekatan ini, perubahan identitas visual dapat dilakukan pada token global, sedangkan perubahan khusus dapat dilakukan langsung pada komponen.

Penting untuk dicatat bahwa konsep token dan theming bukan milik eksklusif shadcn/ui. Material UI dan library modern lain juga mempunyai sistem tema yang matang. Keunggulan khusus shadcn/ui terletak pada kombinasi antara token desain dan kepemilikan source code komponen.

Fondasi aksesibilitas tidak harus dibangun dari nol

shadcn/ui menggunakan primitive component untuk menangani berbagai interaksi kompleks. Pada perkembangan terbarunya, CLI resminya menyediakan pilihan fondasi seperti Base UI, Radix, dan React Aria, bergantung pada konfigurasi yang dipilih. Untuk proyek baru pada dokumentasi edisi Juli 2026, Base UI menjadi pilihan default, sementara Radix tetap didukung.

Primitive tersebut membantu menangani aspek seperti:

• navigasi menggunakan keyboard;
• pengelolaan fokus;
• atribut ARIA;
• perilaku membuka dan menutup komponen;
• interaksi pada dialog, popover, menu, dan komponen kompleks lainnya.

Meskipun demikian, menggunakan shadcn/ui tidak membuat aplikasi otomatis sepenuhnya aksesibel. Developer tetap harus memberikan label yang benar, menjaga kontras warna, menggunakan struktur semantik, menguji navigasi keyboard, serta memeriksa kembali aksesibilitas setelah memodifikasi komponen.

Cocok dengan pengembangan berbantuan AI

Dokumentasi shadcn/ui menyebut AI-ready sebagai salah satu prinsipnya. Klaim ini cukup masuk akal karena source code komponen berada di dalam proyek. AI coding assistant dapat membaca implementasi yang sebenarnya, memahami konvensinya, lalu mengusulkan perubahan langsung pada berkas terkait.

Pada dependency tradisional, konteks implementasi sering berada di luar source tree utama. AI mungkin mengetahui API library, tetapi belum tentu melihat keseluruhan implementasi internal atau penyesuaian yang dibutuhkan proyek.

Open code membuat alur kerja seperti berikut menjadi lebih alami:

1. Developer menambahkan komponen dari registry.
2. AI membaca source code komponen.
3. Developer menjelaskan perubahan yang diinginkan.
4. AI menyesuaikan struktur, style, dan perilakunya.
5. Hasil perubahan tetap menjadi bagian dari codebase proyek.

Popularitas AI coding turut membuat model distribusi berbasis source code semakin relevan.

Registry: Evolusi dari Copy-Paste Biasa

Komponen dapat didistribusikan secara terstruktur

Jika shadcn/ui hanya menyediakan potongan kode untuk disalin manual, konsistensi instalasinya akan sulit dijaga. Karena itu, shadcn/ui menyediakan registry dan CLI.

Sebuah registry item dapat mendeklarasikan:

• berkas yang harus ditambahkan;
• dependency NPM yang dibutuhkan;
• ketergantungan terhadap item registry lain;
• CSS variables;
• konfigurasi tema;
• dokumentasi;
• environment variable tertentu.

CLI kemudian menyelesaikan dependency tersebut dan menempatkan berkas sesuai konfigurasi proyek. Artinya, shadcn/ui bukan sekadar situs koleksi snippet. Ia merupakan protokol dan perkakas distribusi kode.

Tim dapat membuat registry internal

Perusahaan dapat membangun registry privat berisi komponen yang mengikuti design system mereka sendiri. Sebagai contoh, registry internal dapat menyediakan:

• tombol dengan standar merek perusahaan;
• formulir yang terhubung ke mekanisme validasi tim;
• tabel dengan aturan pagination internal;
• komponen autentikasi;
• layout dashboard;
• konfigurasi tema;
• hook dan utility bersama.

Dengan begitu, shadcn/ui dapat bertindak sebagai fondasi untuk membangun platform UI internal, bukan sekadar kumpulan komponen publik.

Ekosistem tidak lagi bergantung pada satu katalog

Registry bernamespace memungkinkan developer mengambil komponen dari sumber yang berbeda. Secara konseptual, tim dapat menggunakan komponen resmi, registry komunitas, dan registry internal dalam proyek yang sama.

Fleksibilitas ini memperluas ekosistem, tetapi juga menciptakan risiko supply chain. Dokumentasi resmi mengingatkan bahwa registry komunitas dikelola pihak ketiga sehingga kode harus diperiksa sebelum dipasang.

Karena source code masuk langsung ke proyek, proses review menjadi sangat penting. Developer perlu memeriksa dependency, request jaringan, environment variable, dan berkas yang akan ditambahkan.

Apakah shadcn/ui Benar-Benar Lebih Ringan?

Jawabannya tidak selalu.

Karena hanya komponen yang dipilih yang ditambahkan, developer dapat menghindari pemasangan katalog UI besar secara keseluruhan. Namun, ukuran bundle akhir tetap dipengaruhi oleh primitive, icon library, utility, dependency tambahan, serta cara bundler melakukan tree-shaking.

Sementara itu, library tradisional modern juga umumnya mendukung impor modular dan tree-shaking. Oleh sebab itu, pernyataan bahwa shadcn/ui pasti menghasilkan bundle lebih kecil daripada semua library tradisional tidak dapat dibenarkan tanpa mengukur aplikasi yang nyata.

Keuntungan yang lebih tepat adalah kontrol terhadap kode dan dependency yang digunakan, bukan jaminan otomatis mengenai ukuran bundle.

Harga yang Harus Dibayar untuk Kebebasan

Pembaruan tidak selalu dapat diterapkan secara otomatis

Pada library tradisional, bug fix biasanya diperoleh dengan memperbarui versi paket. Walaupun major upgrade bisa menimbulkan breaking change, kode implementasi tetap dirawat secara terpusat oleh maintainer.

Dalam pendekatan open code, komponen yang telah disalin dapat berkembang berbeda dari versi upstream. Semakin banyak modifikasi lokal, semakin sulit memasukkan pembaruan baru secara otomatis.

Konsekuensinya, tim harus:

• memantau perubahan penting dari upstream;
• meninjau ulang komponen ketika ditemukan masalah keamanan;
• membandingkan implementasi lokal dengan versi terbaru;
• menguji komponen yang sudah dimodifikasi;
• mendokumentasikan penyimpangan dari komponen awal.

Dengan kata lain, shadcn/ui menukar kemudahan pembaruan terpusat dengan kontrol penuh terhadap implementasi.

Konsistensi bergantung pada disiplin tim

Kepemilikan source code berarti setiap developer dapat mengubah komponen. Tanpa aturan yang jelas, variasi tombol, input, dialog, dan token desain dapat berkembang secara tidak terkendali.

Tim sebaiknya menetapkan batas antara:

• komponen primitive;
• komponen UI umum;
• komponen domain;
• komponen khusus halaman.

Code review, dokumentasi, visual regression test, dan design token menjadi semakin penting. Fleksibilitas tanpa tata kelola hanya akan memindahkan masalah dari vendor lock-in menjadi kekacauan internal.

Tidak selalu ideal untuk semua proyek

shadcn/ui sangat menarik bagi tim yang membutuhkan desain khusus dan mempunyai kemampuan untuk memelihara komponen. Namun, library tradisional dapat menjadi pilihan lebih rasional ketika:

• aplikasi harus dibuat dalam waktu sangat singkat;
• tampilan bawaan library sudah sesuai;
• tim tidak memiliki resource untuk memelihara design system;
• produk membutuhkan banyak komponen enterprise yang kompleks;
• konsistensi lebih penting daripada kebebasan implementasi;
• aplikasi ingin memperoleh pembaruan komponen secara terpusat.

Admin panel internal, prototipe, dan aplikasi berstandar desain umum sering kali tidak membutuhkan kontrol sedalam yang ditawarkan shadcn/ui.

shadcn/ui Tidak Menghapus Library Tradisional—Ia Mengubah Standar Pilihan

Istilah “menggusur” sebaiknya tidak dimaknai bahwa shadcn/ui telah membuat Bootstrap, Material UI, Ant Design, atau Chakra UI tidak relevan. Tidak ada satu pendekatan yang selalu unggul untuk semua proyek.

Yang benar-benar digeser adalah ekspektasi developer. Komponen siap pakai kini tidak harus berarti kode tertutup di balik dependency. Developer mulai menginginkan kecepatan implementasi sekaligus kepemilikan source code, kemudahan kustomisasi, dukungan design token, aksesibilitas, dan kompatibilitas dengan workflow berbantuan AI.

Aspek	shadcn/ui	Library UI tradisional
Model distribusi	Source code ditambahkan ke proyek melalui CLI atau registry	Komponen umumnya digunakan dari paket NPM
Kepemilikan kode	Tim memiliki dan dapat mengubah lapisan komponen	Implementasi utama dimiliki serta dirawat oleh library
Kustomisasi	Dapat mengubah struktur, style, perilaku, dan API secara langsung	Menggunakan props, theme, slot, override, atau wrapper
Pembaruan	Perlu meninjau dan menggabungkan perubahan upstream, terutama setelah modifikasi lokal	Umumnya melalui pembaruan versi paket
Konsistensi	Sangat bergantung pada aturan dan disiplin tim	Lebih banyak konsistensi disediakan oleh library
Kecepatan awal	Cepat, tetapi membutuhkan konfigurasi dan pemahaman struktur kode	Biasanya sangat cepat dengan komponen siap impor
Desain khusus	Sangat fleksibel	Bisa fleksibel, tetapi tetap mengikuti extension point library
Aksesibilitas	Dibantu oleh primitive; tetap harus diuji setelah modifikasi	Banyak komponen sudah ditangani library; tetap harus diuji dalam konteks aplikasi
Integrasi AI	Kuat karena kode komponen tersedia di dalam proyek	AI lebih banyak bekerja melalui API dan mekanisme ekstensi library
Beban pemeliharaan	Lebih besar pada tim pengguna	Lebih banyak ditanggung maintainer library
Risiko utama	Fragmentasi kode, tertinggal dari upstream, dan kualitas modifikasi lokal	Vendor lock-in, upgrade paket, serta kompleksitas override
Cocok untuk	Produk dengan identitas visual khusus dan tim yang siap merawat design system	Prototipe, aplikasi internal, atau proyek yang mengutamakan standardisasi cepat

Pada akhirnya, kekuatan shadcn/ui bukan terletak pada bentuk tombol atau pilihan warnanya. Kekuatan utamanya adalah perubahan hubungan antara developer dan komponen UI: dari sekadar konsumen menjadi pemilik kode.

Itulah alasan shadcn/ui terasa seperti sedang menggusur library web tradisional. Ia tidak hanya menawarkan katalog komponen yang berbeda, tetapi juga menawarkan filosofi pengembangan yang berbeda—mulai dari komponen yang matang, distribusikan sebagai kode, lalu berikan kendali terakhir kepada tim yang membangun produknya.

Referensi

• Dokumentasi resmi: Introduction to shadcn/ui
• Dokumentasi resmi: shadcn CLI
• Dokumentasi resmi: components.json
• Dokumentasi resmi: Theming
• Dokumentasi resmi: Registry
• Dokumentasi resmi: Registry Directory
• Dokumentasi resmi: Base UI sebagai pilihan default
• Material UI: How to customize
• Material UI: Themed components