2025 का React vs. Backbone

• 2010 के दशक की शुरुआत के Backbone और 2025 के React की तुलना करते हुए यह चर्चा देखती है कि 15 वर्षों में फ्रंटएंड विकास ने वास्तव में कितनी प्रगति की है
• React ऊपर से संक्षिप्त और आधुनिक दिखता है, लेकिन अंदरूनी तौर पर जटिल abstraction layers के जरिए सरलता का आभास देता है
• Backbone में कोड लंबा-चौड़ा है, लेकिन event flow और DOM manipulation स्पष्ट होने से शुरुआती डेवलपर भी व्यवहार को आसानी से ट्रैक कर सकते हैं
• React में state management, dependency arrays, closure issues जैसी वजहों से आंतरिक कामकाज समझे बिना debugging कठिन हो जाती है
• अंततः यह “event + state = UI” के मूल विचार को फिर याद दिलाते हुए, सरलता और hackable संरचना वाले नए मॉडल की ज़रूरत उठाता है

---

15 वर्षों की प्रगति

• एक उदाहरण password input का है, जिसमें एक implementation 2010s framework (Backbone) में और दूसरा 10 साल से अधिक विकसित हुए React में लिखा गया है
  • दोनों code implementations की लंबाई लगभग समान है और functionality भी एक जैसी है
  • React को असंख्य डेवलपर-घंटों और विशाल ecosystem का समर्थन मिला है
  • फिर भी लेखक के अनुसार “React कितना बेहतर हुआ” से ज़्यादा दिलचस्प सवाल है “यह कितना कम विकसित हुआ”
• React ऊपरी सरलता का भ्रम देता है, लेकिन वास्तव में जटिल abstraction के कारण इसे समझना कठिन है
  • Backbone event trigger → handler execution → HTML generation → DOM insertion जैसी सीधी flow को स्पष्ट रूप से दिखाता है
  • वहीं React अंदरूनी कामकाज छिपा देता है, और साधारण examples से आगे बढ़ते ही ऐसी समस्याएँ आती हैं जिन्हें हल करने के लिए internal mechanism समझना ज़रूरी हो जाता है

सरलता का भ्रम (The Illusion of Simplicity)

• React का code साफ-सुथरा दिख सकता है, लेकिन यह explicit simplicity की जगह abstract complexity चुनने का परिणाम है
  • Backbone लंबा है, लेकिन “क्या हो रहा है और कब हो रहा है” यह साफ दिखाता है
  • शुरुआती डेवलपर भी code flow को आसानी से ट्रैक कर सकते हैं
• React में internal state और rendering logic छिपे रहते हैं, इसलिए unexpected bugs अक्सर आते हैं
  • उदाहरण: list item की key को index में बदलने पर React उसे अलग component मानकर state reset कर सकता है
  • value अगर undefined हो जाए तो uncontrolled → controlled component transition के कारण input reset हो सकता है
• useEffect के साथ infinite loop बन जाना भी आम है
  • अगर dependency array में ऐसा object हो जो हर render पर नया बनता है, तो React उसे बदलाव मानता है
  • इसे रोकने के लिए useMemo, useCallback से identities को stabilize करना पड़ता है
  • यानी ऐसे concepts पर भी ध्यान देना पड़ता है जिनकी पहले ज़रूरत नहीं होती थी
• click handler के stale state को refer करने की समस्या भी होती है
  • क्योंकि function बनते समय की state capture हो जाती है
  • समाधान के लिए state को dependency array में डालना पड़ता है, या setState(x => x + 1) जैसे functional updates का उपयोग करना पड़ता है
  • लेकिन दोनों तरीके कुछ हद तक workaround जैसे लगते हैं

जादू की कीमत बहुत अधिक है (Magic Has a High Price)

