2025 में React और कम्युनिटी की मौजूदा स्थिति

 (blog.isquaredsoftware.com)
26 पॉइंट द्वारा GN⁺ 2025-06-16 | 16 टिप्पणियां | WhatsApp पर शेयर करें
  • React अब भी सबसे व्यापक रूप से इस्तेमाल किया जाने वाला UI framework है, लेकिन पिछले कुछ वर्षों में कम्युनिटी के भीतर भ्रम, बहस और अविश्वास बढ़ा है, और official team तथा बाहरी developers के बीच कम्युनिकेशन की कमी और गलत marketing के मिश्रण ने चिंताओं को और बढ़ाया है
  • React 19 आधिकारिक रूप से रिलीज़ हो चुका है, जिसमें Server Components, नया use hook, form integration जैसी बड़ी सुविधाएँ जोड़ी गई हैं, लेकिन "केवल framework recommended" नीति और Next.js-केंद्रित संरचना ने कई users में असंतोष पैदा किया
  • "अब React को सही ढंग से केवल Next.js में ही इस्तेमाल किया जा सकता है" और "जल्द ही client-only support बंद हो जाएगा" जैसी गलतफहमियाँ और FUD फैले, लेकिन वास्तव में client rendering capability कभी खत्म नहीं होगी, और RSC व server features भी पूरी तरह वैकल्पिक हैं
  • React team की framework-केंद्रित नीति का उद्देश्य performance/structure का standardization और user experience में सुधार है, लेकिन SPA और विभिन्न architectures के प्रति सम्मान की कमी तथा अनौपचारिक/अनुकूल न लगने वाले docs ने कम्युनिटी के भ्रम को बढ़ाया
  • हाल में ही Vite·Parcel आधारित SPA सहित कई तरीकों को official docs में शामिल किया गया है, लेकिन server components (RSC) पर official explanation की कमी और कमजोर संचार अब भी बाकी है

परिचय और उद्देश्य

  • 2025 के अनुसार React कम्युनिटी सफलता, अविश्वास और बहस के मिश्रण वाला एक जटिल चरण झेल रही है
  • इस लेख का उद्देश्य React के विकास क्रम, development direction, और प्रमुख निर्णयों की पृष्ठभूमि को व्यवस्थित करना तथा FUD और भ्रम को दूर करना है

लेखक की पृष्ठभूमि और कम्युनिटी भागीदारी का इतिहास

  • React team का सदस्य नहीं, लेकिन 2015 से React ecosystem में गहराई से शामिल
  • Redux family libraries, खासकर Redux Toolkit, के maintainer और प्रमुख कम्युनिटी contributor
  • अनेक React/Redux tutorials, blogs, talks और podcasts में भागीदारी
  • Reactiflux Discord, /r/reactjs subreddit जैसी प्रमुख कम्युनिटीज़ में admin और moderator की भूमिका
  • React team के साथ सहयोग का अनुभव, जैसे useSyncExternalStore hook के alpha tester के रूप में, और कई internal feedback groups में भागीदारी
  • React DevTools, sourcemaps, Replay DevTools आदि में विभिन्न तकनीकी योगदान

  • पक्षपात और सीमाओं के बारे में सूचना

    • मैं हमेशा सही नहीं हो सकता, और जानकारी की सीमाओं, गलतफहमियों या सारांश बनाने की प्रक्रिया में कुछ विवरण आंशिक रूप से गलत हो सकते हैं
    • मैं Redux maintain करता हूँ, और React उपयोग का मेरा अनुभव भी मुख्यतः internal tools और SPA रूपों की ओर झुका हुआ है
    • SSR, RSC, बड़े पैमाने के traffic, i18n आदि का व्यावहारिक अनुभव सीमित है
    • कम्युनिटी के भीतर गहराई से चर्चा किए गए विषयों से परिचित हूँ, लेकिन यह सामान्य app developer की रोज़मर्रा की वास्तविकता से कुछ अलग हो सकता है
    • React team के साथ सकारात्मक और नकारात्मक दोनों तरह के व्यक्तिगत अनुभवों ने मेरे दृष्टिकोण को प्रभावित किया है
    • ऐतिहासिक और संरचनात्मक पृष्ठभूमि समझाते समय यथासंभव ईमानदारी से तथ्य प्रस्तुत करने की कोशिश की है

