Shadcn रेडियो बटन की अत्यधिक जटिलता

(paulmakeswebsites.com)

2 पॉइंट द्वारा GN⁺ 2026-01-21 | 4 टिप्पणियां | WhatsApp पर शेयर करें

वेब ब्राउज़र में डिफ़ॉल्ट रूप से मौजूद radio button एक साधारण HTML element है, लेकिन Shadcn UI लाइब्रेरी इसे React components की कई परतों में फिर से बनाती है
Shadcn के <RadioGroup> और <RadioGroupItem>, Radix UI के components को फिर से wrap करते हैं और lucide-react icon तथा दर्जनों Tailwind classes का उपयोग करते हैं
Radix accessibility और customization के लिए ARIA attributes का उपयोग करता है, लेकिन वास्तव में डिफ़ॉल्ट <input type="radio"> की जगह button element को दोबारा इस्तेमाल करता है
जबकि वही styling साधारण CSS से भी की जा सकती है, यह संरचना सैकड़ों लाइनों का code और कई dependencies जोड़कर अनावश्यक जटिलता पैदा करती है
बुनियादी HTML elements का पुन: उपयोग न करने से performance में गिरावट और maintenance का बोझ बढ़ता है, और web development की सरलता को नुकसान पहुँचता है

Shadcn रेडियो बटन संरचना का विश्लेषण

Shadcn, radio button को <RadioGroup> और <RadioGroupItem> इन दो components के ज़रिए लागू करता है
- हर component, @radix-ui/react-radio-group से लाए गए primitives को wrap करता है और lucide-react के CircleIcon का उपयोग करता है
- इसमें 45 से अधिक lines का code, 3 external imports, और styling के लिए 30 से अधिक Tailwind classes शामिल हैं
एक साधारण गोल संकेत के लिए SVG icon library लोड की जाती है
- जबकि यह काम CSS के border-radius या <circle> element से भी किया जा सकता है

Radix UI की भूमिका

Shadcn द्वारा उपयोग किया जाने वाला Radix, accessibility और customization पर केंद्रित low-level UI component library है
- Radix का radio group implementation लगभग 215 lines के React code और 7 files के import पर आधारित है
Radix, <button> element में ARIA attributes जोड़कर उसे radio button की तरह काम करने लायक बनाता है
- लेकिन W3C के ARIA उपयोग का पहला सिद्धांत साफ़ कहता है: “जहाँ संभव हो, मूल HTML elements का उपयोग करें”
- Radix इस सिद्धांत का पालन नहीं करता और <input> की जगह button को फिर से इस्तेमाल करता है
<form> के अंदर ही hidden <input type="radio"> जोड़ने वाली इसकी संरचना सुसंगत नहीं लगती

CSS से संभव एक सरल विकल्प

डिफ़ॉल्ट HTML radio button को appearance: none, ::before, :checked, border-radius आदि से आसानी से style किया जा सकता है
- उदाहरण code में dependencies, JavaScript, या ARIA attributes के बिना पूर्ण customization दिखाया गया है
- वही प्रभाव Tailwind से भी बनाया जा सकता है
“radio button की styling कठिन है” यह धारणा अतीत की समस्या है; अब शुद्ध CSS से पर्याप्त नियंत्रण संभव है

जटिलता के जमा होने की समस्या

Shadcn और Radix को साथ उपयोग करने पर दो libraries और सैकड़ों lines के code को समझना पड़ता है
- एक साधारण radio button के लिए कई KB JavaScript अतिरिक्त लोड होती है
- उपयोगकर्ता को button toggle करने के लिए JS parse और execution का इंतज़ार करना पड़ता है
ऐसी संरचना cognitive load बढ़ाती है, bugs की संभावना फैलाती है, और web performance घटाती है

सरलता की ओर वापसी

ब्राउज़र पहले से ही radio button देता है, और <input type="radio" name="beverage" value="coffee" /> की एक लाइन ही काफ़ी है
अनावश्यक abstraction और nested libraries का उपयोग web development की मूल सरलता और दक्षता को नुकसान पहुँचाता है
छोटे UI elements में भी मूल functionality का पुन: उपयोग करने वाला design maintenance और performance, दोनों के लिए अधिक फायदेमंद है

4 टिप्पणियां

slowandsnow 2026-01-22

react aria के button component को देखें तो शायद बेहोश ही हो जाएँगे lol

preserde 2026-01-21

मैं frontend क्षेत्र से हूँ, इसलिए यह ऐसी समस्या है जिसका मैंने लंबे समय तक सामना किया है। कहें तो, इसे हल करना वाकई बहुत मुश्किल समस्या है। implementation समय के साथ लगातार बदलता रहा है, लेकिन input type से इसे हल नहीं किया जाता—यह हर दौर में एक जैसा ही रहा है...
वेब ब्राउज़र के radio/checkbox button के व्यवहार की नकल करने के लिए accessibility से जुड़ी specs को अलग से implement करना आखिर किसलिए है... समझ नहीं आता... जैसा कि मूल लेख में है, अब css से भी विकल्प मौजूद हैं, फिर भी किसी भी कीमत पर इसे component के रूप में implement करने की ज़िद देखते हुए थोड़ा हँसी आती है।

