अगर React नहीं, तो फिर क्या इस्तेमाल करें?

 (infrequently.org)
11 पॉइंट द्वारा GN⁺ 2024-12-01 | 12 टिप्पणियां | WhatsApp पर शेयर करें

> "Frameworkism (फ्रेमवर्कवाद) अब काम नहीं करता। जवाब कोई दूसरा टूल नहीं, बल्कि इंजीनियरिंग करने का साहस है"

  • पिछले 10 वर्षों में, डेस्कटॉप और मोबाइल वेब के लिए विभिन्न प्रोडक्ट्स और टेक स्टैक्स के साथ 100 से अधिक प्रोजेक्ट्स का अनुभव
  • बहुत सा समय web API सुधारने के बजाय React जैसे फ्रंटएंड फ्रेमवर्क से पैदा हुई performance और accessibility समस्याओं को ठीक करने में खर्च हुआ
  • React पहले से ही legacy तकनीक है, फिर भी इसे नए प्रोजेक्ट्स में अपनाया जा रहा है
  • कुछ लोग React को "modern" बताते हैं, लेकिन यह बस पुराने तरीकों को दोहराना है

न्यूनतम client-side complexity का नियम

  • server-side code डेवलपर्स के नियंत्रण में होता है, इसलिए performance और availability को प्रभावी ढंग से संभाला जा सकता है
  • client-side code ऐसे विविध environments में चलता है जो डेवलपर के नियंत्रण में नहीं होते, इसलिए reliability और performance की गारंटी देना कठिन है
  • सबसे अच्छी रणनीति है client को भेजे जाने वाले code की मात्रा कम करना
    • JavaScript पर निर्भरता कम करने के लिए HTML और CSS को प्राथमिकता दें
    • React और इसी तरह के फ्रेमवर्क अनावश्यक code duplication और performance degradation पैदा करते हैं

तो फिर विकल्प क्या है?

चर्चा दो सवालों में बंटती है

  • संकीर्ण सवाल: "अगर client rendering की ज़रूरत हो, तो React की जगह कौन-सी तकनीक इस्तेमाल की जाए?"
    • आधुनिक frameworks (जैसे Svelte, Lit, FAST, Solid, Qwik, Marko, HTMX, Vue, Stencil आदि) पर विचार करना सार्थक हो सकता है
    • लेकिन इन frameworks का उपयोग करते समय भी client-side payload और complexity को सख्ती से नियंत्रित करना होगा। HTML/CSS की तुलना में JavaScript की लागत कम-से-कम 3 गुना अधिक है
  • विस्तृत सवाल: "अगर React-आधारित tech stack की पूरी तरह समीक्षा करनी हो, तो कैसे करें?"
    • बात सिर्फ किसी नए टूल से बदलने की नहीं है, बल्कि मौजूदा architecture के उद्देश्य और सीमाओं को समझकर उसे फिर से डिज़ाइन करने की है

संकीर्ण सवाल के लिए दृष्टिकोण

  • performance scalability और सीमाओं का आकलन करने के लिए कई छोटे PoC (Proof of Concept) बनाएं
  • ऐसे objective experiments टीम सदस्यों को अर्थपूर्ण engineering अनुभव देते हैं

विस्तृत सवाल पूछने वाली टीमों की आम स्थिति

  • React को बदलने की चर्चा में टीमें अक्सर भ्रमित महसूस करती हैं
    • ज़्यादातर निर्णय मौजूदा architecture का अनुसरण करते हुए लिए गए होते हैं
    • user experience की स्पष्ट समझ और data-driven decision-making की कमी

फ्रेमवर्कवाद और user-centered approach में अंतर

  • फ्रेमवर्कवाद: यह विश्वास कि फ्रेमवर्क में और features जोड़ देने से हर समस्या हल हो जाएगी
    • वास्तव में, इससे अक्सर users की समस्याएँ हल नहीं होतीं
    • अनियमित patterns या data-based evidence को नज़रअंदाज़ किया जाता है
  • यथार्थवाद: user experience को मापा जाता है और वास्तविक data के आधार पर निर्णय लिए जाते हैं
    • users की ज़रूरतों और constraints को समझकर उसी आधार पर tech stack डिज़ाइन किया जाता है
    • शुरुआती बिंदु हमेशा user requirements होती हैं

