React डिफ़ॉल्ट विकल्प के रूप में जीत रहा है और फ्रंटएंड इनोवेशन को धीमा कर रहा है

 (lorenstew.art)
8 पॉइंट द्वारा GN⁺ 2025-09-16 | 19 टिप्पणियां | WhatsApp पर शेयर करें
  • आज React को अपनाना अक्सर तकनीकी श्रेष्ठता की वजह से नहीं, बल्कि डिफ़ॉल्ट विकल्प के रूप में हो रहा है, और इससे फ्रंटएंड इकोसिस्टम में इनोवेशन धीमा पड़ रहा है
  • कई टीमें बाधाओं और आवश्यकताओं का आकलन किए बिना “सबको पता है React” के आधार पर उसे चुन लेती हैं, जिससे network effects तकनीकी उपयुक्तता से अधिक आर्किटेक्चरल फैसलों को प्रभावित करने लगे हैं
  • Svelte, Solid, Qwik जैसे नवोन्मेषी framework बेहतर performance model देते हैं, लेकिन adoption कम होने की वजह से मुख्यधारा की प्रतिस्पर्धा में पीछे हैं
  • React में कई खूबियाँ हैं, लेकिन समस्या React-default mindset की है, जो opportunity cost बढ़ाता है और बेहतर विकल्पों पर विचार की गुंजाइश कम करता है
  • एक स्वस्थ इकोसिस्टम के लिए विविधता और प्रतिस्पर्धा ज़रूरी है, और संदेश यह है कि framework को डिफ़ॉल्ट नहीं, बल्कि constraints और fit के आधार पर चुनना चाहिए

React की डिफ़ॉल्ट जीत और उसकी सीमाएँ

  • React अब तकनीकी बढ़त की वजह से नहीं, बल्कि अक्सर डिफ़ॉल्ट रूप से अपनाया जा रहा है
    • इससे टीमों में प्रोजेक्ट constraints का आकलन किए बिना React का अपने-आप उपयोग करने की आदत और मजबूत होती है
  • वैकल्पिक framework (Svelte, Solid, Qwik) कुछ scenarios में React से बेहतर performance देने के बावजूद ठीक से evaluate नहीं किए जाते
  • समस्या React खुद कम और React-default mindset ज़्यादा है, जो इनोवेशन को बाधित करने वाली संरचना बना रहा है

इनोवेशन की सीमा

  • React का Virtual DOM 2013 में उपयुक्त था, लेकिन आज कई मामलों में अनावश्यक overhead बन जाता है
  • Hooks ने class component की समस्याएँ हल कीं, लेकिन dependency array और stale closure जैसी नई जटिलताएँ भी जोड़ दीं
  • Server Components और React Compiler performance सुधारने की कोशिश हैं, लेकिन ये React model की सीमाओं को bypass करने के उपाय भी हैं
  • इसके उलट Svelte की Runes, Solid की fine-grained reactivity, Qwik की Resumability बिल्कुल अलग model के साथ अधिक संभावनाएँ दिखाती हैं

तकनीकी debt

  • React को डिफ़ॉल्ट मानकर चुनने से अनावश्यक runtime cost और rerendering management का बोझ पैदा होता है
  • डेवलपर business value के बजाय effect dependency या hydration management में समय खर्च करने लगते हैं
  • benchmark में Solid, React की तुलना में 2~3 गुना तेज update performance दिखाता है
  • React pattern-केंद्रित सोच web fundamentals को कमजोर करती है और architectural inertia को बढ़ाती है