crawler 2026-01-21

उबाऊ और पांडित्यपूर्ण:

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

जल्दी खत्म, लंबे समय तक याद रहने वाला:

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

GN⁺ 2026-01-21

Hacker News की राय

मैं फ्रंटएंड पर बहुत अक्सर काम नहीं करता, लेकिन React के mainstream बनने के समय से ही लगने लगा था कि complexity बढ़ेगी
दूसरे abstraction layers आम तौर पर चीज़ों को simple बनाते हैं, लेकिन React अपने underlying tech से कहीं ज़्यादा जटिल abstraction बना देता है
ऐसा लगता है कि सिर्फ React जानने वाले developers लगातार उसके ऊपर और ऊँची layers चढ़ाते जाते हैं, और नतीजा over-engineered हो जाता है
- अब ज़्यादा बड़ी समस्या यह लगती है कि सब लोग React को default मानकर स्वाभाविक मान लेते हैं
  उदाहरण के लिए Shadcn या Radix React-only UI libraries हैं, लेकिन marketing copy पढ़कर वे सामान्य UI libraries जैसी लगती हैं
- मैं 15 साल से ज़्यादा समय से pure JavaScript और DOM API से UI बनाता आया हूँ
  scale बढ़ने पर आखिरकार या तो अपना framework बनाना पड़ता था या मौजूदा framework से शिकायत होने लगती थी, और React इस समस्या को कुछ हद तक हल करता है
  समस्या React से ज़्यादा ecosystem की अति-जटिलता में है। अगर React अच्छे से आता हो तो आज भी उसे मज़े से इस्तेमाल किया जा सकता है
- यह सिर्फ React की समस्या नहीं है, असली समस्या यह है कि लोग modern CSS सीखना ही नहीं चाहते
  वे Tailwind जैसे tools से CSS को bypass करना चाहते हैं। मैं state management React से करता हूँ, लेकिन styling सीधे CSS में करना पसंद करता हूँ
  team members को CSS सीखने के लिए मनाना सबसे मुश्किल काम है
- abstraction का मूल उद्देश्य complexity को छिपाने वाला दार्शनिक tool होना चाहिए, लेकिन आजकल यह अक्सर उल्टा और ज़्यादा जटिल बना देता है
  मैं ऐसे “modern” frameworks से बचता हूँ और जहाँ तक हो सके मूल तकनीकों को पसंद करता हूँ
- React का core component abstraction है
  React सिर्फ एक “box” देता है, उसके अंदर क्या रखना है यह developer तय करता है। React की असली ताकत यही है
यह radio button वाला उदाहरण मज़ेदार भी है और असरदार भी
final result basic CSS radio button से अलग दिखता भी नहीं, तो सवाल उठता है कि इसे इतना जटिल बनाने की ज़रूरत क्या है
जिज्ञासा है कि क्या बड़े scale की कोई sites ऐसी हैं जो इस अनावश्यक complexity के बिना बनी हों
- McMaster-Carr साइट को अक्सर अच्छे उदाहरण के रूप में बताया जाता है। इससे जुड़ा Hacker News thread भी है
- 15 साल पहले मैंने एक video collaboration web app बनाई थी, जिसका frontend लगभग jQuery आधारित vanilla structure पर था
  आज की तुलना में code ज़्यादा था, लेकिन interface में तुरंत प्रतिक्रिया देने वाली फुर्ती थी
  Takeoff project code देखा जा सकता है
- “इस साइट का क्या?” — शायद यही Hacker News खुद ऐसा उदाहरण हो सकता है
- कंपनी का scale बढ़ते ही managers standardized stack चाहते हैं
  “React चुनकर किसी की नौकरी नहीं गई” वाली बात की तरह, यह safe choice बन चुका है
- UI सबको दिखता है और सबकी राय होती है, इसलिए complexity एक tragedy of the commons की तरह बढ़ती जाती है
developers को याद रखना चाहिए कि वे design requirements का हमेशा विरोध कर सकते हैं
React Native में एक साधारण layout problem पर 4 घंटे बर्बाद कर रहे developer से मैंने कहा कि पूछो क्या design थोड़ा बदला जा सकता है, और 10 मिनट में समस्या हल हो गई
- आजकल मैं JS-रहित UI frameworks (Pico.CSS, Skeleton, Bulma, Tailwind/daisyUI) को पसंद करता हूँ
  सिर्फ CSS से भी काफ़ी अच्छे results मिल सकते हैं। अगर किसी ने यह approach अपनाई हो तो उसकी recommendations जानना चाहूँगा