यथार्थवाद अपनाने के तरीके

  • RUM data का उपयोग: Core Web Vitals जैसे user-centered performance metrics का उपयोग करें
  • performance testing: WebPageTest (WPT) जैसे टूल्स से प्रमुख user paths (critical user journeys) को मापें
  • business goals और user experience को जोड़ें: data के माध्यम से सुधार की दिशा और निवेश के मुकाबले प्रभाव का मूल्यांकन करें

data-driven approach का महत्व

  • भरोसे के आधार पर framework अपनाने के बजाय, data से उसके प्रभाव की पुष्टि करें
  • trends के आधार पर तकनीक अपनाने की वास्तविक लागत और प्रभाव की तुलना करें
  • मापे जा सकने वाले metrics के जरिए user experience optimization पर केंद्रित तकनीकी चयन को बढ़ावा दें

कोई भी मूल्यवान चीज़ नहीं खोई गई

React के फैलाव को रोकने वाली नीतियों का प्रभाव

  • React और अन्य framework-centric approaches पर रोक लगाना cost reduction और user-centered टीम पुनर्संरचना में मदद कर सकता है
  • लेकिन अगर फ्रेमवर्कवाद को पूरी तरह बाहर नहीं किया गया, तो मूलभूत performance improvement हासिल करना कठिन रहेगा
  • एक गलती से बचकर उसी श्रेणी की दूसरी गलती में निवेश करने पर प्रभाव सीमित रहेगा

बड़े सवाल के सामान्य समाधान

user-centered

  • decision-makers को अपनी engineering choices के परिणामों की सीधे जवाबदेही लेनी चाहिए
  • बिना बहाने, अगर system users—खासतौर पर वंचित users—के लिए अच्छी तरह काम नहीं करता, तो alternative version लागू किया जाना चाहिए
  • केवल वही समस्याएँ मान्य हैं जिन्हें हल करना है; पुराने तरीकों को बिना सवाल के पकड़े रहने वाली "पवित्रीकरण" मानसिकता को बाहर किया जाना चाहिए

evidence-based approach

  • management और engineering के बीच साझा यथार्थवादी प्रतिबद्धता आवश्यक है
  • decision-making में बेहतर evidence को हमेशा प्राथमिकता मिलनी चाहिए

guardrails

  • फ्रेमवर्कवाद के भ्रमपूर्ण दावों को रोकने के लिए नीतियों की ज़रूरत है
  • उदाहरण: UK Government Digital Service की progressive enhancement तकनीकी आवश्यकताएँ
    • संगठन की परिस्थिति के अनुसार नीतियों को समायोजित किया जा सकता है (जैसे exception cases के लिए escalation path बनाना)
    • लेकिन महत्वपूर्ण बात है स्पष्ट मानक तय करना। evidence-based policies शक्तिशाली प्रभाव डालती हैं

तकनीकी comparative evaluation

  • स्पष्ट रूप से परिभाषित मुख्य user paths (critical user journeys) के बिना कोई नया system deploy न करें
  • मुख्य user paths वे काम दर्शाते हैं जिन्हें users system में सबसे ज़्यादा करते हैं
  • इसके आधार पर constraints के तहत हर तकनीक के परिणामों का परीक्षण करने वाले comparative evaluations (bakeoffs) करें
    • product managers को सिर्फ बिना दिशा वाले experiments सुझाने से आगे बढ़कर, product की स्पष्ट hypothesis और success criteria तय करनी चाहिए
    • यह असुविधाजनक प्रक्रिया हो सकती है, लेकिन यही product manager की मुख्य भूमिका है
    • जो PM इसे अपने काम के अनुरूप नहीं मानते, उनके इस्तीफ़े को भी स्वीकार किया जाए

case study