React का संक्षिप्त इतिहास

  • 2011~2012 में Facebook (अब Meta) के भीतर विकास, 2013 में open source किया गया
  • हाल तक लगभग पूरा core development Facebook/Meta की React team के नेतृत्व में हुआ
  • मुख्य concepts—components, props, state, data flow—बरकरार रहे, लेकिन implementation, API और application scope लगातार बढ़ते और बदलते रहे
    • createClass → ES6 class → function components (Hooks support के साथ)
    • React Native के जरिए mobile, react-reconciler के जरिए WebGL (react-three-fiber), CLI (ink) जैसे कई platforms तक विस्तार
    • अंदरूनी रूप से "Fiber" architecture के साथ बड़े पैमाने पर refactoring, जिसने performance और structure दोनों में बदलाव लाया
    • 2018 में Hooks के आने से function components में state और effects जोड़ना संभव हुआ
  • "Minimal UI library (MVC में V)" रणनीति के तहत architecture, higher-level frameworks, build setup, state management आदि कम्युनिटी पर छोड़े गए
    • इसी वजह से Redux/Mobx/Zustand (state), Styled-Components/Emotion/CSS Modules (style), React Query/Apollo/SWR(RTK Query) (data), Webpack/Vite/Parcel जैसे असंख्य third-party libraries और build tools उभरे
  • लचीलापन इसका फायदा था, लेकिन हर project में ज़रूरी libraries चुनना भी आवश्यक था → इससे codebase diversity, fatigue और standards की कमी जैसी समस्याएँ साथ आईं

  • Build tools और CRA

    • शुरुआती दौर में Webpack/Babel जैसी जटिल configuration लगभग अनिवार्य थी
    • Create React App (CRA): Webpack+Babel आधारित CLI, जो जटिलता छिपाकर एक command से project बनाना आसान बनाता था (black-box approach)
    • data fetching और state management अब भी अलग third-party tools पर निर्भर थे
    • SSR (server-side rendering) की सुविधा शुरू से मौजूद थी, लेकिन उसे manually implement करना पड़ता था
    • बाद में Next.js (SSR/file-system based routing, data fetching), Gatsby (static sites, GraphQL), Remix (server data loaders) जैसे frameworks सामने आए

  • React Server Components (RSC) और framework shift

    • 2020 के अंत में React Server Components (RSC) का prototype सार्वजनिक किया गया, जो async components और server data fetching को React में standardize करने की एक architectural shift थी
    • development के दौरान React team के कुछ सदस्य Vercel चले गए और Next.js के साथ मिलकर App Router तथा RSC का पहला implementation तैयार किया
    • 2020~2023 के बीच React official docs (react.dev) का बड़ा पुनर्गठन हुआ, जिसमें interactive tutorials और API references को मज़बूत किया गया

  • आधिकारिक recommended usage में बदलाव

    • पहले official docs में CRA-आधारित SPA से शुरुआत recommend की जाती थी, और SSR/static site की ज़रूरत होने पर Next/Gatsby जैसे विकल्प सुझाए जाते थे
    • नए docs (react.dev) में framework use को ज़ोरदार तरीके से recommend किया गया (routing, data fetching, build integration), और RSC implementation के रूप में केवल Next.js का उल्लेख हुआ
    • CRA लगभग 2022 से व्यवहारिक रूप से maintenance mode में चला गया (औपचारिक रूप से deprecated नहीं था, लेकिन कम्युनिटी धीरे-धीरे उससे आगे बढ़ गई)
    • official docs और कम्युनिटी दोनों में “Next.js ही असली React 18 है” जैसी रायों के कारण Next.js के साथ गहरा जुड़ाव अधिक उभरकर सामने आया