2025 में मेरी सबसे बड़ी गलती Shadcn चुनना थी
Radix को बार-बार import होते देख पहला warning sign मिला, और radio component देखकर दूसरा
project पहले से चल रहा था इसलिए छोड़ नहीं सका और Copilot से fixes करवाए, लेकिन नतीजे में यह AI पर निर्भरता भी अच्छी नहीं लगी
पुराना POC कहीं ज़्यादा simple और efficient था। कभी न कभी सब कुछ vanilla HTML में फिर से बनाना चाहता हूँ
- React+NextJS+Tailwind+Shadcn का combo complexity की पराकाष्ठा है
  Remix या React Router 7 फिर भी web standards के क़रीब रहने की कोशिश करते थे
  Tailwind पर ही लगा कि “यह सही नहीं है”, और अगर दोस्त लोग refactor के बाद भी इसे अच्छा कहें तो फिर कभी दोबारा देखूँगा
- सच कहें तो Tailwind और React की जोड़ी उतनी अच्छी नहीं है
  React में पहले से props-based styling है, तो फिर CSS classes के बड़े ढेर की क्या ज़रूरत
  अगर accessibility पर ध्यान है, तो सिर्फ Radix UI भी काफ़ी है
browser के <input> elements, खासकर radio और select, की मुश्किल यह है कि इन्हें customize करना कठिन होता है
default radio button mobile पर usability के लिहाज़ से कमजोर पड़ता है
- असल में native controls को भी CSS से काफ़ी अच्छे से style किया जा सकता है
  mobile पर क्या समस्या आई, यह थोड़ा और ठोस तरीके से जानना चाहूँगा
- लेख में भी CSS से radio button सजाने का तरीका बताया गया है। क्या वही समस्या है?
- <label> में wrap करके padding दे दी जाए तो mobile पर भी यह काफ़ी usable हो जाता है
- “select” अब भी styling के मामले में कठिन है, लेकिन बाकी controls काफ़ी लचीले तरीके से customize किए जा सकते हैं
ज़्यादातर projects अच्छे इरादों से शुरू होते हैं, लेकिन देखते-देखते वे 200-line radio button code और 7 import से भर जाते हैं
यहीं से code rot शुरू होती है
हाल ही में daisyUI इस्तेमाल किया, और यह काफ़ी पसंद आया
यह pure CSS आधारित है, इसलिए browser की नई features (जैसे dialog) का अच्छा फ़ायदा उठा सकता है
- लेकिन accessibility के मामले में इसमें काफ़ी कमियाँ हैं
  उदाहरण के लिए Drawer focus trap नहीं कर पाता, और Accordion radio button का JS replacement की तरह दुरुपयोग करता है
  इन्हीं वजहों से Radix जैसी libraries का जटिल होना लगभग तय है
लेख की बात से सहमति है, लेकिन अगर designer ने Figma में जो exact style बनाया है उसे हर browser में एक जैसा लागू करना हो, तो क्या यह vanilla CSS से मुमकिन है?
क्या Radix demo जैसी चीज़ को पूरी तरह reproduce किया जा सकता है?
- थोड़े-बहुत बदलाव के साथ काफ़ी मिलता-जुलता बनाया जा सकता है
  CodePen उदाहरण देखा जा सकता है
- आखिरकार उन जटिल frameworks के नीचे भी CSS ही मूल चीज़ है
  CSS को निकालकर किसी simple React component में लगा दें, तो वह काफ़ी है
- इस उदाहरण की तरह vanilla input पर वही CSS लगा दी जाए, तो browser compatibility भी अच्छी रहती है
- लेख के लेखक ने खुद आकर कहा कि “यह बस basic example को Shadcn style के हिसाब से ढालने वाली चीज़ है, चाहें तो इसे जितना चाहें customize किया जा सकता है”
- लेकिन सवाल यह है कि perfection की सीमा कहाँ तक खींचनी चाहिए
  थोड़े visual mismatch से बचने के लिए दर्जनों KB code और maintenance burden जोड़ना क्या सच में सही है?
  Nam June Paik की बात याद आती है: “अगर कुछ बहुत perfect हो, तो भगवान नाराज़ हो जाते हैं”
असली लागत code नहीं, बल्कि onboarding time है
नई team में शामिल हुआ developer अगर Radix आधारित 47-line radio button को समझना चाहे, तो उसमें हफ़्ते लग सकते हैं
जबकि vanilla तरीका एक दिन में बनाया जा सकता है और 20 मिनट में समझाया जा सकता है
हाँ, अगर Figma या Linear जैसे products की तरह accessibility और keyboard navigation बेहद महत्वपूर्ण हों, तो यह complexity justified हो सकती है
- एक सवाल यह भी है कि क्या अच्छी library ऐसी नहीं होनी चाहिए जिसे उसके internal structure को जाने बिना भी इस्तेमाल किया जा सके
कई comments Shadcn की आलोचना कर रहे हैं, लेकिन मुझे उल्टा लगता है कि यह component structure और reusability को अच्छी तरह बढ़ावा देता है
Shadcn का मूल दर्शन है: “components को खुद own करो और modify करो”
यह पारंपरिक UI libraries से मूल रूप से अलग approach है