यथार्थवाद और फ्रेमवर्कवाद का अंतर: उदाहरणों से समझें

  • तकनीक चुनने के मानदंड
    • तकनीक का चयन मुख्य data updates की संख्या और session length के आधार पर आंका जाना चाहिए
    • कुछ app classes लंबी sessions और बार-बार data updates की विशेषता रखते हैं
      • ऐसे मामलों में local data model उपयुक्त हो सकता है
      • लेकिन यह दुर्लभ और अपवादात्मक स्थिति है
  • छोटी sessions के मामले में
    • जिन sites की औसत session time कम होती है, उन्हें initial JavaScript load को न्यूनतम रखना चाहिए
    • अधिकांश sites को SPA architecture की ज़रूरत नहीं होती
  • जब SPA architecture आवश्यक हो
    • SPA architecture पर तभी विचार करना चाहिए जब कुछ विशेष शर्तें पूरी होती हों
      • session लंबी हो और एक ही data पर कई बार updates की ज़रूरत हो
    • जो sites इन शर्तों को पूरा नहीं करतीं, उन्हें SPA नहीं अपनाना चाहिए
  • मुख्य सवाल
    • चयन JavaScript frameworks के बीच का सवाल नहीं है
    • ज़्यादातर मामलों में असली सवाल यह है कि SPA-oriented tools का उपयोग करना ही उचित है या नहीं
    • अधिकांश sites के लिए इसका जवाब स्पष्ट रूप से "नहीं" है

informational websites

  • सर्वोत्तम संरचना: semantic HTML और ज़रूरत पड़ने पर progressive enhancement का उपयोग
  • static site generators (Hugo, Astro, 11ty, Jekyll) उपयुक्त हैं
  • बार-बार अपडेट होने वाली content के लिए WordPress जैसे CMS tools का उपयोग करें
  • blogs, marketing sites, company homepages, और public information sites को client JavaScript payload यथासंभव कम रखना चाहिए
  • SPA architecture के लिए डिज़ाइन किए गए frameworks का उपयोग नहीं करना चाहिए
  • semantic markup और progressive enhancement क्यों उपयुक्त हैं?
    • इनकी विशेषता छोटी sessions और server-owned data model है
      • page पर दिखने वाले data का मूल स्रोत हमेशा server द्वारा नियंत्रित होता है
      • client data model abstraction या component definitions की ज़रूरत नहीं होती
    • CMS configuration:
      • authors के लिए low-traffic, high-interaction editor
      • readers के लिए high-traffic, low-interaction viewer UI

e-commerce

  • अनुशंसित architecture: server-generated semantic HTML और progressive enhancement
  • Amazon की तुलना में React-आधारित competitors का performance gap स्पष्ट है
    • Walmart traffic का 70% से अधिक mobile से आता है, और SPA-आधारित Next.js का business पर नकारात्मक प्रभाव पड़ता है
  • progressive enhancement क्यों उपयुक्त है
    • e-commerce की सामान्य संरचना:
      • current offerings और search functionality वाली landing page
      • filters और comparison features वाले search results pages
      • product detail page: media, reviews, और recommended alternatives सहित
      • cart management, checkout, और account management screens
    • server-owned state:
      • fresh content (जैसे price) बनाए रखना
      • lightweight page optimization के जरिए latency कम करना
      • aggressive caching, image optimization, और page size reduction strategies का उपयोग

media consumption websites

  • मूल संरचना: progressive enhancement के आधार पर डिज़ाइन
    • ज़रूरत पड़ने पर product changes के अनुसार complexity जोड़ें
  • progressive enhancement और Islands structure क्यों उपयुक्त हैं
    • comment threads जैसे interactive elements को independent data models के रूप में बनाया जा सकता है
    • Web Components का उपयोग करके इन्हें static pages के भीतर implement किया जा सकता है
  • जब SPA उपयुक्त हो
    • media playback persistence:
      • page navigation के दौरान mini player बनाए रखने की ज़रूरत हो
      • SPA तकनीक का उपयोग करें और client JS size limits को नियंत्रित करें
    • offline playback support:
      • local media cache को प्रबंधित करने वाली logic की ज़रूरत होती है
      • Zero, Y.js जैसे data synchronization systems पर विचार करें