React और इसे प्रायोजित/स्वामित्व रखने वाली कंपनियों का संबंध

  • Meta (Facebook)

    • React शुरू से Facebook/Meta के स्वामित्व और नेतृत्व वाला project रहा है
    • open source होने के बावजूद वास्तविक development Meta React team ने संभाला, और core meetings व roadmap भी मुख्यतः internal रहे
    • नई features पहले Meta के विभिन्न app teams में वास्तविक उपयोग और testing के बाद बाहर लाई जाती थीं
    • React team को development में काफ़ी autonomy मिली हुई थी, और roadmap तथा vision तैयार करने में इसकी अग्रणी भूमिका रही
    • उपलब्धियों और projects का Meta business में योगदान क्या है, इसका internal validation ज़रूरी था
    • Meta अपनी server infrastructure, GraphQL, Relay जैसी technologies का सक्रिय उपयोग करता है, और routing व state management में React का उपयोग कम्युनिटी से अलग ढंग से करता है
    • इसलिए Meta के भीतर बाहरी third-party libraries का उपयोग अपेक्षाकृत कम है

  • Vercel, Next.js, React

    • Vercel एक web app hosting platform है और Next.js framework की developer company भी है
    • इसका business model broadly यह है: Next जैसे frameworks का प्रसार → Vercel platform पर hosting की ओर प्रेरित करना
    • CEO Guillermo Rauch शुरू से React rendering philosophy पर गहरा भरोसा और निवेश रखते रहे हैं
    • 2021 में React team leader Sebastian Markbage Meta से Vercel चले गए, और बाद में Andrew Clark, Tom Occhino जैसे प्रमुख लोग भी जुड़े
    • Vercel में गए इन सदस्यों ने React Server Components (RSC) और Next.js App Router जैसी core features को React और Next.js दोनों पक्षों में implement किया
    • Vercel के engineers ने भी React core और server rendering features में वास्तविक योगदान दिया
    • 2025 तक React team Meta और Vercel के बीच विभाजित रूप से काम कर रही है (मुख्य आधार Meta है, लेकिन महत्वपूर्ण core implementation में Vercel भी शामिल है), साथ ही कुछ external contributors भी हैं

React के उपयोग के पैटर्न

  • Standard architectures

    • React स्वयं SPA, SSR, SSG, hybrid आदि कई तरह के approaches को support करता है
      • SPA: खाली HTML पर पूरा React tree client में render करना
      • SSR: server पर हर request के लिए dynamic HTML बनाना
      • SSG: build time में static HTML पहले से generate करना
      • Python/Django, Ruby/Rails, PHP/WordPress जैसे कई languages और frameworks के साथ संयोजन संभव
    • 2015 के आसपास से SPA (client rendering) तरीका standard था, लेकिन initial loading speed, JS bundle size, और native browser behavior के अंतर जैसे trade-offs मौजूद थे
    • data fetching पहले Redux आदि में manually implement की जाती थी, बाद में React Query/Apollo/SWR/RTK Query जैसे dedicated hooks/libraries ने इसे सरल बनाया
    • Next.js, Remix जैसे frameworks ने SSR, SSG, file-system routing को standardize कर और data fetching को structure देकर React के उपयोग के दायरे को बढ़ाया
    • SSR-आधारित architecture (server rendering, prefetching, code splitting आदि) की ओर बढ़ने का रुझान बना
    • React team “data fetching waterfall” pattern से बचने और route-level prefetching जैसे performance patterns की सलाह देती है

  • Build tools और frameworks की उपयोग स्थिति

    • प्रमुख tools/frameworks:
      • Next.js (SSR/SSG/RSC/SPA)
      • Remix / React-Router v7 (SSR/SSG/SPA)
      • Vite (SPA, build tool, कई frameworks plugins के support के साथ)
      • Create React App (SPA)
    • Vite की शुरुआत Vue ecosystem में हुई थी, लेकिन अब React, Svelte सहित कई frameworks को support करता है → React official plugin और framework build tool standard के रूप में व्यापक उपयोग
    • Remix/React-Router भी हाल में Vite-आधारित SSR/SSG support structure की ओर बढ़े हैं
    • Download stats का सार:
      • Next.js उपयोग में स्पष्ट रूप से नंबर 1
      • Vite का React plugin तेज़ी से बढ़ा, और दूसरा सबसे अधिक इस्तेमाल होने वाला विकल्प बना
      • CRA (react-scripts) 2023 के बाद गिरावट में है, लेकिन अब भी काफ़ी उपयोग में है
      • Remix की चर्चा और प्रतिष्ठा मज़बूत है, लेकिन कुल पैमाना सीमित है; React Router का framework mode की ओर बदलाव धीमा है
      • Gatsby, Next/Vite/CRA की तुलना में काफी पीछे है, और हाल में Astro (multi-framework static sites) से भी पीछे निकल गया है
      • Astro React-specific नहीं है, लेकिन पैमाने में Remix के करीब है
      • Vite+CRA का संयुक्त उपयोग Next के बराबरी पर है → SPA approaches की मांग अब भी ऊँची है