• ये समस्याएँ कोई अपवाद नहीं हैं, बल्कि मध्यम आकार या उससे बड़े apps में आम तौर पर दिखने वाली समस्याएँ हैं
  • debugging के लिए reconciliation algorithm, render phase, scheduler (batch update) की समझ चाहिए
  • React ऐसी संरचना है जो “यह क्यों काम करता है जाने बिना भी काम करती है”, लेकिन समस्या आने पर अंदरूनी चीज़ें जाने बिना समाधान संभव नहीं होता
• React को सच में समझने के लिए उसे खुद बनाकर देखना चाहिए — यह बात इसकी जटिलता दिखाती है
  • “Build your own React” जैसे tutorial मौजूद हैं
  • लेकिन सिर्फ एक साधारण password validator बनाने के लिए virtual DOM, scheduling priority, concurrent rendering समझना पड़े — यह अपने आप में एक आलोचनात्मक संकेत है
• Backbone और jQuery की संरचना ईमानदार और hackable है
  • source code सीधे देखा और बदला जा सकता है
  • DOM methods पर आधारित होने से समझना और बढ़ाना आसान है
  • इसके उलट React की abstraction layers अंदर पहुँच और बदलाव को कठिन बना देती हैं

अगला कदम क्या है (So, What's Next?)

• आखिरकार React और Backbone दोनों “event + state = UI” की एक ही समस्या को हल करने की कोशिश हैं
• बड़े apps में React की जटिलता जायज़ हो सकती है, लेकिन ज़्यादातर छोटे और मध्यम आकार के apps के लिए यह अनावश्यक बोझ है
• सरलता और पारदर्शिता वाला एक नया UI model चाहिए
  • DOM की तरह मज़बूत लेकिन सहज system
  • Backbone या jQuery की तरह तुरंत समझ में आने वाली और बदली जा सकने वाली संरचना की दिशा में

[shakespeares]

छोटे और मझोले ऐप्स में Backbone या JQuery की बजाय JavaScript Class को डिज़ाइन करना आगे के लिए तैयारी करने जैसा लगता है.
JQuery या Backbone में मौजूद templates को फिर से याद करके आगे बढ़ना पीछे जाने जैसा लगता है.

[GN⁺]

Hacker News राय

• Backbone, Angular 1, Ember, और React सब इस्तेमाल किए हैं
  यह नज़रअंदाज़ नहीं करना चाहिए कि React लोकप्रिय क्यों हुआ। component composition, event handling, state management, efficient DOM updates जैसी चीज़ों में React ने पुराने frameworks की पुरानी समस्याएँ हल कीं
  Backbone में DOM lifecycle manage करना जटिल था, और event handlers को string के रूप में लिखना पड़ता था, इसलिए maintenance मुश्किल हो जाता था। React ने one-way state flow और virtual DOM से इन समस्याओं को सरल बनाया
  अगर आज pure JS इस्तेमाल करना हो, तो Backbone की तुलना में lit-html जैसी template solution कहीं बेहतर लगेगी

  • लगता है उदाहरण यथार्थवादी नहीं है। तुलना करनी हो तो TodoMVC एक प्रतिनिधि उदाहरण है। Backbone version में यह code देखें तो maintenance nightmare जैसा है। React version(link) कहीं ज्यादा स्पष्ट है
    frontend पहले भी जटिल था और अब भी जटिल है, लेकिन अब यह बहुत कम पीड़ादायक है
  • सहमत। React भी परफेक्ट नहीं है, लेकिन आखिरकार यह trade-off का मामला है। कोई भी tool इस्तेमाल करें, developer को उसकी complexity संभालनी ही पड़ती है। असली बात यह है कि क्या हम सही trade-off चुन रहे हैं
  • आजकल React के अलावा भी ऐसे features देने वाले कई frameworks हैं। यह सिर्फ React की विशेषता नहीं है

• ऐप की complexity components की संख्या से नहीं, बल्कि state management से आती है
  Backbone Store के two-way data flow की वजह से UI freeze होने की समस्या अक्सर देखी। React की असली innovation one-way data flow पर आधारित Flux architecture थी
  मेरा मानना है कि अच्छा framework वह tool है जो आपको स्वाभाविक रूप से “success की खाई (Pit of Success)” की तरफ ले जाए। React ने यह भूमिका अच्छी तरह निभाई है

  • React/Flux/Redux से पहले frontend development सच में अराजक था। 1000 lines से कम code में भी state management की समस्याएँ फूट पड़ती थीं
  • मैं ही लेख का लेखक हूँ। one-way data flow ने समस्याएँ हल कीं, यह सही है, लेकिन React अपने साथ नई complexity भी लाया
    उदाहरण के लिए stale closure, infinite useEffect loop, key बदलने से input reset हो जाना जैसी समस्याएँ Backbone में नहीं थीं
    Backbone की समस्याएँ सामने दिखती थीं और debug करना आसान था, लेकिन React की समस्याएँ abstraction के पीछे छिपी रहती हैं
    ज़्यादातर apps Facebook के scale पर नहीं होते, इसलिए explicit और simple approach कई बार बेहतर हो सकती है
  • Angular लंबे समय तक करने के बाद React पर लौटा, और भले यह परफेक्ट न हो, React developer को सही दिशा में code लिखने के लिए प्रेरित करता है
  • component खुद भी एक अलग complexity है। markup, events, business logic, accessibility सब एक साथ बंधकर बहुत बड़ा ढाँचा बन जाते हैं। आखिरकार यह सुविधा के लिए complexity है, simplicity मुफ्त में नहीं मिलती
  • “one-way data flow” क्या असल में DOM के default behavior जैसा नहीं है? React team ने Flux बनाया था, Flow नहीं

• किसी लोकप्रिय technology को सीधे “खराब” घोषित करना एक तरह की भोली अहंकारिता जैसा लगता है
  लोकप्रियता quality की गारंटी नहीं है, यह सही है, लेकिन यह मान लेना कि दुनिया भर के बेहतरीन engineers सब धोखा खा गए, यह भी अतिशयोक्ति है

  • लोकप्रिय technology हमेशा सही नहीं होती। MongoDB, Kafka, Microservice के trends याद करिए
    जब बड़ी कंपनियाँ और marketing इसे push करते हैं, तो CTOs इसे adopt करते हैं, और जब career दाँव पर हो तो कोई “यह खास नहीं है” कहने की हिम्मत नहीं करता। लोकप्रियता ≠ उपयुक्तता
  • मैं ही लेखक हूँ। “paleo influencer” वाली उपमा दिलचस्प है, लेकिन नया होना हमेशा अच्छा होना नहीं है
    React सिर्फ technical superiority से नहीं जीता, बल्कि Facebook की marketing और ecosystem के self-reinforcement की वजह से भी जीता
    15 साल बाद भी code की लंबाई या complexity बहुत कम नहीं हुई है। बस complexity का रूप बदल गया है
    अतीत की ओर देखना nostalgia के लिए नहीं, बल्कि यह जाँचने के लिए है कि क्या हमने अनुपातहीन complexity जोड़ दी है
  • React या Tailwind की ताकत hiring friendliness है। तकनीकी पूर्णता से ज़्यादा वजह onboarding की आसानी है
    web अब भी design patterns का wild west जैसा है। इसे स्वीकार करने के बाद मन हल्का हो गया
  • React को सीधे “मूर्खतापूर्ण” कहना अहंकार और अज्ञान का मिश्रण लगता है। लाखों developers इसे किसी वजह से इस्तेमाल करते हैं। पूरी तरह खारिज करना Chesterton’s Fence को नज़रअंदाज़ करने जैसा है
  • इसे अहंकार कहना ज़रूरी नहीं, यह अलग नज़रिए का अनुभव भी हो सकता है। कुछ लोग React ecosystem पसंद करते हैं, कुछ लोग JS की अधिक मात्रा की वजह से उसे नापसंद करते हैं
    आखिरकार हर project में trade-offs का पुनर्मूल्यांकन करना पड़ता है

• “सरल कामों के लिए React की ज़रूरत नहीं” वाला दावा एक आम React fallacy है
  React को simple examples से आँकना वैसा है जैसे “Hello World की लंबाई से किसी language का मूल्यांकन करना”
  सरल कामों में भी React इसलिए इस्तेमाल होता है, क्योंकि जटिल कामों में भी वही इस्तेमाल होता है। consistent toolset maintenance के लिए फायदेमंद होता है

  • “जटिल कामों के लिए इस्तेमाल करते हैं, इसलिए सरल कामों में भी” यह कुछ वैसा है जैसे truck से सब्ज़ी खरीदने जाना। आखिरकार उपयुक्त tool का चयन ही मुख्य बात है

• Backbone “framework जैसा दिखता था, लेकिन असल में glue code का ढेर” था
  React की असली जीत यह थी कि DOM को सीधे manipulate करने की ज़रूरत नहीं रही, और reactive state management संभव हुआ। इन दो बातों ने developer productivity को काफी बढ़ाया

  • पहले Backbone tutorials बहुत लिखने वाले व्यक्ति के रूप में थोड़ी nostalgia है
    पुराना tutorial link, archive version
    आजकल ज़्यादा दिलचस्पी इस बात में है कि LLM code को कैसे समझता है। JSX जैसी declarative syntax, LLM-friendly है
    लेकिन useEffect के बाद वाला React expressiveness और explicitness के मामले में उल्टा कुछ धुंधला-सा लगने लगा है
  • Marionette ने Backbone के boilerplate को काफी कम किया था
  • यह सवाल भी उठा कि क्या React में built-in state management है

• इससे साफ़ दिखता है कि React लोकप्रिय क्यों हुआ
  React code ज़्यादातर pure JS और HTML है, और इसकी core चीज़ बस useState है। यह इतना intuitive है कि documentation के बिना भी समझा जा सकता है
  Backbone .space-y-2 जैसी string selectors पर निर्भर था, इसलिए maintenance नरक बन जाता था। एक class name बदलते ही आधा app टूट जाता था
  React ने इस समस्या को संरचनात्मक रूप से हल किया

  • मज़ाक में कहा गया कि “वह लेख खुद नहीं लिखा गया, शायद Claude से लिखवाया गया है”

• Backbone code में “क्या कब होता है” साफ़ दिखता है, लेकिन React में internal behavior समझना पड़ता है
  React के timing behavior को समझने के लिए मैंने भी Dan Abramov की useEffect guide और Mark Erikson का blog कई बार पढ़ा है
  Backbone code 10 साल बाद भी देखकर तुरंत समझ आ गया

• 6 साल पहले टीम को Backbone से Angular पर ले गया था
  Backbone intuitive और बिना किसी magic वाला structure होने की वजह से juniors के लिए अच्छा था, लेकिन आखिरकार TypeScript और Angular ज़्यादा व्यवस्थित साबित हुए
  अभी NG20 इस्तेमाल कर रहा हूँ और संतुष्ट हूँ। शायद कभी browser और ज़्यादा features built-in देने लगे, तो फिर से simple approach की ओर लौटा जा सके

• हम हमेशा abstractions के ऊपर programming कर रहे होते हैं
  असली बात यह है कि क्या वह abstraction complexity के मुकाबले productivity gain देता है, और क्या वह विश्वसनीय है
  सबसे खराब स्थिति में भी उसे debug किया जा सकना चाहिए

• React का input field Backbone की तुलना में Undo behavior को ज़्यादा स्वाभाविक रूप से handle करता है
  Backbone एक-एक अक्षर पीछे ले जाता है, जबकि React शब्द-स्तर पर undo करता है

  • समझ नहीं आता कि browser के default behavior को override करना बेहतर क्यों माना जाए। यह तो उल्टा natural scroll बिगाड़ने वाली JS library जैसा लगता है
  • दिलचस्प बात यह है कि Chrome में यह अलग है, लेकिन Firefox में दोनों frameworks एक ही तरह behave करते हैं
  • मुझे Backbone का तरीका बेहतर लगता है
  • कौन-सा behavior “सही” है, यह आखिरकार व्यक्तिगत पसंद का मामला है