social media

  • hybrid model: server-owned data model पर आधारित कम interaction + बीच-बीच में media updates
  • progressive enhancement क्यों उपयुक्त है
    • सामान्य interactions:
      • "like" क्लिक, कभी-कभार updates आदि
      • Hotwire या HTMX का उपयोग करने वाला hybrid तरीका उपयुक्त है
  • जब SPA उपयुक्त हो
    • deep interaction islands:
      • draft posts सेव करने जैसे मामलों में client caching उपयोगी है
    • offline support:
      • पहले HTML deliver करें, फिर Service Worker के जरिए sync और offline logic लागू करें

productivity apps

  • document-centric productivity apps की जटिल ज़रूरतें होती हैं (collaborative editing, offline support, lightweight viewing mode)
  • local data model और SPA-आधारित architecture उपयुक्त हो सकते हैं
  • SPA क्यों उपयुक्त हो सकता है
    • frequent data updates:
      • key input, mouse drag जैसे कार्यों में client logic बेहतर साबित हो सकती है
    • performance constraints को संभालने की ज़रूरत:
      • initial bundle size का प्रबंधन
      • delayed package loading strategies लागू करना

अन्य application classes

  • विशिष्ट आवश्यकताएँ:
    • 3D CAD, programming editors, game streaming, web-based games, media editing, music production systems आदि
    • हर app class का productivity apps की तरह सावधानीपूर्वक मूल्यांकन होना चाहिए
  • सफलता की शर्तें:
    • मुख्य user paths को परिभाषित करना
    • औसत session depth का विश्लेषण
    • performance assurance metrics तय करना
    • core scripts और resources पर नियंत्रण

enterprise software पर एक बात

  • "enterprise business apps" आमतौर पर सबसे खराब performance समस्याएँ पैदा करती हैं
    • dashboards, workflow systems, enterprise chat apps इसके प्रमुख उदाहरण हैं
  • performance एक culture है:
    • initial load time और post-interaction performance को परिभाषित और मापने में विफलता
    • users की अनदेखी करने वाली developer-centric culture ज़हरीली साबित होती है

"लेकिन…"

  • React सहित किसी खास framework से बँधे managers अक्सर इन चुनावों को सही ठहराने के लिए तरह-तरह के तर्क देते हैं
  • लेकिन इन चर्चाओं में user experience केंद्र में नहीं होता, और यही कमी बार-बार दिखाई देती है.

"...हमें तेज़ी से आगे बढ़ना है"

  • सवाल: "आपको लगता है यह कितने समय तक टिकेगा?"
  • जल्दी-जल्दी बनाए गए NPM-आधारित projects accessibility issues, low performance, और बढ़ती complexity पैदा करते हैं, और अंततः गति घट जाती है.
  • remediation cost: JavaScript समस्याओं को सुलझाने में महीनों लग जाते हैं, और feature shipping की गति और कम हो जाती है.
  • Product-Market Fit के लिए accessibility और quality को प्राथमिकता देनी चाहिए.
  • React के साथ "तेज़ी से आगे बढ़ने" का निर्णय लंबे समय में ज़्यादा महँगा पड़ता है और growth में बाधा डालता है.

"...Facebook में तो यह अच्छी तरह चल रहा है"

  • अधिकांश कंपनियाँ Facebook जैसी समस्याओं का सामना नहीं करतीं.
  • Facebook को भी React इस्तेमाल करने से performance समस्याएँ हुईं, लेकिन उसने अपने monopolistic position के दम पर उन्हें ढक दिया.
  • सामान्य कंपनियों को Facebook के उदाहरण की अंधाधुंध नकल नहीं करनी चाहिए.

"...हमारी टीम React पहले से जानती है"

  • React developers, web developers ही होते हैं. CSS, HTML, JavaScript, और DOM पर काम करना अनिवार्य है.
  • React tech stack की सबसे सरल और बदली जा सकने वाली परत है.
  • Preact, Svelte, Lit, FAST जैसे छोटे और तेज़ frameworks सीखने में कोई बड़ी बाधा नहीं है.

"...hiring आसान होनी चाहिए"

  • मौजूदा IT उद्योग बेहतरीन developers को hire करने का शानदार अवसर दे रहा है.
  • React knowledge hiring का मानदंड नहीं हो सकता.
  • React जानने वाले developers आम तौर पर web standards भी आसानी से सीख सकते हैं.
  • इसके उलट, अधिक सरल systems बेहतर ROI देते हैं.