वैकल्पिक framework

  • Svelte: compiler क्रांति

    • Svelte ज़्यादातर काम compile time पर करता है और virtual DOM को हटा देता है
    • components web की मूल संरचना के अधिक करीब हो जाते हैं, और runtime overhead काफ़ी कम हो जाता है
    • लेकिन “job opportunities कम हैं” जैसी धारणा की वजह से इसका adoption कम है
    • The Guardian, Wired, Shawn Wang जैसे कई उदाहरणों में Svelte अपनाने के बाद bundle size और loading time में बड़ी कमी और developer productivity में सुधार दिखा है
    • उदाहरण के लिए, Shawn Wang ने React में 187KB वाले site size को Svelte के साथ 9KB तक घटा दिया

  • Solid: सूक्ष्म reactivity का मूलभूत दृष्टिकोण

    • Solid fine-grained reactivity को JSX syntax के साथ जोड़कर देता है
    • signal के ज़रिए यह सीधे सिर्फ बदले हुए DOM तक पहुँचता है और reconciliation bottleneck को पूरी तरह टाल देता है
    • इसमें शानदार performance और सरल state management की ताकत है
    • adoption cases अभी सीमित हैं, लेकिन शुरुआती teams के अनुभव बताते हैं कि efficiency और code simplicity दोनों में बड़ा सुधार मिलता है

  • Qwik: Resumability इनोवेशन

    • Qwik में traditional hydration की जगह resumability है, जिससे तुरंत startup इसका बड़ा फायदा है
    • यह केवल मौजूदा ज़रूरत के features को progressively load करता है, और state व code दोनों को serialize किया जा सकता है
    • बड़े sites, लंबे sessions और धीमे network पर यह बेहतरीन नतीजे देता है
    • अभी बहुत सी टीमों ने इसे नहीं आज़माया है, लेकिन अपनाने वाली टीमों ने initial loading time और resource efficiency दोनों में बड़ा सुधार बताया है

  • React API की जटिलता और वैकल्पिक framework की सरलता

    • React API में hook, context, reducer, memoization आदि जैसे जटिल concepts शामिल हैं, जिससे डेवलपर पर cognitive load बढ़ता है
    • गलत इस्तेमाल होने पर dependency issues से bug और ज़रूरत से ज़्यादा design burden पैदा हो सकता है
    • उदाहरण के लिए, Cloudflare की 12 सितंबर 2025 की outage का कारण भी useEffect की dependency array configuration की गलती बताई गई
    • इसके उलट Svelte, Solid, Qwik जैसे विकल्प कहीं छोटे और focused API के साथ सरलता और web के मूल सिद्धांतों पर ज़ोर देते हैं
    • इन तीनों framework में तकनीकी बढ़त पर्याप्त है, लेकिन React के डिफ़ॉल्ट कल्चर की वजह से अक्सर इन्हें प्रयोग करने का मौका भी नहीं मिलता

network effects का कैदखाना

  • React का प्रभुत्व खुद को और मज़बूत करने वाली दीवारें बना रहा है
  • hiring market में “React developer” ही खोजे जाते हैं, और हर संगठन में component library, development habits जैसी चीज़ें React के हिसाब से जम चुकी हैं
  • risk से बचने वाले leaders स्वाभाविक रूप से सुरक्षित React को चुनते हैं, और educational institutions भी उसी के अनुसार ढल जाते हैं
  • ऐसी संरचना स्वस्थ प्रतिस्पर्धा से खाली इकोसिस्टम की पहचान है

network effects को तोड़ना

  • इससे बाहर निकलने के लिए सचेत चयन ज़रूरी है
  • technical leaders को inertia छोड़कर requirements के आधार पर architecture तय करना चाहिए, और कंपनियाँ pilot budget देकर विकल्पों को आज़मा सकती हैं
  • डेवलपरों को भी एक ही paradigm पर अड़े रहने के बजाय अलग-अलग framework सोच को सीखना चाहिए
  • educational institutions को framework-agnostic concepts पर आधारित पढ़ाई बढ़ानी चाहिए, और open source contributors छोटे इकोसिस्टम को मज़बूत करने में मदद कर सकते हैं
    परिवर्तन अपने-आप नहीं आता, उसे इरादे के साथ बनाना पड़ता है.

framework evaluation checklist

नए प्रोजेक्ट में निम्न मानदंडों का उपयोग किया जा सकता है

  • performance requirements: initial loading, update efficiency, bundle size और compile time optimization की उपलब्धता
  • team capability और learning curve: मौजूदा अनुभव को ध्यान में रखें; Solid जैसे React-संगत विकल्प भी मौजूद हैं
  • scalability और cost of ownership: maintenance, dependency management, technical debt सहित दीर्घकालिक लागत का आकलन
  • ecosystem fit: maturity और innovation के बीच संतुलन, non-core work में pilot और ROI test

आम आपत्तियाँ और उनके जवाब

  • ecosystem maturity: पुराना इकोसिस्टम होना यह साबित नहीं करता कि वह आज की समस्याओं के लिए सबसे उपयुक्त ही होगा। third-party package पर अधिक निर्भरता maintenance burden, security vulnerabilities और bundle bloat जैसी समस्याएँ बढ़ा सकती है। इसके विपरीत, छोटा इकोसिस्टम web fundamentals पर अधिक केंद्रित रह सकता है, और AI tools की प्रगति से custom solution जल्दी बनाना आसान हो गया है।
  • hiring problem: मांग ही hiring standard बनाती है। non-core क्षेत्रों में विकल्पों को टेस्ट करके और on-the-job learning से skill gap भरा जा सकता है।
  • component libraries: framework-independent design system और Web Components का उपयोग lock-in कम करते हुए productivity बनाए रख सकता है।
  • stability: React भी hooks, Server Components आदि के साथ लगातार बदल रहा है। कई बार वैकल्पिक framework अधिक consistent API देते हैं।
  • बड़े पैमाने पर validation की ज़रूरत: कभी jQuery भी वैश्विक उदाहरण था। अतीत की सफलता भविष्य की गारंटी नहीं है।