React Server Components (RSC) की आंतरिक संरचना और frameworks से संबंध

  • RSC development background और Vercel सहयोग

    • Meta की internal infrastructure पहले से अपने server structure पर आधारित थी, इसलिए RSC (React Server Components) के development/testing में सीमाएँ थीं
    • RSC, React team द्वारा सीधे आगे बढ़ाया गया भविष्य-उन्मुख design था, यह Meta या Vercel के निर्देश/मांग से पैदा नहीं हुआ, बल्कि React team के स्वतंत्र vision से शुरू हुआ
    • React team ने Vercel को RSC vision प्रस्तावित किया, और Vercel development के लिए प्रयोगशाला तथा समर्थक के रूप में जुड़ा
    • Sebastian Markbage, Andrew Clark जैसे React core members Meta से Vercel गए, और Next.js team ने App Router बनाया, जो RSC का पहला वास्तविक उपयोग-मामला बना
    • इस प्रक्रिया में Next.js को लगभग शुरुआत से फिर से design और implement किया गया
    • Shopify (Hydrogen), Remix जैसे दूसरे frameworks ने शुरुआती testing/सहयोग की कोशिश की, लेकिन गंभीर स्तर की भागीदारी सीमित रही
    • नतीजे में केवल Next.js App Router ही वास्तविक “production-grade” RSC implementation के रूप में स्थापित हुआ; अन्य frameworks (React Router, Parcel, Waku आदि) अभी integration पर काम कर रहे हैं, लेकिन लोकप्रिय उपयोग में Next का दबदबा है

  • RSC और framework/bundler integration structure

    • “RSC के लिए framework या bundler ज़रूरी क्यों है?” यह एक आम सवाल है
    • पारंपरिक SSR (renderToString, renderToPipeableStream) कहीं भी चल सकता था, लेकिन RSC संरचनात्मक रूप से कहीं अधिक जटिल है
      • code में 'use client', 'use server' directives को समझना
      • client/server components का विभाजन और registration स्वचालित करना
      • पूरे module graph का analysis और compilation करने वाले bundler (जैसे Webpack, Vite आदि) के साथ गहरा integration अनिवार्य है
    • React core, RSC की core logic और data serialization API देता है, लेकिन वास्तविक behavior, routing, endpoint calls आदि की जिम्मेदारी framework की होती है
    • हर framework में RSC के उपयोग, architecture और implementation का तरीका अलग होता है
      • Next.js App Router layout, routing आदि पर अपने नियम लागू करता है
      • Parcel, Waku, React Router आदि अलग-अलग designs अपना रहे हैं
    • सार:
      • RSC, React core में built-in hybrid feature है, लेकिन उसका वास्तविक उपयोग हमेशा bundler/framework integration पर निर्भर करता है
      • framework support होने पर ही RSC की ताकत का वास्तविक लाभ लिया जा सकता है