"...अब तो सबके पास तेज़ फोन हैं"

  • mobile usage बढ़ने वाले पिछले 10 वर्षों में, client resources सस्ते हैं—यह धारणा पहले से ही गलत मान्यता साबित हो चुकी है.
  • low-performance phones इस्तेमाल करने वाले users भी product के प्रमुख customers हो सकते हैं.
  • React चुनकर यह मान लेना कि सभी users महंगे devices इस्तेमाल करते हैं, जोखिमभरा है.

"...React industry standard है"

  • React कोई सुसंगत standard नहीं है.
    • React की अपनी शैली (class components vs functional components), TypeScript का उपयोग हो या नहीं, state management tools का चुनाव—ये सब हर project में अलग होते हैं.
  • React stack हमेशा बदलती रहती है, और इसे "standard" कहना सिर्फ एक आरामदेह भ्रम है.

"...ecosystem…"

  • केवल React के साथ compatible libraries बहुत कम हैं; अधिकतर tools Preact आदि में भी इस्तेमाल किए जा सकते हैं.
  • हर NPM package भविष्य का technical debt बन सकता है.
  • CSS-in-JS जैसी अनावश्यक dependencies सिर्फ cost बढ़ाती हैं.

"...Next.js भी काफ़ी तेज़ है"

  • Next.js डिफ़ॉल्ट रूप से React की performance समस्याएँ साथ लेकर आता है.
  • HTML-first tools (जैसे Astro, 11ty) Next.js से बेहतर performance देते हैं.
  • VC-backed startups के API में lock-in का मुद्दा भी मौजूद है.

"...React Native!"

  • React Native mobile apps को धीमा बनाता है और maintenance cost बढ़ाता है.
  • PWA और Capacitor/Cordova का उपयोग बेहतर विकल्प है.
  • Facebook भी React Native से दूर जा रहा है.

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

12 टिप्पणियां

 
nemorize 2024-12-08

सामान्य कंपनियों को Facebook के उदाहरण की अंधाधुंध नकल नहीं करनी चाहिए।

  • Facebook भी React Native से दूर जा रहा है।

कम प्रदर्शन वाले फ़ोन इस्तेमाल करने वाले यूज़र भी प्रोडक्ट के प्रमुख ग्राहक होने की संभावना रखते हैं।

  • Service Worker के ज़रिए sync और offline logic लागू करना

React Native मोबाइल ऐप्स को धीमा बना देता है और उसके maintenance पर काफ़ी ज़्यादा लागत आती है।

  • Capacitor/Cordova का उपयोग करना बेहतर विकल्प है।

हाहाहाहाहाहा हाहा
 
wildmental 2024-12-03

लेख बहुत लंबा है, इसलिए उसका मुख्य बिंदु धुंधला हो गया है

ऐसा लगता है कि लेखक React इस्तेमाल करने की राय को बिना किसी अपवाद के सिर्फ framework-वाद से निकली हुई बात मान रहा है

framework-वाद से बाहर निकलकर case-by-case तरीके से आगे बढ़ने की बात करने के बाद, वह हर तरह की engineering needs के लिए recipe बनाने की कोशिश कर रहा है

हर संभावित आपत्ति का जवाब देने की कोशिश में बातचीत पर ज़रूरत से ज़्यादा कब्ज़ा करने की प्रवृत्ति दिखती है। आपत्तियों पर उसकी पुनः-आपत्तियाँ भी बहुत संकीर्ण हैं.

यानि, किसी खास case से आगे बढ़कर सामान्य सिद्धांतों पर चर्चा करने के लिए लेखक का discussion attitude और skill, दोनों ही बहुत कमज़ोर लगते हैं

नतीजतन, मैं खुद React का इस्तेमाल पसंद नहीं करता, फिर भी लेखक के एकतरफ़ा रवैये की वजह से मुझे React इस्तेमाल करने की वकालत करने वालों की बात थोड़ी और सुनने का मन हुआ
 
savvykang 2024-12-03

