Geçen sonbahar, Kadıköy’de küçük bir ürün ekibiyle otururken aynı tartışma yine açıldı: “Bu arayüz işini MUI ile mi çözelim, yoksa daha hafif bir şey mi kuralım?” Masada kahveler soğudu, konu uzadı gitti. Ben de o sırada şunu düşündüm: asıl mesele hangi kütüphaneyi seçtiğimiz değil, arayüzün ne kadarını gerçekten bizim kontrol ettigimizdi. Işin garip tarafı, shadcn/ui tam burada hem tuhaf hem de bayağı iş görüyor.
Şimdi açık konuşayım; shadcn/ui klasik anlamda “kur ve kullan” tipi bir paket gibi davranmıyor. Hani npm’den indirip kenara cekildiginiz o eski alışkanlık var ya… burada işler öyle yurumu yor. Bileşeni projeye alıyorsunuz, dosya sizin oluyor, sonra canınız nasıl isterse öyle kurcaliyorsunuz. Ilk bakışta biraz ters geliyor. Sonra fark ediyorsunuz ki rahatlatıcı olan da bu.
Neden herkes aynı konuyu konuşuyor?
Shadcn/ui’nın popülerliği biraz da teknoloji dünyasının uzun süredir taşıdığı bir sıkıntıya dokunmasindan geliyor: bileşen kütüphaneleri çoğunlukla sızı hızlandırırken bir yandan da bağlıyor. Evet, ilk hafta şahane görünüyorlar. Ama iki ay sonra tema değiştirmek istersiniz, üç ay sonra özel davranış eklersiniz, altı ay sonra sürüm güncellemesi gelir. Yarım gününüz gider. Tanıdık geldi mi? Bana fazlasıyla.
Ben bunu ilk kez 2024’un başında Beşiktaş’taki bir SaaS projesinde net biçimde gördüm. Tasarımcı arkadaşımız butonlarin köşesini biraz daha yumuşatmak istedi; normalde küçük görünen bu değişiklik başka sistemlerde neredeyse mini proje olurdu. Burada işe ilgili dosyayı açıp düzeltmek yeterliydi (ciddiyim). O an kafamda ampul yandı: “Tamam,” dedim, “bu başka.”
Yani, Işin özü su: shadcn/ui size hazır kutu vermiyor; parçaları veriyor. Bir lego seti gibi düşünün ama kutunun kapağı kilitli değil — parçalar masanın üstünde duruyor ve siz hangisini nereye koyacaginiza karar veriyorsunuz.
Klasik kütüphane mantığından farkı ne?
Mantık çok basit görünüyor ama etkisi büyük (buna dikkat edin). Geleneksel yapılarda komponentleri dış paketten import edersiniz; sürüm gelir, bağımlılık gelir, bazen de ufak bir API değişikliği ölür ve zincirleme sorun çıkar (ciddiyim). shadcn/ui’de işe komponentler doğrudan proje klasorunuze kopyalanıyor. Yani kod sizin repo’nuzda yaşıyor.
Bunun pratik karşılığı su: geliştirici olarak “paketin sınırları” içinde düşünmek zorunda kalmıyorsunuz. Istediğiniz yerde değişiklik yapabiliyorsunuz; custom variant ekliyorsunuz, spacing’i oynuyorsunuz, hatta bazı yerlerde neredeyse tamamen farklı davranış yazıyorsunuz. YouTube TV’de 90 Saniyelik Reklam Şoku: İşler Karıştı yazımızda bu konuya da değinmiştik.
npx shadcn@latest init
npx shadcn@latest add button
npx shadcn@latest add dialog
npx shadcn@latest add dropdown-menuNeden bana göre işliyor?
Bir kere sürüm derdi azalıyor. Bakın şimdi… MUI veya Chakra tarafında sürüm geçişi bazen tatlı bela gibi gelir; kâğıt üstünde güncelleme yaparsınız ama gerçek hayatta kırılan stillerle uğraşı rsiniz. ShadCN tarafında işe o bağımlılık baskısı hissedilmiyor çünkü kod zaten sizde duruyor.
E tabi bunun güzel tarafı kadar eksik yani da var: otomatik güncelleme rahatlgi azalıyor. Yani paket kendiliğinden sızı itip kakmiyor; sorumluluk size geçiyor. Bu iyi mi kötü mu? Küçük ekipte bence iyi bile sayılır çünkü karar hızı artıyor ama kurumsal tarafta disiplin şart oluyor.
Ve işler burada ilginçleşiyor.
Şunu söyleyeyim, Editör masasında bu yazıyı hazırlarken ben de eski notları karıştırdım; Nişan 2025’te Ankara’da yaptığım bir demo uygulamada sadece üç component ekleyerek taslak ekranı ayağa kaldirmistik: button, dialog. Form parçaları… Gerçekten hızlıydı ama sonrasında erişilebilirlik detaylarını elden geçirmek gerektiği için biraz ter dokduk (hani her şey güllük gülistanlık olmuyor).
| Kriter | shadcn/ui | Klasik UI Kütüphanesi |
|---|---|---|
| Sahiplik | Kod sizde | Kod pakette |
| Güncelleme baskısı | Daha düşük | Daha yüksek olabilir |
| Özelleştirme | Düz dosya düzenleme ile kolay | Tema/override mekanizmasına bağlı |
| Ağırlık kontrolü | Kullandığın kadar parça | Paket mimarisine bağlı ölür |
| Ekip disiplini ihtiyacı | Daha yüksek olabilir | Daha standart akış sunar} |
No lock-in meselesi neden önemli?
No lock-in lafını pazarlama cümlesi gibi okumayın; günlük işte karşılığı baya somut oluyor. Bir müşteri toplantısında tasarım dili degisirsa gidip tema ayarıyla oyalanmıyorsunuz, ilgili component dosyasına giriyorsunuz. Işi hallediyorsunuz. PR Açıklaması Nasıl Yazılır: Doğal ve Net Dursun yazımızda bu konuya da değinmiştik.
Küçük bir detay: Buna karşılık büyük ekiplerde kontrolsüzlük riski de var tabii ki. Eğer herkes component dosyalarını kafasına göre oynarsa kısa sürede küçük mutasyonlar başlıyor — bugün border radius değişir, yarın renk sistemi kayar… Sonunda tasarım dili yamalı bohçaya dönüyor. Razor 1911: 40 Yıllık Dijital İsyan ve Demo Efsanesi yazımızda bu konuya da değinmiştik.
Hangi bileşenler en çok is görüyor?
Açıl söyleyeyim, her projede her şeyi kurmaya gerek yok! Zaten güzel taraflarından biri de bu seçicilik hissi veriyor olmasıdır. Ilk etapta ben genelde button, input+label ikilisiyle başlarım; ardından dialog ve dropdown-menu gelir. Bunlar temel taşlar çünkü ürünün yüzde sekseni oralardan akar gider.
- Button: Temel ama kritik; varyant yönetimi rahat.
- Input + Label: Formlarin omurgası gibi çalışır.
- Dialog: Modal akışlarında fazla kavga çıkarmadan ilerler.
- Select:, yani kullanması daha doğal hissettirir (özellikle özelleştirilmiş select’lerde). (bu kritik)
Küçük startup ile enterprise arasında fark nerede?
Küçük startup için avantaj belli: hızlı prototip çıkarırsınız, UI kararlarını erken test edersiniz. Gereksiz paket yüküne girmezsiniz. Urun-pazar uyumu ararken bu ciddi konfor sağlıyor.
Ama enterprise seviyede durum biraz daha çetrefilli.
Orada tek tek component sahibi olmak kulağa hoş geliyor fakat design system governance yoksa kaos çıkabilir.
Yani evet… özgürlük güzel ama kurumsal düzen olmayınca özgürlük bazen gürültüye dönüşüyor.
Peki eksileri yok mu? Var tabii!
Bana göre en büyük eksi su:
Her şey sizin repo’nuzda olduğu için bakım yükü de size kalıyor.
Kulağa romantik gelebilir ama beşinci sprintten sonra insan şunu soruyor:
“Bu file’a kim ne yaptı?”
İşte orada disiplin devreye giriyor.
” Honda’nın Çin Şoku: Bir CEO’nün İtirafı Ne Anlama Geliyor? yazımızda da bu konuya değinmiştik. Netflix’in Türkiye’deki Yeni Oyuncu Çağrısı: Şans, Set ve Basketbol yazımızda da bu konuya değinmiştik.
shadcn/ui hızlı hissettiriyor çünkü size hazır siyah kutu vermek yerine düzenlenebilir yapı sunuyor… ama bunun bedeli ekip disiplinidir.
“
“Bir de şunu dürüstçe söylemem lazım:
Bazı projelerde “kendi component’in olsun” fikri beklediğim kadar pürüzsüz gitmedi.
Özellikle acele teslim edilen dashboard işlerinde insanlar önce hız istiyor;
sonra accessibility konusu pat diye kapıya dayaniyor.
O noktada güzel görünüm yetmiyor.”
“
“Ne zaman tercih etmeliyim?” sorusunun kısa cevabı
“”Eğer React + Tailwind hattindaysaniz,
tasarım üzerinde ciddi söz hakkınız varsa
ve komponentleri kendi ellerinizle şekillendirmek istiyorsanız
shadcn/ui baya iyi seçenek.
“Açık konuşayım,
ben bunu her projeye körlemesine koymam.
Mesela içerde ağır kurumsal UI standardı olan,
çok sayıda ekip tarafından kullanılan platformlarda önce tasarım sistemi oturturum,
sonra shadcn/ui parçalarını kontrollü şekilde alırım.”
“”
“Ha bu arada küçük ekiplerde tam tersi çalışabilir:
önce hızlıca birkaç kritik component alinır,
ürünün dili oluşur,
sonra ihtiyaç oldukça genişletilir.
Bu akış bana daha mantıklı geliyor.”
” (kendi tecrübem)
“
Sıkça Sorulan Sorular
shardCN ui ücretsiz mi?
”
“”Evet,
tamamen ücretsiz kullanılabiliyor.
Kodlarınızı kendi projenize aldığınız için lisans tarafı da oldukça rahat ilerliyor.”
“”
”
?MUI yerine neden shadcN/UI seçeyim?”
”
“”Evet,
tamamen ücretsiz kullanılabiliyor.
Kodlarınızı kendi projenize aldığınız için lisans tarafı da oldukça rahat ilerliyor.”
“”
”
?MUI yerine neden shadcN/UI seçeyim?”
“Daha fazla sahiplik,
daha az framework kavgası ve daha hafif hissettirmesi yüzünden tercih ediliyor.
Ama hazır enterprise özelliklerini hemen beklememek lazım.”
“
?Yeni başlayan biri için uygun mu?”
”
“”Eğer React ve Tailwind konusunda temel bilginiz varsa evet,
gayet uygun.
Hiç bilmeyene işe başlangıçta biraz farklı gelebilir çünkü yapı klasik paket mantığından ayrılıyor.”
“”
“
?Performansa katkısı ölür mu?”
“Doğrudan mucize yaratmaz,
ama yalnızca kullandığınız component’leri aldığınız için gereksiz ağırlığı azaltmaya yardımcı olabilir.
Asıl kazanç genelde mimarı esneklikten geliyor.”
”
Kaynaklar ve İleri Okuma
Tailwind CSS Dokümantasyonu (Kurulum)
Azure Mimari Rehberi: Teknoloji Seçimi (Genel Yaklaşım)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