कम्युनिटी की चिंताएँ और भ्रम

  • 1. “Vercel ने React पर कब्ज़ा कर लिया” वाली चिंता

    • Vercel ने React team के प्रमुख लोगों को hire किया, और docs/examples में Next.js पर ज़ोर के कारण “Vercel React development को नियंत्रित कर रहा है” जैसी शंकाएँ फैलीं
    • वास्तविकता में React team ने ही RSC vision और Next App Router structure को lead किया, और Vercel ने support तथा testbed की भूमिका निभाई
    • Vercel ने React को “कब्ज़ा” नहीं किया, बल्कि React core team के कुछ सदस्य Vercel जाकर अपने vision को आगे बढ़ा सके

  • 2. “अब React केवल Next में ही चलता है” वाली गलतफहमी

    • केवल Next.js ही production RSC implementation के रूप में अधिक उभरा, इसलिए यह भ्रम पैदा हुआ
    • React official docs में Next के अलावा कई frameworks और framework के बिना उपयोग के तरीके भी बताए गए हैं
    • Next, React पर आधारित एक framework भर है; React आज भी अकेले या अन्य tools के साथ इस्तेमाल किया जा सकता है

  • 3. “client apps में React गायब हो सकता है” वाली चिंता

    • server features (RSC, SSR आदि) पर ज़ोर के कारण कुछ लोगों ने SPA client support के खत्म होने की आशंका जताई
    • React की client rendering capability कभी खत्म नहीं होगी
      • Meta जैसे बड़े codebases भी client-based approaches का बड़े पैमाने पर उपयोग करते हैं
      • React team compatibility और migration support को लेकर बहुत सावधान रहती है

  • 4. “React framework use पर इतना ज़ोर क्यों देता है?”

    • React team data fetching, routing, SSR integration आदि में framework के productivity और performance benefits को कारण बताकर उसे default recommendation मानती है
    • उनका दृष्टिकोण है कि “self-configured/custom SPA लंबी अवधि में कम efficient है, और frameworks ही industry standard हैं”
    • व्यवहार में उपयोग के कई अलग-अलग patterns मौजूद हैं, लेकिन recommendation बहुत एकरूप लगती है
      • beginners के लिए entry barrier, server hosting सीमाओं वाली कंपनियाँ, SPA hosting की सरलता आदि कारणों से SPA आज भी वैध विकल्प है
    • official docs में “non-framework approach” को गौण तरीके से पेश किए जाने से कम्युनिटी के एक हिस्से को अलग-थलग महसूस हुआ

  • 5. Official docs की सीमाएँ और सुधार को लेकर विवाद

    • CRA (react-scripts) को आधिकारिक रूप से deprecated किया गया, लेकिन replacement tools (जैसे Vite) का उल्लेख देर से आने से भ्रम बढ़ा
    • SPA जैसे “non-framework” approaches को भी अब आधिकारिक मान्यता और guidance मिली है (2025 के latest docs)
    • Vite जैसे महत्वपूर्ण build tools का official mention देर से होने पर कम्युनिटी और ecosystem figures (जैसे Evan You) ने भी सवाल उठाए
    • सुधरे हुए latest docs में SPA, Vite/Parcel/RSPack आदि भी recommend किए गए हैं, और router/data fetching चयन के लिए guides भी जोड़ी गई हैं

  • 6. RSC पर official docs और explanation की कमी

    • Next.js, Vercel जैसी बाहरी सामग्री की तुलना में React official docs में RSC की explanation और conceptual guidance कम है
    • API Reference में केवल बिखरी हुई जानकारी है, समग्र concept/application guidance कमज़ोर है
    • कम्युनिटी और प्रमुख लोग (जैसे Dan Abramov आदि) सक्रिय रूप से पूरक व्याख्या दे रहे हैं, लेकिन official रूप की कमी लगातार भ्रम पैदा करती है
    • RSC के concept, architecture, adoption examples, FAQ आदि के लिए docs sections जोड़ने की ज़रूरत बताई जा रही है