इकोसिस्टम और उद्योग पर व्यापक नुकसान

  • React की एकल-संस्कृति web के विकास को ही धीमा कर देती है
  • talent और capital सिर्फ React की समस्याएँ सुलझाने में लग जाते हैं, जबकि platform-स्तरीय इनोवेशन टलते रहते हैं
  • educational institutions भी तुरंत नौकरी-योग्यता केंद्रित curriculum के कारण transferable skills के बजाय सीमित तकनीकी प्रशिक्षण बढ़ा देते हैं
  • web platform का विकास खुद “React हो तो काफी है” जैसी सोच से रुकता है, और इकोसिस्टम में विविधता की कमी लंबी अवधि में सबके लिए नुकसान बनती है

हम कैसा बेहतर इकोसिस्टम बना सकते हैं

  • विविधता एक स्वस्थ इकोसिस्टम की अनिवार्य शर्त है
  • जब कई paradigm प्रतिस्पर्धा और आदान-प्रदान करते हैं, तभी इनोवेशन जन्म लेता है
  • डेवलपर अलग-अलग सोच के तरीके सीखकर आगे बढ़ते हैं, और web platform भी विविध प्रयोगों से विकसित होता है
  • किसी एक framework पर पूरी तरह निर्भर होना एक single point of failure बन जाता है। सीमा आने पर विकास रुक जाता है और बेहतर अवसर भी खो जाते हैं
  • हर प्रोजेक्ट में तकनीकी constraints और उपयुक्तता के आधार पर चयन होना चाहिए; सिर्फ React डिफ़ॉल्ट पर निर्भर रवैया पर्याप्त नहीं है
  • केवल विविधता ही वास्तविक इनोवेशन की गारंटी दे सकती है
  • अब समय है कि हम सब एक ही ‘बीज (React)’ न बोएँ, बल्कि अलग-अलग framework के साथ अधिक प्रयोग करके web इकोसिस्टम को और मज़बूत और अधिक नवाचारी बनाएं
  • चुनाव हमारे हाथ में है

संबंधित पढ़ाई

19 टिप्पणियां

 
supermaxi 2025-09-23

जूनियर डेवलपर्स के लिए React चुनना लाज़िमी हो सकता है, लेकिन सीनियर डेवलपर्स का दूसरे विकल्पों पर विचार करना बंद कर देना एक समस्या है।
 
singed 2025-09-20

यह सच है कि React या Java जैसी पुरानी कबाड़ चीज़ें, जबकि उनसे कहीं बेहतर विकल्प पहले से बहुत हैं, फिर भी बहुत लंबे समय तक बाज़ी मारती रहती हैं lol
 
devsepnine 2025-09-19

पिछले बड़े framework अराजकता वाले दौर में प्रयोग तो बहुत किए थे...
लेकिन काम में पहले से इस्तेमाल हो रही चीज़ों को उखाड़कर बदलने की ज़रूरत नहीं होती, और नया प्रोजेक्ट हो तब भी
जो चीज़ पहले से अच्छी चल रही हो उसे छोड़कर नया सीखने और उस पर स्विच करने के लिए तैयार लोग ज़्यादा नहीं मिलते, hiring की समस्या भी होती है..
 
xiniha 2025-09-18

उम्मीद है Solid थोड़ा अच्छा चले..... React के monopoly को कैसे तोड़ा जाए
 
say8425 2025-09-18

पिछले लगभग 10 सालों में FE ecosystem में अनगिनत tools आए, उनके उत्थान-पतन के बाद अब जाकर कुछ हद तक स्थिरता आई है, और अब फिर से उसी तरह की बड़ी अव्यवस्था आज़माने की बात हो रही है..
 
coremaker 2025-09-18

यह लेख बहुत ही पक्षपाती लगता है, है न?
"Svelte, Solid, Qwik जैसे इनोवेटिव framework बेहतर performance model प्रदान करते हैं, लेकिन adoption की कमी के कारण मुख्यधारा की प्रतिस्पर्धा में पीछे हैं"

अगर "innovation" शब्द के अर्थ को समझने के लिए कोई सुसंगत मानदंड ही नहीं है,
तो मुझे लगता है कि मूल धारणा ही गलत है।
 
indigoray 2025-09-18

ऐसे लेख पढ़कर लगता है कि लोग प्रोडक्ट बनाने पर ध्यान देने के बजाय सिर्फ software engineering में ही ज़रूरत से ज़्यादा डूबे हुए हैं। आखिरकार सब कुछ लगभग एक जैसा ही होता है, इसलिए प्रोडक्ट को अच्छी तरह बनाना ज़रूरी है, लेकिन लोग हर समय नया framework, नई architecture खोजते फिरते हैं, overengineering करते हैं, फिर कहते हैं यह बेहतर है तो इसे भी बदल दें। मेरा मानना है कि नया होना अच्छी बात नहीं है; असली बात यह है कि जो भी हो, उसे अच्छी तरह इस्तेमाल करके प्रोडक्ट रिलीज़ करना महत्वपूर्ण है।
 
