Shadcn radyo düğmelerindeki aşırı karmaşıklık

 (paulmakeswebsites.com)
2 puan yazan GN⁺ 2026-01-21 | 4 yorum | WhatsApp'ta paylaş
  • Web tarayıcısına varsayılan olarak gömülü radyo düğmesi, basit bir HTML öğesi olmasına rağmen Shadcn UI kütüphanesinde birden çok katmandan oluşan React bileşenleriyle yeniden inşa ediliyor
  • Shadcn’in <RadioGroup> ve <RadioGroupItem> bileşenleri, Radix UI bileşenlerini tekrar sarmalıyor ve lucide-react ikonları ile onlarca Tailwind sınıfı kullanıyor
  • Radix, erişilebilirlik ve özelleştirme için ARIA özniteliklerini kullanıyor; ancak gerçekte varsayılan <input type="radio"> yerine düğme öğesini yeniden kullanıyor
  • Basit CSS ile aynı stil oluşturulabilmesine rağmen bu yapı, yüzlerce satır kod ve çeşitli bağımlılıklar ekleyerek gereksiz karmaşıklığa yol açıyor
  • Varsayılan HTML öğelerini yeniden kullanmamak, performans düşüşünü ve bakım yükünü artırıyor; web geliştirmenin sadeliğine zarar veriyor

Shadcn radyo düğmesi yapısının analizi

  • Shadcn, radyo düğmesini <RadioGroup> ve <RadioGroupItem> olmak üzere iki bileşenle uyguluyor
    • Her bileşen, @radix-ui/react-radio-group içinden alınan primitive’leri sarıyor ve lucide-react içindeki CircleIcon’u kullanıyor
    • 45 satırdan fazla kod, 3 harici import ve 30’dan fazla Tailwind sınıfı içeriyor
  • Basit bir dairesel gösterim için SVG ikon kütüphanesi yükleyen bir yapı kullanılıyor
    • Bu işlev, CSS’te border-radius ya da <circle> öğesiyle değiştirilebilir

Radix UI’nin rolü

  • Shadcn’in kullandığı Radix, erişilebilirlik ve özelleştirme odaklı düşük seviyeli bir UI bileşen kütüphanesi
    • Radix’in radyo grubu uygulaması yaklaşık 215 satır React kodu içeriyor ve 7 dosya import ediyor
  • Radix, <button> öğesine ARIA öznitelikleri ekleyerek bunun radyo düğmesi gibi davranmasını sağlıyor
    • Ancak W3C’nin ARIA kullanımına ilişkin birinci ilkesi, “Mümkün olduğunda yerel HTML öğelerini kullanın” diyor
    • Radix bu ilkeye uymuyor ve <input> yerine düğmeyi yeniden kullanıyor
  • Yalnızca <form> içinde gizli bir <input type="radio"> ekleyen yapı, tutarlılık açısından zayıf kalıyor

CSS ile mümkün olan basit alternatif

  • Varsayılan HTML radyo düğmesi, appearance: none, ::before, :checked, border-radius gibi özelliklerle kolayca stillendirilebilir
    • Örnek kodda bağımlılık, JavaScript ve ARIA öznitelikleri olmadan tam özelleştirme uygulanıyor
    • Aynı etki Tailwind ile de elde edilebilir
  • “Radyo düğmesini stillendirmek zordur” algısı geçmişin sorunu; bugün yalnızca saf CSS ile yeterli kontrol sağlanabiliyor

Karmaşıklığın birikme sorunu

  • Shadcn ve Radix birlikte kullanıldığında iki kütüphane ve yüzlerce satır kodun anlaşılması gerekiyor
    • Basit bir radyo düğmesi için birkaç KB JavaScript ek olarak yükleniyor
    • Kullanıcı, düğmenin açılıp kapanması için JS’nin parse edilmesini ve çalıştırılmasını beklemek zorunda kalıyor
  • Bu yapı artan bilişsel yük, daha yüksek hata olasılığı ve daha düşük web performansı ile sonuçlanıyor

Sadeliğe dönüş

  • Tarayıcılar radyo düğmesini zaten yerleşik olarak sunuyor ve <input type="radio" name="beverage" value="coffee" /> tek satırda yeterli oluyor
  • Gereksiz soyutlamalar ve iç içe geçmiş kütüphane kullanımı, web geliştirmenin özündeki sadeliğe ve verimliliğe zarar veriyor
  • Küçük bir UI öğesinde bile yerel işlevleri yeniden kullanan bir tasarım, hem bakım kolaylığı hem de performans açısından daha avantajlıdır

İlgili okumalar

4 yorum

 
crawler 2026-01-21

Sıkıcı ve bilgiççe:

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

Çabuk biter, uzun süre akılda kalır:

&lt;input type=&quot;radio&quot; name=&quot;beverage&quot; value=&quot;coffee&quot; /&gt;
 
slowandsnow 2026-01-22

react aria'nın button component'ine bakınca insan bayılır gibi oluyor lol
 
preserde 2026-01-21