प्रमुख चिंताओं पर सार

  • framework और server features पर ज़ोर को “Vercel के फ़ायदे” से जोड़कर जो गलतफहमी कम्युनिटी में बैठ गई है, वह वास्तविकता से मेल नहीं खाती
    • React team की communication style और official docs की wording ने इस गलतफहमी को बढ़ाने में भूमिका निभाई
  • React की client rendering capability आगे भी बनी रहेगी; server features (RSC/SSR आदि) केवल विकल्प हैं, और SPA जैसे मौजूदा approaches का उपयोग जारी रह सकता है
  • कम्युनिटी की चिंता और भ्रम का एक कारण React team की कमजोर communication और developer relations (DevRel) गतिविधियों की कमी भी है
    • official position को स्पष्ट करना, गलतफहमियाँ दूर करना, और अलग-अलग patterns को मान्यता व guidance देना ज़रूरी है
  • “framework use” की recommendation अच्छी मंशा से शुरू हुई, लेकिन व्यवहार में यह ज़रूरत से ज़्यादा एकरूप लगी और कई वैध usage patterns को हाशिये पर ले गई—ऐसी आलोचना मौजूद है
  • 2025 के बाद official docs में सुधार कर SPA/custom build approaches को भी मान्यता और guidance दी गई, लेकिन कम्युनिटी feedback को reflect करने में बहुत समय लगा
  • RSC (React Server Components) के concept, trade-offs आदि जैसे core points पर official docs को और मज़बूत करने की ज़रूरत है
    • इससे कम्युनिटी में सही समझ बनेगी और अनावश्यक विवाद कम होंगे

निष्कर्ष

  • यह लेख इस बात के कई सवालों के जवाब देता है कि React कैसे विकसित हुआ, किन प्रभावों और लक्ष्यों के तहत विकसित किया जा रहा है, और मौजूदा ecosystem में usage patterns कैसे स्थापित हुए
  • इसका उद्देश्य React team की दिशा और बदलावों को लेकर पैदा हुए भ्रम या FUD (डर, अनिश्चितता और संदेह) को दूर करना था
    • भले ही कोई इसकी technical direction से सहमत न हो या RSC/बड़े frameworks की ज़रूरत न महसूस करे, React team की मंशा और दिशा पर्याप्त रूप से उचित है
  • React team की नीतियाँ performance standardization और कम्युनिटी UX सुधार जैसी अच्छी मंशा से निकलीं, लेकिन कम अनुकूल communication और docs ने अनावश्यक भ्रम बढ़ाया
  • SPA, frameworks, और अलग-अलग build tools जैसे वास्तविक usage diversity के प्रति सम्मान तथा official docs में सुधार की ज़रूरत और बढ़ गई है
  • आगे चलकर कम्युनिटी feedback को अपनाने वाले docs, विभिन्न architectures को समाहित करने वाला मार्गदर्शन, और खुला communication ही React के स्वस्थ विकास की कुंजी होंगे

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

16 टिप्पणियां

 
ahwjdekf 2025-06-19

React कुछ हद तक ढीला-ढाला और अधूरा-सा library लगता है... उदाहरण के लिए, useEffect के आधिकारिक docs में जो लंबी-चौड़ी बातें लिखी हैं, उन्हें देखो तो... बस हैरानी होती है... इतने सारे rabbit holes बनाकर रख दिए हैं, और फिर कहते हैं कि इसे अच्छे से इस्तेमाल करो—यह रवैया आखिर क्या है... अक्सर ऐसा लगता है कि बिना ज़्यादा सोचे बस तदर्थ तरीके से पैबंद लगाया जा रहा है।
 
ahwjdekf 2025-10-23

AWS में गड़बड़ी होते देख कर फिर वही... ऐसा ख़याल आया।
 
geek12356 2025-06-18

अगर आप सुधार के सुझाव नहीं दे सकते, तो आप जूनियर हैं
 
woonki 2025-06-17

React Native में भी कुछ ऐसा ही माहौल है। अगर React के लिए Next.js है, तो React Native के लिए Expo है। आधिकारिक दस्तावेज़ भी Expo framework के इस्तेमाल की सिफारिश करते हैं, और पुराना cli तरीका अब इस तरह छिपा दिया गया है कि उसे ढूंढना भी मुश्किल हो गया है।
 
preserde 2025-06-16

असल में यहाँ web frontend development से जुड़े मुद्दे काफ़ी कम पोस्ट होते हैं... फिर भी हाल में nextjs का ज़िक्र बहुत ज़्यादा होने लगा है, तो यह कुछ असामान्य सा लग रहा है.
लगता है कि बस Server component ही समस्या है, बाकी सब ठीक है~
 
ahwjdekf 2025-06-16