biyott 2025-09-18

यह तो लाचारी वाली बात है, क्योंकि देश की बड़ी tech कंपनियाँ React (next.js) को आधार मानकर hiring करती हैं.
यहाँ तक कि बड़े माने जाने वाले vue.js के लिए भी big tech में hiring positions ज़्यादा नहीं हैं.
 
kallare 2025-09-18

इकोसिस्टम को नज़रअंदाज़ नहीं किया जा सकता... आजकल आने वाली third-party या open source libraries में ज़्यादातर React को official support मिलता है, लेकिन दूसरे frameworks को सिर्फ community support मिलता है, इसलिए यह-वह जोड़कर इस्तेमाल करना हो तो आखिरकार React ही सबसे सुरक्षित विकल्प बन जाता है...
 
slowandsnow 2025-09-17

फ्रंटएंड जितने विविध तरीकों से प्रयोग करता है, ऐसा और कौन-सा क्षेत्र है...
 
devstudyman7 2025-09-17

React की जीत डिफॉल्ट विकल्प के रूप में हो रही है, और यह frontend innovation को धीमा कर रहा है

Facebook की React डेवलपमेंट टीम की प्रतिबद्धता की बदौलत web app development में बहुत-सी चुनौतियाँ आईं। यह खलनायक नहीं है.. इसने php jquery युग का अंत कर दिया।
 