फ़िलहाल मेरी व्यक्तिगत राय में अभी React ही सबसे बेहतर विकल्प है, इसलिए अपनी बात रख रहा हूँ.

वेब डेवलपमेंट में मेरी शुरुआत php jquery के दौर से हुई थी, और जिस कंपनी में अभी काम करता हूँ वहाँ AngularJS, Angular, class-style React और hooks-style React का अनुभव रहा है. इस नज़रिए से, पहले इस्तेमाल कर चुके लोगों के trial and error और ecosystem की libraries अच्छी तरह तैयार हो जाने के बाद tech stack बदलना कम सिरदर्द वाला होता है. Semantic versioning के हिसाब से कहें तो यह बिल्कुल latest version की जगह उससे एक major version पुराना इस्तेमाल करने जैसा है. Requirements और high-level features नहीं बदलते, इसलिए कोई बड़ी समस्या नहीं होती, लेकिन अगर underlying technology पर reference material न हो तो productivity नहीं निकलती. इसके अलावा, हमारी कंपनी के project की प्रकृति के कारण SaaS service से अलग product cycle लंबा होता है और एक ऐसा दौर भी आता है जब सिर्फ maintenance ही करना होता है, इसलिए नई technology लागू करना और भी मुश्किल था.

शायद जब React, Next.js की दिशा में पूरी तरह मुड़कर SPA support बंद कर दे और architecture change को मजबूर करे, तब फिर से technology transition पर गंभीरता से सोचना पड़ेगा. अगर Vue थोड़ा और ज़्यादा फैला हुआ होता, तो वह स्वाभाविक रूप से candidate list में आता. उसे न इस्तेमाल करने की कोई वजह नहीं है.
 
dalinaum 2024-12-03

मोबाइल ऐप को RN धीमा बनाता है, ऐसा कहते हुए फिर Capacitor या Cordova की सिफारिश क्यों करते हैं? कम से कम UI को native की तरह दिखाना hybrid web की तुलना में performance के लिहाज़ से कहीं बेहतर तरीका लगता है।
 
dalinaum 2024-12-03

दुख की बात है कि कोरियाई hiring market में अगर “framework purism काम नहीं करता।” तो इंटरव्यू में बहुत जल्दी बाहर हो जाने की संभावना काफ़ी ज़्यादा है। कई इंटरव्यू में ऐसे सवाल पूछे जाते हैं जो केवल framework का बहुत ज़्यादा इस्तेमाल करने पर ही पता चलते हैं।
 
clastneo 2024-12-03

RN डेवलपर फूट-फूटकर रोते हैं
 
clastneo 2024-12-03

अगर इसे गंभीरता से कहें, तो RN का मतलब JS bundle के ज़रिए native components को handle करना है, इसलिए इसका use case PWA से पूरी तरह अलग है.

कुछ हिस्से ऐसे हैं जिन्हें WebView से handle करना भी मुश्किल होता है, तो PWA? लंबी अवधि में यह दिशा वहीं जा सकती है, ऐसा मैं मानता हूँ, लेकिन अभी यह समय से पहले की बात है. शुरू से ही ऐसा लगता है कि एक बेकार तुलना की जा रही है.
 
bbulbum 2024-12-04

सही है। मुख्य लेख की राय लगभग इस स्तर की है कि native ऐप्स की ज़रूरत ही नहीं है।
 
savvykang 2024-12-03

जब तक नई चीज़ों की तरफ आकर्षित होने वाले लोग रहेंगे, ऐसे सवाल बार-बार उठते रहेंगे। क्योंकि पहले से ही React पर बना हुआ सिस्टम मौजूद है, इसलिए hiring की समस्या को नज़रअंदाज़ करने से हकीकत नहीं बदलेगी। Facebook ने React को आगे बढ़ाने की जो वजहें थीं और 10 साल बाद आम कंपनियाँ React को चुनने की जो वजहें हैं, उनमें फर्क है

मेरा मानना है कि architecture और paradigm बदलने पर होने वाली चर्चा इससे कहीं ज़्यादा सावधानी से होनी चाहिए और जहाँ तक संभव हो, ज़्यादा से ज़्यादा लोगों को इसके लिए राज़ी करना चाहिए।
 