js fe वाली दुनिया को एक बार पूरी तरह ढहाकर रीसेट कर दीजिए। और state management वगैरह सबको भी ठीक से शामिल करके कोई framework बना दीजिए। हद से ज़्यादा options? वह आज़ादी नहीं, बस गैर-जिम्मेदारी है।
 
passerby 2025-06-16

मुझे लगता है कि framework का सुविधाजनक होना और React खुद CRA को छोड़ देना बिल्कुल अलग स्तर के मुद्दे हैं। बदले हुए React docs में अचानक Next install करने को कहा गया, तो मुझे थोड़ा अटपटा लगा था, और लगता है यह महसूस करने वाला मैं अकेला नहीं था।
 
dohyun682 2025-06-16

मुझे लगा था कि Vercel और React डेवलपमेंट टीम अलग-अलग हैं, लेकिन असल में उनका संबंध उससे कहीं गहरा है।
 
quilt8703 2025-06-16

मैं React के साथ एक गेम प्रोटोटाइप बना रहा हूँ, जिसमें सिर्फ UI interaction, internal state calculation, और state display जैसी ज़रूरतें हैं। कुछ साल पहले जब create-react-app आधिकारिक दस्तावेज़ों से लगभग बाहर होने वाला था, उस समय की तुलना में मुझे हाल में आधिकारिक दस्तावेज़ देखकर setup करना थोड़ा ज़्यादा मुश्किल लगा। लगता है कि उस समय लिखा गया मेरा यह लेख थोड़ा प्रासंगिक हो सकता है।
 
click 2025-06-16

ऐसा लगता है कि RSC को शुरू से ही Next.js आधारित बनाकर विकसित किया गया था, यह बात अपने आप में अलग नहीं लगती।
अगर इसे इस बात के साथ जोड़ें कि Next.js धीरे-धीरे Vercel के अलावा दूसरे environments में ज्यादा डगमगाने लगा है,
तो React टीम के भीतर की सोच क्या है यह तो नहीं पता, लेकिन तर्क का प्रवाह कुछ ऐसा बनता है कि RSC ही भविष्य है! लेकिन RSC चलाने के लिए Next.js की सिफारिश की जाती है, और Next.js को Vercel पर इस्तेमाल करें। तो अगर पूछा जाए कि क्या इसका Vercel के फायदे से कोई संबंध नहीं है, तो ह्म्म...
चाहे कितना भी कहा जाए कि यह गलतफहमी है, आखिरकार लोगों को यह महसूस होना ही है कि Vercel ने React पर कब्जा कर लिया है, और क्या इस गलतफहमी को दूर करने के लिए तेज़ी से प्रतिक्रिया भी नहीं दी गई थी?
 
spp00 2025-06-17

अभी React की आधिकारिक वेबसाइट Meta की तरफ़ के सर्वर पर नहीं, बल्कि Vercel पर चल रही है।
 
moderna 2025-06-16

सहमत हूँ।
 
click 2025-06-16

मुझे लगा कि Vercel द्वारा निवेशित svelte, शायद उसका स्केल छोटा होने की वजह से, इस तरह के vendor lock-in में फंसता नहीं दिखता; इसलिए यह अंतर क्यों है, यह भी जानने की उत्सुकता है।
 
spp00 2025-06-17

Svelte को Vercel सिर्फ़ sponsor करता है, Vercel उसका lead नहीं करता। दूसरी ओर, Next को Vercel पूरी तरह lead करता है।

GitHub repository के मामले में भी, Next Vercel organization के अंतर्गत है, लेकिन Svelte ऐसा नहीं है।

और Next.js की आधिकारिक वेबसाइट के footer के copyright उल्लेख में Vercel है, जबकि Svelte में नहीं है।
 
click 2025-06-17

तो Vercel ने Rich Harris को हायर किया था, वह एक तरह का sponsorship ही था।
 
spp00 2025-06-17

https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte हाँ, यह काफ़ी हद तक sponsorship जैसी hiring है। यानी उन्हें सैलरी दी जा रही है ताकि वे Svelte development पर full-time ध्यान दे सकें। Vercel की ओर से भी यह साफ़ किया गया है कि Svelte अब भी एक independent project है।