GN⁺ 2025-09-16
Hacker News टिप्पणी

  • मुझे नहीं लगता कि React बस डिफॉल्ट बन गया; बल्कि यह इतना प्रभावी और अच्छी तरह डिज़ाइन किया गया था कि यह व्यावहारिक रूप से मानक बन गया, और अब उसी कारण से खलनायक जैसा दिखने लगा है
    मुझे यह दावा कि React innovation को धीमा कर रहा है, काफ़ी बेतुका लगता है
    React अनगिनत "मुझे भी शामिल करो" टाइप frameworks और उलझे हुए डिज़ाइनों के बीच व्यावहारिक रूप से एकमात्र स्थिर और तर्कसंगत विकल्प है

    • मैं विनम्रता से असहमत हूँ
      मैंने React से कभी कोई जटिल interactive app नहीं बनाया; बस कुछ सरल sites बनाई हैं जहाँ टीम पहले से React चुन चुकी थी
      उस अनुभव से मुझे लगा कि React साधारण sites के लिए उल्टा ठीक से छोटा नहीं हो पाता
      अगर एक साधारण login page हो, तो state सीधे DOM में रखकर और सिर्फ <form> से value submit करके काम चल जाता है, और password show/hide के लिए थोड़ा सा JS काफी है
      लेकिन React में इसे बनाने के लिए JSX, hooks, component lifecycle, development build, production packaging वगैरह बहुत कुछ सीखना पड़ता है
      Vue या Alpine जैसे दूसरे frameworks को "progressive" तरीके से अपनाया जा सकता है, और सिर्फ CDN से भी तुरंत शुरू किया जा सकता है
      React भी खुद को progressive बताता है, लेकिन JSX की प्रकृति के कारण build-compile प्रक्रिया ज़रूरी हो जाती है, इसलिए CDN से सीधे शुरू करने का तरीका official docs में नहीं है
      जबरदस्ती करना असंभव नहीं है, लेकिन तब compiler भी client तक भेजना पड़ता है, जो व्यवहारिक रूप से सबसे खराब विकल्प है
      ज़्यादातर sites Facebook, Spotify, Netflix के स्तर की नहीं होतीं (और Netflix ने भी React से दूर जाने की बात कही थी), इसलिए यह मानना मुश्किल है कि React इतना प्रभावी और इतना अच्छी तरह डिज़ाइन किया गया है

    • जब React 12 साल पहले आया था, तब वह सचमुच innovative था
      लेकिन जल्द ही कई मिलते-जुलते frameworks आ गए, और उसके बाद से यह innovation के केंद्र में नहीं बल्कि बस "ठीक-ठाक इस्तेमाल लायक" स्तर पर रहा
      अब यह पुराने Virtual DOM डिज़ाइन की समस्याएँ सुलझाते-सुलझाते धीरे-धीरे boilerplate बढ़ाता जा रहा है, और आधुनिक alternatives की तुलना में कम आकर्षक लगता है

    • शीर्षक का मतलब उल्टा है
      असल में स्थिति यह लगती है कि "innovation" खुद React के फ़ॉर्मूले (सफलता के फ़ॉर्मूले) को पकड़ नहीं पा रहा

    • यह भी पूछना चाहिए कि innovation की ज़रूरत कितनी है
      अक्सर repetition और improvement ज़्यादा बेहतर और सस्ता विकल्प होते हैं

  • मुझे यह लेख और 2015~16 वाला pluralistic नज़रिया पसंद है
    मैं टीम से कहना चाहता हूँ, "चलो Svelte में कोई छोटा अलग use case बनाते हैं," लेकिन evaluation checklist लेख के दावे के ठीक उलट काम करती है
    Performance: 99% apps में फर्क महसूस ही नहीं होता, तो अंत में React चुना जाता है
    टीम की skill और learning curve: सबको React आता है, Qwik वगैरह नहीं. स्वाभाविक रूप से React चुना जाता है
    Scalability, operating cost: कोई बड़ा फर्क नहीं
    Ecosystem: React बहुत बड़ा और ज़्यादा स्थिर है. React चुना जाता है
    ऊपर से आजकल AI tools भी React के साथ बेहतर काम करते हैं, और developers भी लगभग अपने-आप React-केंद्रित तरीके से सीख रहे हैं
    आख़िरकार React ही तर्कसंगत विकल्प बन जाता है

  • मुझे लगता है कि इस framework oligopoly से निकलने का रास्ता Web components हो सकते हैं
    React को छोड़कर लगभग सभी frameworks Web components का सक्रिय समर्थन करते हैं; हर framework को अपना अलग React ecosystem दोबारा खड़ा करने के बजाय compatible components और utility ecosystem का लाभ उठाना ही रास्ता है
    बहुत लोग Web components को frameworks के प्रतिस्पर्धी के रूप में देखते हैं, लेकिन असल में वे component implementation और browser के बीच interface परिभाषित करते हैं, जिससे interoperability और भरोसेमंद composition संभव होता है
    ऐसे low-level API के ऊपर component बनाने के अलग-अलग तरीके (buildless, JSX, templates, custom syntax, compiler आदि) और component composition व state management में अलग-अलग innovations अब भी हो सकते हैं
    "हमारा नया Flugle framework किसी भी framework के साथ बढ़िया चलता है और automation tools भी भरपूर हैं!" — React की monopoly तोड़ने के लिए ऐसी बात कह पाना ज़रूरी है

    • मैं भी boilerplate से बचने के लिए wrapper की मदद से Web components इस्तेमाल कर रहा हूँ
      इस तरीके से मुझे बहुत कम मेहनत में Web components की 80% क्षमता मिल गई
      संबंधित GitHub: ZjsComponent, और पुरानी HN चर्चा भी देखें (HN चर्चा)
      यह परफेक्ट नहीं है, लेकिन मेरे लिए नए HTML components बनाने का इससे आसान और तेज़ तरीका नहीं है

    • अगर React Native जैसी कोई बराबर की alternative नहीं है, तो सिर्फ Web components काफ़ी नहीं होंगे
      Browser technology अभी native apps के स्तर तक पहुँचने जितनी तेज़ नहीं है
      React की सबसे बड़ी value यह है कि वह platforms के पार GUI development को एकीकृत कर सकता है

    • मैंने lit Web components से business apps बनाए हैं
      हर property का string type होना पड़ता था, जो काफ़ी असुविधाजनक था, और यह real-time केंद्रित component libraries की बराबरी नहीं कर पाता था

    • हमारी बड़ी कंपनी में internal apps के लिए central React library का इस्तेमाल अनिवार्य है
      यह "React क्योंकि डिफॉल्ट है" नहीं, बल्कि "सिर्फ React ही इस्तेमाल कर सकते हैं" वाली स्थिति है
      मुझे लगता है कि रास्ता यह है कि central library को Web components में फिर से implement किया जाए, ताकि मनचाहा framework इस्तेमाल किया जा सके

    • क्या किसी ने React UI library में Web components का अच्छा इस्तेमाल किया है?
      किसी खास design system के लिए component library बनाते समय RAC जैसी headless libraries पर निर्भर रहना मुझे संतोषजनक लगता है
      मुझे समझ में आता है कि Web components पूरक हो सकते हैं, लेकिन व्यवहार में उनका सबसे अच्छा उपयोग कहाँ है, यह अभी साफ़ नहीं है

  • दरअसल यह लेख React की performance के बारे में नहीं, बल्कि इस बात के बारे में है कि alternatives की तुलना में उसके "social benefits" इतने बड़े हैं कि दूसरे विकल्प अपनाना कठिन हो जाता है
    यानी React तकनीकी रूप से बहुत अलग न भी हो, फिर भी वह default choice बन गया, और network effects तकनीकी suitability से ज़्यादा निर्णयों को प्रभावित करते हैं — इससे मैं सहमत हूँ
    फिर भी teams के लिए React के स्पष्ट फायदे alternatives पर बने रहते हैं
    असल में ज़्यादातर सक्षम teams अच्छी तरह समझती हैं कि उन्हें सिर्फ सचमुच अपवाद वाले मामलों में ही कोई दूसरा विकल्प अपनाना चाहिए

    • मैंने कई कंपनियों और startups में tech stack के फ़ैसलों में हिस्सा लिया है, लेकिन React चुनने की वजह के रूप में मैंने कभी "framework की अपनी खूबियाँ" नहीं सुनीं
      फ़ैसला हमेशा familiarity, hiring की आसानी, और ecosystem के आधार पर हुआ

    • लोग मान लेते हैं कि web developers तर्कसंगत निर्णय लेते हैं, लेकिन मेरे अनुभव में ऐसा नहीं है
      इंसान "social proof", "authority" जैसी मानवीय biases से आसानी से प्रभावित हो जाते हैं

    • मैंने कभी किसी को यह कहते नहीं सुना कि "React अच्छा है इसलिए इस्तेमाल करते हैं"
      हमेशा वजह यही होती है कि "hiring आसान है"

    • React जटिल समस्याएँ सुलझाने में मज़बूत है
      लेकिन हर समस्या जटिल नहीं होती, और अगर जटिल tools को default बना दिया जाए तो वे projects में अनावश्यक complexity और कम flexibility ला सकते हैं
      पुरानी या भविष्य की features के कारण maintain किए जाने वाले ecosystem की अस्थिरता भी केवल React तक सीमित समस्या नहीं है
      आगे चलकर मैं उम्मीद करता हूँ कि अभी की पीढ़ी के web app paradigms से आगे कोई नया प्रवाह आएगा

  • frontend monoculture (React monopoly) को लेकर चिंतित होने की वजहें हैं, लेकिन दिलचस्प बात यह है कि 10 साल पहले स्थिति बिल्कुल उलटी थी
    हर हफ़्ते HN पर नए frameworks आ जाते थे, Angular 1.x से 2.0 तक का भ्रम था, और "JavaScript fatigue" जैसा शब्द भी चल पड़ा था, इतना कठिन frontend development हो गया था
    अब React साफ़ तौर पर standard बन गया है, और इससे चैन से service development पर ध्यान दिया जा सकता है
    मैं React की पूजा नहीं कर रहा (मुझे भी hooks ख़ास पसंद नहीं), लेकिन शुक्र है कि अब 2015 जैसा समय नहीं है
    अब समय के साथ माहौल फिर बदलता दिख रहा है, यह देखना दिलचस्प है

  • मुझे वह दौर याद है जब पागलों की तरह अलग-अलग boutique JavaScript libraries भरी पड़ी थीं
    React का mainstream होना अपने-आप में एक तरह की जीत है
    "innovation" जैसे धुंधले विचार के लिए किसी परिचित और स्थिर चीज़ को ज़बरदस्ती छोड़ देना सही नहीं लगता

  • इससे सच में जुड़ाव महसूस होता है
    2009~2015 तक मैंने काफ़ी अग्रणी ढंग से browser में native app जैसी UX वाली चीज़ें बहुत बनाई थीं
    मेरी ताकत web standards और उनका अधिकतम सीधा इस्तेमाल था, लेकिन बाद में मैं backend की ओर चला गया और React के उभार को दूर से देखता रहा
    React मुझे अक्षम सा लगता था, और JSX की "सब कुछ expression होना चाहिए" वाली सीमा भी परेशान करती थी
    फिर भी मैं मानता हूँ कि React ने state management में एक महत्वपूर्ण paradigm shift लाया
    पुराने state model से एक-तरफ़ा immutable data flow की ओर जाना कठिन था, लेकिन आख़िरकार वह सार्थक साबित हुआ
    वह एक अव्यवस्थित दौर था, लेकिन React ने innovation और web app design के बारे में सोचने के तरीके में बड़ा बदलाव किया — यह सच है
    लेकिन आज SolidJS से तुलना करें तो वही फायदे Solid ज़्यादा संक्षेप में, बेहतर performance के साथ और कहीं आसान manageability के साथ देता है
    यह JSX, server components, reactive state management भी बेहतर देता है, और React developers भी आसानी से उस पर जा सकते हैं
    App structure को लेकर सोचने का तरीका भी लगभग वैसा ही है, इसलिए React से जो लगभग सारे व्यावहारिक फायदे मिलते हैं, वे वहाँ बेहतर, तेज़ और बहुत छोटे bundle size के साथ मिल जाते हैं
    फिर भी पूरा बाज़ार React की ओर झुका हुआ है, इसलिए मजबूरी में उसी का इस्तेमाल करना पड़ता है

    • SolidJS में भी अभी दर्द वाले हिस्से हैं
      सबसे बड़ी समस्या यह है कि यह सहज रूप से समझना मुश्किल है कि कोई prop signal है या नहीं
      Type system भी इसमें बहुत मदद नहीं करता
      React में अगर reference बदलता है तो साफ़ है कि prop पाने वाली जगह फिर render होगी, लेकिन Solid में यह अस्पष्ट हो सकता है कि बदलाव observe होगा या नहीं

    • मुझे लगता है ज़्यादातर लोग उसी चीज़ से संतुष्ट रहते हैं जो उन्हें पहले से आती है
      बहुत से developers React को मजबूरी में इस्तेमाल नहीं करना चाहते, लेकिन आख़िरकार वही इस्तेमाल करते हैं जिसे वे सबसे बेहतर जानते हैं
      समय सीमित है, और परिवार, hobbies या जीवन की दूसरी प्राथमिकताओं के लिए efficient चुनाव करना पड़ता है

    • React से बँधे रहना ज़रूरी नहीं है
      मेरी कंपनी का (लगभग अकेले मेरे द्वारा) पिछले 10 साल में बनाया गया एक framework भी है, जिसे MIT license के तहत open source किया गया है
      Q.js लिंक
      इस पर राय जानना चाहूँगा

  • Hooks ने class components की कमियों को दूर किया, लेकिन साथ में नई complexity भी लाई (dependency arrays, stale closures, overuse आदि)
    लेकिन ये समस्याएँ सिर्फ hooks की वजह से नहीं हैं; class-based components के दौर में भी ये मौजूद थीं
    Dependency arrays से जुड़ी दिक्कतों जैसी bugs पहले भी props या state changes छूट जाने से आम थीं
    Stale closure वही समस्या setState के दूसरे argument में भी आती थी
    Lifecycle methods (componentDidMount, componentWillMount आदि) का overuse भी बहुत होता था
    मुझे लगता है "Effect सिर्फ तभी इस्तेमाल करो जब वाकई ज़रूरत हो" जैसी documentation की ज़रूरत पहले भी थी
    Hooks गलतियाँ करने के मौके कम करते हैं, उन मौकों की पहचान आसान बनाते हैं, और warnings भी देते हैं, इसलिए उन्होंने निश्चित रूप से सुधार में योगदान दिया है

    • dependency arrays की समस्या eslint में react-hook rules इस्तेमाल करने से बहुत आसानी से हल हो जाती है

    • prop testing में fast-check का इस्तेमाल करने से छोटे-मोटे बदलाव होने पर bugs रोकने में बहुत मदद मिलती है

  • JavaScript community को शायद कुछ साल innovation रोक देना चाहिए
    बहुत innovation हुआ, लेकिन उसमें substance कम था
    अब browsers को web के लिए समझदारी भरा component development support देना चाहिए
    अगर browser स्तर पर backend-supported combobox या standard date picker जैसा कुछ मिल जाए, तो हर बार इन बुनियादी UI controls की state management के लिए नई innovation के पीछे भागना नहीं पड़ेगा

    • मुझे लगता है समस्या यह भी है कि browser अब अपनी मूल भूमिका ठीक से नहीं निभा रहे
      Chrome के ज़रिए Google के पास लगभग monopoly जैसी प्रभावशाली शक्ति है, इसलिए web standards में भी वही चीज़ें आगे बढ़ती हैं जिनमें Google रुचि ले और resources लगाए
      Safari और Firefox कुछ हद तक संतुलन बनाते हैं, लेकिन अगर platform को सच में अलग और बेहतर दिशा में विकसित होना है, तो किसी को नेतृत्व लेकर आगे बढ़ाना होगा
      आख़िरकार platform-level support न मिलने के कारण JS दुनिया को NAND chip पर तार जोड़ने जैसी hacks करते रहना पड़ता है

    • मुझे लगता है हाल के browsers और CSS ने लगातार उन use cases को बेहतर किया है या सुलझाया है जिनके लिए परंपरागत रूप से JS पर निर्भर रहना पड़ता था
      यह रुझान और फैलना चाहिए

    • शायद shopping, banking, social वगैरह जैसी 5~6 तरह की browsers के बारे में भी सोचना चाहिए
      ऐसा हो कि services backend में innovation पर प्रतिस्पर्धा करें, और frontend उपयोगकर्ताओं को एक समान अनुभव दे — इससे ज़्यादा फ़ायदा होगा
      हर कंपनी का बार-बार लगभग वही frontend अलग से बनाना बहुत बड़ी बर्बादी है
      एक sandwich shop को बेहतर sandwich बनाने में प्रतिस्पर्धा करनी चाहिए; सिर्फ app install करने वाले 8% users को छीनने के लिए लगभग एक जैसा frontend बनाना असली बात नहीं है

    • सच कहूँ तो इतने जटिल platform (HTML/CSS/JS) के ऊपर frameworks ने जो हासिल किया है, वह हैरान करने वाला है
      'web' की बनावट दस्तावेज़/पाठ और साधारण forms पर केंद्रित होने के समय के लिए ठीक थी; अब जटिल interactive apps के लिए यह बहुत अनुपयुक्त आधार है
      कभी न कभी इसे पूरी तरह से नए सिरे से बनाना होगा

  • React इसलिए नहीं जीता कि वह "सबसे बेहतरीन" था, बल्कि इसलिए कि वह "safe default" बन गया
    सबको React आता है, hiring आसान है, ecosystem बड़ा है, इसलिए वही सबसे स्थिर विकल्प बन गया
    इससे innovation घट जाती है, और Svelte या Solid जैसे हल्के alternatives को लोग आज़माने की भी कोशिश नहीं करते
    React अभी भी अच्छा काम करता है, लेकिन मेरा मानना है कि व्यवहार में इसे suitability से ज़्यादा inertia की वजह से इस्तेमाल किया जाता है

    • Silicon Valley पर यह मज़ाक भी किया जा सकता है कि वहाँ लोग हमेशा बहुत तेज़ी से ट्रेंड पर चढ़ जाते हैं
 