Benim frontend alanında uzun zamandır yaşadığım bir sorun bu; nasıl desem, çözmesi gerçekten çok zor bir mesele. Uygulama biçimi döneme göre sürekli değişiyor ama bunu input type ile çözmemeleri her dönemde aynı kalıyor...
Web tarayıcısındaki radyo ve checkbox düğmelerinin davranışını taklit etmeye çalışıp erişilebilirlikle ilgili spesifikasyonları ayrıca uygulamak da neyin nesi gerçekten... bilmiyorum... Yazıda da dendiği gibi artık CSS ile de alternatifler varken, illa bunu component olarak implemente etmeye çalışmalarını görünce biraz komik geliyor.
 
GN⁺ 2026-01-21
Hacker News yorumları

  • Frontend ile çok sık uğraşmıyorum ama React ana akım olmaya başladığından beri karmaşıklığın artacağına dair işaretler vardı
    Diğer soyutlama katmanları genelde basitleşme eğilimindeyken, React kendi temel teknolojilerinden çok daha karmaşık bir soyutlama üretiyor
    Yalnızca React bilen geliştiriciler bunun üstüne giderek daha yüksek katmanlar inşa ettikçe, ortaya aşırı tasarlanmış sonuçlar çıktığını düşünüyorum

    • Bence artık daha büyük sorun, herkesin React’i varsayılan seçenek olarak doğal kabul etmesi
      Örneğin Shadcn ya da Radix React’e özel UI kütüphaneleri ama pazarlama metinlerine bakınca genel amaçlı UI kütüphanesi gibi görünüyorlar
    • 15 yıldan uzun süredir saf JavaScript ve DOM API ile UI geliştiriyorum
      Ölçek büyüdüğünde ya kendi framework’ümü yazmak ya da mevcut framework’lerden memnun kalmamak gibi bir noktaya geliyordum, React bunu bir ölçüde çözüyor
      Sorunun React’in kendisinden çok ekosistemin aşırı karmaşıklığı olduğunu düşünüyorum. Sadece React’i iyi kullanırsanız hâlâ keyifle çalışılabilir
    • Bunun sadece React sorunu olmadığını, asıl büyük sorunun insanların modern CSS öğrenmek istememesi olduğunu düşünüyorum
      Sadece Tailwind gibi araçlarla CSS’ten kaçmaya çalışıyorlar. Ben React ile state yönetiyorum ama stillendirmeyi doğrudan CSS ile yapmayı tercih ediyorum
      Ekip arkadaşlarını CSS öğrenmeye ikna etmek en zor iş
    • Soyutlama aslında karmaşıklığı gizleyen felsefi bir araç olmalı ama bugünlerde çoğu zaman tam tersine daha da karmaşık hâle getiriyor
      Ben bu tür “modern” framework’lerden kaçınıyor ve mümkün olduğunca temel teknolojileri tercih ediyorum
    • React’in özü bileşen soyutlamasıdır
      React sadece bir “kutu” sağlar, içine ne koyacağınıza geliştirici karar verir. React’in gerçek gücü de budur

  • Bu radio button örneği hem komik hem de etkileyici
    Ortaya çıkan sonuç temel CSS radio button’ından ayırt edilemiyor; neden bunu bu kadar karmaşık yaptıklarını merak ediyorum
    Bu tür gereksiz karmaşıklık olmadan yapılmış büyük ölçekli sitelere örnek var mı diye merak ediyorum

    • McMaster-Carr sitesi buna iyi bir örnek olarak sık anılıyor. Bununla ilgili bir Hacker News başlığı da var
    • 15 yıl önce video işbirliği odaklı bir web uygulaması yapmıştım; frontend neredeyse tamamen jQuery tabanlı vanilya bir yapıydı
      Bugüne göre daha çok kod vardı ama arayüzde anında tepki veren bir hız hissi bulunuyordu
      İsteyenler Takeoff proje koduna bakabilir
    • “Peki bu site nasıl?” — belki de bunun örneği doğrudan Hacker News’in kendisi olabilir
    • Şirket büyüdükçe yöneticiler standartlaştırılmış bir stack istiyor
      “React’i seçti diye kimse işten çıkarılmaz” sözündeki gibi, güvenli tercih hâline geliyor
    • UI herkesin gördüğü ve hakkında fikir yürüttüğü bir alan olduğu için, karmaşıklık müştereklerin trajedisi gibi büyüyen bir yapıya sahip

  • Geliştiriciler, tasarım gereksinimlerine her zaman itiraz edebileceklerini hatırlamalı
    React Native’de basit bir yerleşim sorunu için 4 saat harcayan bir geliştiriciye “tasarımı biraz değiştirebilir miyiz” diye sormasını söyledim; sorun 10 dakikada çözüldü

    • Bu aralar ben JS’siz UI framework’lerini (Pico.CSS, Skeleton, Bulma, Tailwind/daisyUI) tercih ediyorum
      CSS’i iyi kullanınca yeterince iyi sonuç alınabiliyor. Böyle bir yaklaşımı kullananların önerilerini merak ediyorum

  • 2025’te yaptığım en büyük hata Shadcn seçmekti
    Sürekli Radix import edildiğini görmek ilk alarmdı, radio bileşenini görünce ikinci alarm çaldı
    Proje çoktan ilerlediği için vazgeçmeyip Copilot’la düzeltmeler yaptım ama sonuç olarak yapay zekaya bağımlılık da içime sinmedi
    Önceki POC çok daha basit ve verimliydi. Bir gün her şeyi vanilya HTML ile yeniden yapmak istiyorum

    • React+NextJS+Tailwind+Shadcn kombinasyonu karmaşıklığın zirvesi
      Remix ya da React Router 7 en azından web standartlarına daha yakın kalma yönünde bir çaba gösteriyordu
      Tailwind’de “bu kadarı fazla” dedim; arkadaşlarım refactor sonrasında hâlâ iyi olduğunu söylerse o zaman tekrar bakarım
    • Aslında Tailwind ile React çok iyi uyuşmuyor
      React’te zaten props tabanlı stillendirme var; o kadar CSS class yığını kullanmaya gerek yok
      Odak erişilebilirlikse yalnızca Radix UI bile yeterli olabilir

  • Sorun, tarayıcının <input> öğelerinin, özellikle radio ve select türlerinin özelleştirilmesinin zor olması
    Varsayılan radio button’lar mobilde kullanışlı değil

    • Aslında yerel kontroller de CSS ile gayet iyi stillendirilebilir
      Mobilde tam olarak ne tür bir sorun yaşandığını daha somut duymak isterim
    • Yazıda da radio button’ların CSS ile nasıl stillendirilebileceği anlatılıyor. Sorun bu mu?
    • <label> ile sarıp padding verirseniz mobilde de yeterince kullanılabilir olur
    • “select” hâlâ stillendirmesi zor bir alan ama geri kalanlar epey esnek biçimde özelleştirilebilir

  • Projelerin çoğu iyi niyetle başlıyor ama bir bakıyorsunuz 200 satırlık radio button kodu ve 7 import ile dolmuş
    Kod çürümesi (code rot) böyle başlıyor

  • Kısa süre önce daisyUI kullandım ve oldukça beğendim
    Saf CSS tabanlı olduğu için tarayıcının yeni özelliklerinden (dialog vb.) iyi yararlanabiliyor

    • Ama erişilebilirlik açısından ciddi eksikleri var
      Örneğin Drawer odak tuzağı kuramıyor, Accordion ise radio button’ları JS yerine geçecek şekilde aşırı kullanıyor
      Bu yüzden Radix gibi kütüphanelerin karmaşıklaşması bir ölçüde kaçınılmaz

  • Yazının ana fikrine katılıyorum ama tasarımcıların Figma’da hazırladığı tam stili tüm tarayıcılarda birebir uygulamak vanilya CSS ile gerçekten mümkün mü merak ediyorum
    Radix demosundaki gibi bir şeyi tamamen yeniden üretmek mümkün olur mu?

    • Ufak değişikliklerle oldukça benzer bir şey yapılabilir
      Şu CodePen örneğine bakabilirsiniz
    • Sonuçta o karmaşık framework’lerin altında da asıl belirleyici olan CSS
      Sadece CSS’i çıkarıp basit bir React bileşenine bağlamak yeterli olabilir
    • Bu örnekteki gibi vanilya input ile aynı CSS uygulanırsa tarayıcı uyumluluğu da iyi olur
    • Yazının yazarı bizzat gelip, “yalnızca temel örneği Shadcn stiline uyarladım; isterseniz dilediğiniz kadar özelleştirebilirsiniz” diye açıklama yapıyor
    • Ama asıl soru, mükemmelliği ne kadar zorlamamız gerektiği
      Ufak görsel farklılıkları engellemek için onlarca KB kod ve bakım yükü eklemek gerçekten buna değer mi?
      Nam June Paik’in sözüyle, “fazla mükemmellik tanrıyı kızdırır” gibi geliyor

  • Asıl maliyet kod değil, onboarding süresi
    Yeni katılan bir geliştiricinin Radix tabanlı 47 satırlık bir radio button’ı anlaması haftalar sürebilir
    Buna karşılık vanilya yaklaşımı bir günde yapılır, 20 dakikada da anlatılır
    Tabii Figma ya da Linear gibi erişilebilirlik ve klavye gezinmesi kritik olan ürünlerde bu karmaşıklık haklı görülebilir

    • İyi bir kütüphane, iç yapısını bilmeden de kullanılabilmeli değil mi diye düşündürüyor

  • Birçok yorum Shadcn’i eleştiriyor ama ben aksine onun bileşen yapısını ve yeniden kullanılabilirliği iyi teşvik ettiğini düşünüyorum
    Shadcn’in özü, “bileşenleri gerçekten sahiplenin ve kendiniz değiştirin” anlayışı
    Bu da mevcut UI kütüphanelerinden temelden farklı bir yaklaşım