huiya 2024-12-03

लेकिन preact भी react-like है, और react से बाहर निकलो तो लाइब्रेरी की संख्या ही.....
जो भी काम की लाइब्रेरी लगती है, वह सब react-विशेष होती है, इसलिए vue डेवलपर रोते हैं
 
alucard 2024-12-03

अच्छे से इस्तेमाल कर रहे हैं, लेकिन इसमें थोड़ा-बहुत जबरन आलोचना वाला एहसास भी है.. इसे इतना लंबा-चौड़ा लिख देने से ऐसा लगता है मानो किसी बहुत बड़ी समस्या का सामना करा रहा हो..
 
GN⁺ 2024-12-01
Hacker News राय

  • मुझे लगता है कि React के इस्तेमाल का विरोध करने की ज़्यादातर वजहें गलत समस्याओं को हल करने की कोशिश हैं। performance issues वास्तव में कोई बड़ी समस्या नहीं हैं। ज़्यादातर मामलों में backend में सुधार ज़्यादा प्रभावी होता है

    • React के पुराने event system के इस्तेमाल की आलोचना की जाती है, लेकिन इससे users को समस्या नहीं होती। React को पूरी तरह छोड़ देने की यह वजह नहीं है
    • React की जगह इस्तेमाल करने के लिए कोई विकल्प नहीं बताया जाता, इसलिए चर्चा अधूरी लगती है। मुझे लगता है कि विकल्प React से भी बदतर हैं

  • React और jQuery के लोकप्रिय होने की वजह यह है कि code साफ़-सुथरा दिखता है। AngularJS के शुरुआती code samples देखने में अच्छे नहीं लगते

    • React को भी jQuery की तरह तब बदला जाएगा जब उससे बेहतर विकल्प आएगा। code samples का सुंदर दिखना महत्वपूर्ण है

  • React का मूल यह है कि यह O(n) UI state को functional तरीके से render करने देता है। पहले O(n^2) state transitions को manage करना जटिल था

    • React इस जटिलता को कम करने वाला पहला mainstream tool था, और इसकी सफलता जायज़ है

  • React का इस्तेमाल जारी रखने की वजह यह है कि यह Java की तरह स्थिर और परिपक्व तकनीक है। इसका community और resources ecosystem बहुत समृद्ध है

  • Alex का लेख बार-बार होने वाली बहसों को लेकर उसकी हताशा दिखाता है। बहुत से लोग लेख को अंत तक नहीं पढ़ते

    • वह web performance के सच को देखती लेकिन किसी के भरोसा न करने वाली Cassandra जैसी है

  • यह कहना कि React developer ही web developer है, अब धीरे-धीरे कम सही लगता है। बहुत से developer सिर्फ SPA React और styling frameworks के आदी हो गए हैं

    • React के इस्तेमाल की वजह Facebook है, और बहुत से लोग इस पर सवाल नहीं उठाते

  • ज़्यादातर sites को SPA की ज़रूरत नहीं होती। लेकिन जिन businesses को बहुत सारा data चाहिए, उनके लिए SPA फायदेमंद है

    • NPM packages की बहुत आलोचना होती है, लेकिन लोग यह समझने की कोशिश कम करते हैं कि ऐसा क्यों है
    • React framework नहीं बल्कि एक view library है

  • मुझे React पसंद नहीं है। backend developer होने के नाते मैं server-generated HTML और थोड़े-से JavaScript को प्राथमिकता देता हूँ

    • नए projects में Elixir/Phoenix/LiveView और HTMX पर विचार कर रहा हूँ

  • frontend development के JavaScript frameworks की ओर बढ़ने की वजह maintenance cost है

    • अगर frontend build पहले से process में शामिल है, तो लागत बचाई जा सकती है
    • SPA pattern frontend build के साथ सबसे अच्छी तरह फिट बैठता है

  • React के बारे में बहुत-सी आलोचनाएँ गलत हैं। React developers बिना कोई नई template language बनाए भी काम पूरा कर लेते हैं

    • websites के धीमे होने की वजह React नहीं, बल्कि developers या budget की कमी है