pweasd 2025-09-19

मैं लेखक की राय से सहमत हूँ। लेकिन React इस्तेमाल करने की जड़ता उतनी गलत भी नहीं है जितनी कही जाती है। अगर आपके बताए Svelte जैसे विकल्प iPhone 17 हैं, तो React को मैं लगभग iPhone 15 या 16 मानूँगा। लागत के मुकाबले यह अब भी काफ़ी काम का है, और इसे बदलने की कोई खास ज़रूरत महसूस नहीं होती। फ्रंटएंड के बड़े उथल-पुथल वाले दौर में हमने React को चुना, यह लेखक की राय से अलग किसी सचेत फैसले का नतीजा नहीं था। कई चीज़ें इस्तेमाल करते-करते React सबसे ज़्यादा उपयोगी लगा, इसलिए वही चुना जाता रहा। भविष्य में अगर React असुविधाजनक लगने लगे और कुछ और ज़्यादा उपयोगी दिखे, तो मुझे लगता है कि बिना जानबूझकर चुनौती लेने या प्रयोग करने के भी स्वाभाविक रूप से बदलाव आ जाएगा।
 
dokdo2005 2025-09-17

VHS और Betamax के आमने-सामने हुए वीडियो टेप standard war के उदाहरण को देखें, तो लगता है कि तकनीकी रूप से बेहतर होना हमेशा यह तय नहीं करता कि बाज़ार आखिर किसे चुनता है।
 
savvykang 2025-09-18

क्या फ्रंटएंड में ज़रूरत से ज़्यादा इनोवेशन करके समस्या नहीं पैदा की जा रही है?
 
shakespeares 2025-09-18

मैं कुछ हद तक सहमत हूँ.
बैकएंड में spring boot framework के electronic government framework तक बनने की प्रक्रिया में भी यह स्पष्ट है कि जब कोई format बन जाता है तो productivity बढ़ती है, इसलिए मुझे लगता है कि React भी शायद उसी तरह के रूप में बदलता जा रहा है.
 
savvykang 2025-09-18

हाँ, मेरा मानना है कि React की अहमियत इस बात में है कि उसने component-आधारित डिज़ाइन और rendering behavior को स्थापित किया, जिसे काफ़ी बड़ा बहुमत समझता है। लेकिन React अपने आप में web app बनाने के लिए एक low-level framework है, इसलिए अच्छा होता अगर यह कम-से-कम router और form जैसी चीज़ें basic रूप से देता। और state तथा effect के मामले में, अगर deep comparison डिफ़ॉल्ट रूप से supported होता और logic को सिर्फ़ structs और functions से लिखा जा सकता, तो कैसा होता—यह भी सोचता हूँ। JavaScript की shallow comparison वाली पाबंदी की वजह से custom hook syntax में classes लिखनी पड़ती हैं।
 
preserde 2025-09-22

लो-लेवल... कहना भी मुश्किल है... फ़ॉर्म implement करने के लिए सिर्फ़ HTML input टैग इस्तेमाल करने से काम चल सकता है, लेकिन state, jsx, uncontrolled/controlled components जैसी चीज़ें बेवजह बहुत ज़्यादा जाननी पड़ती हैं और बहुत सारा कोड भी लिखना पड़ता है, इसलिए शायद यही बातें मूल लेख की प्रेरणा बनी होंगी।
 
indigoray 2025-09-18

सहमत हूँ