React Server Components में 50,000 लाइनों का कोड ले जाने से पहले जो बातें जानना अच्छा होता

 (mux.com)
1 पॉइंट द्वारा GN⁺ 2023-09-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Mux ने mux.com और docs.mux.com को React Server Components पर माइग्रेट करते हुए पाया कि server और client execution boundary को कैसे बाँटा जाता है, इसका bundle size और hydration cost पर सीधा असर पड़ता है
  • RSC से components सर्वर पर सीधे data fetch कर सकते हैं और परिणाम को stream कर सकते हैं, जिससे धीमे data calls होने पर भी स्क्रीन का कुछ हिस्सा पहले दिखाया जा सकता है
  • वास्तविक migration में सबसे बड़े अड़ंगे CSS-in-JS का unsupported होना, Server Components में React Context की सीमाएँ, और server/client boundary को लगातार ट्रैक करने की जटिलता थे
  • Next.js 13 के app directory में default रूप से Server Component होता है, और root पर मौजूद use client को धीरे-धीरे नीचे ले जाकर gradual adoption किया जा सकता है
  • Suspense, loading.js, server-only libraries को server पर बनाए रखना, और server-only जैसे patterns को सिर्फ वहीं सावधानी से लागू करना चाहिए जहाँ performance gain ज़रूरी हो, और टीम की cognitive cost को भी साथ में गिनना चाहिए

Mux ने RSC में कितना हिस्सा माइग्रेट किया

  • Mux ने documentation site के पुनर्गठन और brand refresh के दौरान mux.com और docs.mux.com को Server Components पर माइग्रेट किया
  • React Server Components वास्तविक codebase में भी लागू किए जा सकते हैं और उपयोगी हो सकते हैं, लेकिन इनके साथ सीमाएँ और जटिलता भी आती हैं
  • यह अनुभव इस बात पर केंद्रित है कि RSC की ज़रूरत क्यों पड़ती है, यह कहाँ उपयुक्त है, किन स्थितियों में कठिन हो जाता है, और इसे वास्तविक codebase में धीरे-धीरे कैसे लाया जा सकता है

CSR, SSR/SSG के बाद RSC किस समस्या को निशाना बनाता है

  • शुरुआती server rendering मॉडल में PHP जैसी तकनीकों से server पर data fetch किया जाता था और भारी CPU काम server पर करके client को हल्का HTML भेजा जाता था
  • CSR/SPA ने rendering code को JavaScript के रूप में client तक भेजा, जिससे interactions तेज़ी से संभाले जा सके, लेकिन जहाँ search engines JavaScript नहीं चलाते, या server पर secret values बनाए रखनी हों, या low-end devices और slow connection मिलें, वहाँ इसकी कमज़ोरियाँ सामने आती हैं
  • SSR/SSG Next.js और Gatsby जैसे tools के ज़रिए server पर HTML और JavaScript साथ में बनाकर client को भेजता है
    • उपयोगकर्ता तुरंत HTML देख सकता है
    • JavaScript लोड होने पर site interactive हो जाती है
    • search engines भी HTML पढ़ सकते हैं
  • पारंपरिक SSR/SSG में भी कुछ लागत बनी रहती है
    • page बनाने में इस्तेमाल हुए ज़्यादातर JavaScript को client तक भेजना पड़ता है, और client को उसे फिर से चलाकर HTML के साथ जोड़ने की hydration करनी पड़ती है
    • अगर server rendering धीमी database calls या बहुत सारा code चलने के कारण लंबा समय ले, तो उपयोगकर्ता को इंतज़ार करना पड़ता है

React Server Components क्या बदलता है

  • React Server Components ऐसे React components हैं जो client पर नहीं बल्कि server पर चलते हैं
  • RSC को support करने वाले frameworks code के execution location को स्पष्ट रूप से अलग करने देते हैं
    • Server Components: वह code जो सिर्फ server पर चलना चाहिए
    • Client Components: वह code जो client पर चलना चाहिए
  • जब execution location अलग हो जाती है, तो client को भेजा जाने वाला JavaScript घटता है और hydration के दौरान किया जाने वाला काम भी कम हो जाता है
  • Server Component component के अंदर ही सीधे data fetch कर सकता है
    • Node libraries या fetch का उपयोग किया जा सकता है
    • page स्तर पर getServerSideProps से एक साथ data fetch करके लगातार props नीचे पास करने की ज़रूरत घट सकती है
    • useEffect से जटिल loading state संभालने की ज़रूरत भी कम हो सकती है
  • data fetch पूरा होने के बाद Server Component परिणाम को client तक stream कर सकता है
    • धीमे components का इंतज़ार करते समय site का बाकी हिस्सा पहले दिखाया जा सकता है
  • client user actions के जवाब में server से data fetch करके response stream करना भी संभव है, लेकिन सख्ती से देखें तो वह RSC नहीं बल्कि React Actions है

RSC के मुश्किल हिस्से

  • CSS-in-JS अभी Server Components में काम नहीं करता
    • Mux के RSC migration में styled-components से Tailwind CSS में जाना सबसे बड़ा हिस्सा था
    • अगर codebase CSS-in-JS पर बहुत निर्भर है, तो अलग migration effort की ज़रूरत होगी
  • React Context तक पहुँच सिर्फ Client Components में संभव है
    • अगर Server Components के बीच props के बिना data share करना हो, तो सामान्य modules का इस्तेमाल करना पड़ सकता है
    • React app की किसी खास subtree तक data सीमित रखने का अच्छा mechanism Server Components में नहीं है
  • Mux के documentation site में Context जहाँ इस्तेमाल हो रहा था वहाँ interaction ज़्यादा था, इसलिए वह हिस्सा वैसे भी client को भेजना था और यह बड़ा मुद्दा नहीं बना
  • marketing site में theme sharing समस्या बनी
    • pre-footer के हर component को यह जानना पड़ता था कि वह हरे background पर है ताकि वह dark green border इस्तेमाल कर सके
    • Context की जगह CSS custom properties का सक्रिय उपयोग करके इसका workaround किया गया
  • RSC execution location और data fetching के तरीकों में flexibility देता है, लेकिन इसके बदले जटिलता भी बढ़ती है
    • नए developers को लगातार देखना पड़ता है कि “क्या server पर चल रहा है और क्या client पर”
    • हर PR में बेवजह client तक भेजे गए code पर feedback आता था
    • development के दौरान यह जाँचने के लिए अक्सर console.log डाले जाते थे कि log server का है या browser का
    • caching भी अपनी अलग जटिलता जोड़ती है

Next.js 13 में RSC इस्तेमाल करने का मूल तरीका

  • लिखे जाने के समय production-ready RSC implementation Next.js 13 का app directory था
  • Next.js 13 app directory में by default लिखा गया component Server Component होता है
    • default स्थिति में page code client को नहीं भेजा जाता
    • client को सिर्फ HTML दिया जाता है
  • Server Component पर async लगाने से component के अंदर data fetch किया जा सकता है
  • जिन Server Components में धीमा data fetching हो, उन्हें React.Suspense से wrap किया जा सकता है
    • client को पहले fallback UI दिखता है
    • server data fetch और rendering पूरा करके result component को stream करता है
  • Suspense boundary का उपयोग सिर्फ data streaming के लिए नहीं, बल्कि user interaction के हिसाब से किसी हिस्से की hydration priority समायोजित करने वाली selective hydration के लिए भी किया जा सकता है
  • जो code client पर चलना चाहिए, उसके लिए file के ऊपर "use client" जोड़ा जाता है
    • onClick listener या useState जैसे client state और interaction वाले components में इसका उपयोग होता है
    • "use client" लगे component द्वारा import किए गए सभी components भी client को भेजे जाते हैं
  • जो libraries RSC को support नहीं करतीं, उन्हें Client Component में import करके client bundle में शामिल किया जा सकता है
    • इसका उदाहरण @mux/mux-player-react को wrap करने वाला ClientMuxPlayer component है

Server Component और Client Component चुनने के मानदंड

  • Server Components उस code के लिए उपयुक्त हैं जिसे client तक भेजने की ज़रूरत नहीं है
    • blog post body render करना
    • code block syntax highlighting जैसे महंगे काम
    • data fetching
  • Client Components उस UI के लिए बेहतर हैं जो user input पर react करता है या समय के साथ state बदलता है
    • useState
    • event listeners
    • client-side interaction
  • अगर पूरे app को Client Components से बनाया जाए, तो वह पारंपरिक SSR framework जैसा व्यवहार करता है
  • पूरे app को एक साथ Server Components में बदलना ज़रूरी नहीं है; जहाँ सबसे अधिक लाभ हो, वहाँ से gradual adoption किया जा सकता है

वास्तविक codebase में इसे धीरे-धीरे लाने के 3 चरण

  • Mux ने जो playbook अपनाई, उसमें तीन चरण थे
    • app root में "use client" directive जोड़ना
    • उस directive को rendering tree में जितना संभव हो उतना नीचे ले जाना
    • performance issues दिखने पर advanced patterns लागू करना
  • चरण 1 में Next.js 13 की top-level page.tsx में "use client" जोड़कर पहले जैसा behavior रखा गया
  • अगर server-side data fetching चाहिए, तो Client Component के parent के रूप में Server Component जोड़ा जा सकता है
    • Server Component data fetch करता है
    • fetched data को props के रूप में Client Component को देता है
    • यह पारंपरिक getServerSideProps की भूमिका ले सकता है
  • चरण 2 में "use client" को top-level component से child components तक नीचे ले जाया जाता है
    • जहाँ client code की ज़रूरत नहीं, जैसे <Title />, वहाँ directive हटाकर उसे pure HTML के रूप में भेजा जा सकता है
    • जहाँ client code चाहिए, जैसे <Player />, वहाँ error आएगा, इसलिए "use client" बनाए रखना होगा
  • यह तरीका नए components और refactor किए जा रहे पुराने हिस्सों में Server Components पर विचार करने के लिए प्रेरित करता है, और bundle size कुछ हद तक घटाने में मदद करता है

performance problems होने पर अपनाए गए patterns

  • Mux की documentation site का ज़्यादातर हिस्सा statically generated है, लेकिन changelog sidebar CMS से आता है
  • sidebar को Suspense में wrap करने पर app के बाकी हिस्से को CMS fetch पूरा होने तक इंतज़ार नहीं करना पड़ता
  • Next.js 13 की loading.js convention भी अंदरूनी रूप से Suspense और streaming का उपयोग करती है
  • बड़ी libraries को server पर बनाए रखने के लिए Client Components और Server Components की placement समायोजित करनी पड़ती है
    • उदाहरण के तौर पर syntax highlighting library Prism को server पर रखा गया

Client Component के अंदर Server Component मिलाने का तरीका

  • Client Component द्वारा import किए गए components साथ में Client Component बन जाते हैं
  • अगर Server Component को Client Component के child के रूप में रखना हो, तो उसे import न करके children या props के रूप में पास करना चाहिए
    • Server Component server पर render होता है
    • उसका serialized result Client Component को दिया जाता है
  • गलत तरीका यह है कि Client Component file से Server Component को सीधे import किया जाए
  • सही तरीका यह है कि सबसे नज़दीकी parent Server Component तक ऊपर जाएँ और वहाँ से Server Component को child या prop के रूप में Client Component को पास करें

एक file को आधा server/आधा client में नहीं बाँटा जा सकता

  • एक ही file का आधा हिस्सा Server Component और आधा हिस्सा Client Component बनाना संभव नहीं है
  • Mux ने functionality को दो files में बाँटने वाला pattern बार-बार इस्तेमाल किया
    • CodeBlock.server.js: बड़ी syntax highlighting library import करता है और server पर render करता है
    • CodeBlock.client.js: useState और onClick का उपयोग करके user को code examples switch करने देता है
  • server पर render किए गए examples props के रूप में Client Component को दिए जाते हैं, इसलिए server-only काम client bundle में नहीं जाता
  • अगर index.js से CodeBlock.server.js को फिर से export कर दिया जाए, तो users सिर्फ CodeBlock import करके काम चला सकते हैं और उन्हें अंदर की server/client separation के बारे में सोचना नहीं पड़ता

सिर्फ server पर execution सुनिश्चित करने का तरीका

  • शुरुआत में development के दौरान console.log जोड़कर यह देखा जाता था कि log server से आ रहा है या browser से
  • यह सुनिश्चित करने के लिए कि server-only code bundle में शामिल न हो, server-only package import किया जा सकता है
  • server-only बड़े libraries या secret keys को गलत जगह पहुँचने से रोकने में उपयोगी है
  • Next.js यह सुरक्षा भी देता है कि environment variables गलती से browser bundle में शामिल न हों
  • file के top पर server-only बनाए रखना maintenance में भी मदद करता है
    • maintainer तुरंत समझ सकता है कि यह file server पर चलती है

अपनाने का फैसला करते समय लागत और लाभ

  • React Server Components कोई मुफ्त में मिलने वाली सुविधा नहीं है
  • इसकी लागत में सिर्फ CSS-in-JS और React Context की सीमाएँ ही नहीं, बल्कि ये भी शामिल हैं
    • server और client execution location को समझना
    • hydration को समझना
    • infrastructure cost
    • Client Components और Server Components मिलाने से code complexity बढ़ना
  • जटिलता बढ़ने से bugs आने और code maintainability घटने की संभावना बढ़ती है
  • framework इस जटिलता को कम कर सकता है, लेकिन खत्म नहीं करता
  • संभावित लाभ ये हैं
    • छोटा bundle size
    • तेज़ execution
    • SEO के लिए महत्वपूर्ण performance improvement
    • complex और data-heavy sites के लिए advanced data loading patterns
  • अगर टीम इस अतिरिक्त cognitive cost को संभालने के लिए तैयार है और performance gain पर्याप्त है, तो RSC उपयुक्त हो सकता है

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

1 टिप्पणियां

 
GN⁺ 2023-09-03
Hacker News की राय

  • सर्वर-साइड रेंडरिंग में क्लाइंट को ऐसा HTML मिलता है जिसे वह तुरंत देख सकता है
    मैंने भी यह महसूस किया है: सर्वर पर plain text file डालने पर वह browser तक काफ़ी तेज़ी से पहुँच जाती है
    अगर .css पर खत्म होने वाली एक और plain text file डालें, तो browser जानता है कि उसे कैसे process करना है, इसलिए first screen के elements हिल-डुल सकते हैं और दिखने में काफ़ी अच्छे भी लग सकते हैं
    यह एक बढ़िया तरकीब तो है, लेकिन first screen पर पढ़ी जा सकने वाली उपयोगी content की तुलना में फिर भी secondary ही है

    • मेरे छोटे भाई ने इस साल web development सीखना शुरू किया, और जब मैंने बताया कि HTML को HTTP से भेजा जा सकता है, तो वह काफ़ी हैरान रह गया
    • browser मूल रूप से hypertext client के रूप में शुरू हुआ था, लेकिन जाने कब वह एक application platform में बदल गया, जिसके अंदर custom hypertext client जैसी चीज़ें तक implement की जाती हैं
      समझ नहीं आता कि “hypertext को और शक्तिशाली बनाने वाली features जोड़ें” कैसे “अब इस बड़े और inconsistent features के ढेर से काम की application आप खुद implement करें” बन गया
    • अब क्या तुम यह बताने वाले हो कि हर page के लिए code चलाने वाली text file भी भेजी जा सकती है?
    • मुझे लगा था वह technology खो चुकी है

  • RSC में जाने से पहले थोड़ा रुकना बेहतर है
    आप जो भी बनाने की कोशिश कर रहे हों, उसे असली full-stack framework या classical web framework में कहीं ज़्यादा आसान, तेज़ और scalable तरीके से संभाला जा सकता है
    Rails/Django/Laravel/… के साथ Turbolinks/Htmx/… जोड़ सकते हैं, या client-side JavaScript का थोड़ा-सा छिड़काव ही काफी हो सकता है
    अगर आप Elixir/Phoenix जानते हैं, तो कई फायदे साथ में मिल सकते हैं
    चाहे कितने भी लोग tweet करें, RSC में और नीचे नहीं उतरना चाहिए
    industry में 10 साल से कम अनुभव वाले लोग पुराने vanilla PHP sites वाली बुनियादी समस्याओं को फिर से दोहराएँगे, और मैंने तो React components के अंदर inline SQL hooks डाले हुए भी देखे हैं
    इस बार ऊपर से accidental complexity भी कहीं ज़्यादा जुड़ी हुई है
    होश में रहें, असली product जल्दी launch करें और Lamborghini के पैसे कमा लें

    • RSC से CORBA याद आता है
      CORBA local components और remote components को मिलाने का तरीका है, mature है और कई languages में काम करता है
      फिर भी सभी इसे क्यों नहीं इस्तेमाल करते? आज के ज़्यादातर developers ने शायद इसका नाम भी नहीं सुना होगा
      अगर आप एक और distributed component architecture बनाना चाहते हैं, तो यह पढ़ना चाहिए कि CORBA और उसके descendants व्यापक रूप से क्यों नहीं जमे
      hint यह है कि छिपी हुई component boundaries छिपी हुई complexity पैदा करती हैं
      दूसरी ओर “server-rendered HTML” और “client-rendered HTML” वाले दोनों camps ठीक-ठाक चल रहे हैं
      मुझे लगता है कि हर web project में दोनों options इस्तेमाल कर पाना काफ़ी सौभाग्य की बात है
      आशा है कि RSC पर काम pure client-rendered apps के लिए React support को धुंधला नहीं करेगा
      1. https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
    • अगर आप Elixir/Phoenix जानते हैं, तो यह बात सच में सही है
      अगर आपको पूरी तरह progressive rich front-end app की सख्त ज़रूरत नहीं है, तो ज़्यादातर चीज़ें LiveView कम-से-कम JavaScript के साथ server-side components के ज़रिए संभाल देता है
      इतना ही नहीं, हर user के लिए server-side thread जुड़ा रहता है, जिससे explicit JavaScript handlers के बिना भी changes को user के frontend तक actively push किया जा सकता है
    • यह बात सचमुच सही है
      लगता है industry को 10 साल के cycle वाली memory loss हो गई है
      server-rendered UI से दूर जाने के बहुत अच्छे कारण थे
      बेशक search engine optimization वाला तर्क हमेशा रहता है, लेकिन अगर वही चिंता है तो बस traditional server template site बना लें
      ज़्यादातर single-page apps को SSR और उसकी complexity की बिल्कुल ज़रूरत नहीं होती
    • मैं Mux में काम करता हूँ, और मज़ेदार fact यह है कि Elixir शुरू से ही हमारे infrastructure का core component रहा है
      शुरुआती dashboard interface पूरी तरह Phoenix से render होते थे, और केवल वे pages अलग से React include करते थे जिन्हें सच में advanced client interactions की ज़रूरत होती थी
      चूँकि हमारा पहला product analytics dashboard था, यह situation जल्द ही लगभग पूरे dashboard में बदल गई, और customers को expose की गई API का उपयोग करके एक full single-page app में जाना स्वाभाविक लगा
      वह 2016 था, इसलिए LiveView नहीं था, लेकिन अगर आज वही product फिर से बनाते तो क्या अलग फैसला लेते, इस बारे में मुझे यकीन नहीं है
      blog post उस application के बारे में है जो public marketing site चलाती है और उसकी requirements काफ़ी अलग हैं, लेकिन मैं यह बताना चाहता था कि हम भी Elixir/Phoenix इस्तेमाल करते हैं और उसे पसंद करते हैं

  • मुझे लगता है मैं बूढ़ा हो रहा हूँ
    आजकल के frameworks बहुत बड़े और जटिल हैं
    एक साधारण web “Hello world” के लिए भी विशाल build और compile pipeline चाहिए, और अब इसमें server-side components भी जुड़ गए हैं
    मैं सच में जानना चाहता हूँ कि overhead कितना है
    Hello world example चलाने के लिए frontend और backend framework code की कितनी परतों से गुजरना पड़ता है, पता नहीं
    मैं तो वापस उसी 10KB वाले साधारण component framework पर जाऊँगा, जहाँ F5 दबाते ही फिर से build हो जाता है

    • ये frameworks साधारण Hello world app को हल करने के लिए नहीं बनाए गए हैं
    • कई websites शायद सिर्फ HTML और CSS से बनाई जाएँ तो हर लिहाज से बेहतर होंगी, यही बात खलती है
      भविष्य में शायद कभी आने वाले fancy features के लिए यह बहुत जल्दी optimization करने जैसा है
      यह कुछ ऐसा है जैसे मुर्गियों का दड़बा बनाने से पहले core sample निकालने और seismic modeling करने के लिए engineer hire करना ज़रूरी बताया जाए
    • इसी वजह से complexity से बाहर निकलने की हलचल दिख रही है
      युवा developers अब इसे देखना शुरू कर चुके हैं
      जैसे हमने SOAP और XML जैसी डरावनी चीज़ों को छोड़कर ज़्यादा सरल और इस्तेमाल में आसान technologies अपनाईं, वैसे ही यह पीढ़ी भी फिर से सीख रही है कि complexity नुकसानदेह है
      शायद नई पीढ़ी के फिर से गड़बड़ करने से पहले कुछ सालों के लिए software development फिर से मज़ेदार हो जाए
    • इस तरह का नज़रिया सच में चिढ़ाता है
      pipeline किसी खास use case के हिसाब से जितनी ज़रूरी हो उतनी जटिल या सरल हो सकती है
      आप सिर्फ static files से बना सकते हैं, esbuild command वाली छोटी Makefile से भी, या 30 plugins वाली विशाल Webpack configuration से भी
      जो बना रहे हैं उसकी ज़रूरतों और complexity के हिसाब से आप कुछ भी चुन सकते हैं
      साथ ही tools को इस आधार पर आँकना कि उनसे simple Hello world बनाना आसान है या नहीं, तभी उपयोगी है जब काम सच में ऐसे apps बनाने का हो
    • इस blog post ने SSR को मेरे देखे ज़्यादातर posts से बेहतर संभाला है
      जब भी SSR या उसके derivatives बातचीत में आते हैं, मैं हमेशा खुद से पूछता हूँ कि कहीं यह बेवजह और जटिल तो नहीं हो रहा
      React server rendering components कुछ ज़्यादा ही दूर तक चले गए लगते हैं, और natural developer experience के flow के खिलाफ हैं
      अगर application की complexity दोगुनी हो जाए, coding pitfalls बढ़ जाएँ, developers धीमे और confused हो जाएँ, और बदले में सिर्फ छोटा-सा performance gain मिले, तो सवाल है कि क्या यह वाकई इसके लायक है
      पुराने PHP sites और single-page app के बिना Rails apps भी लंबे समय तक अच्छी तरह चलते रहे हैं

  • Next.js और नए app directory structure से नया application बनाते हुए मेरा अनुभव रहा है
    पहला, यह समझना मुश्किल है कि क्या server पर हो रहा है और क्या client पर
    जानने के लिए investigation करनी पड़ती है, लेकिन code तेजी से लिखते समय अक्सर इस पर ज्यादा ध्यान नहीं जाता
    छोटे से बदलाव से page का बड़ा हिस्सा अचानक server से client पर जाने लगे, ऐसा आसानी से हो सकता है
    मुझे पता है कि final release से पहले हर page पर सावधानी से और समय लगाने वाली verification करनी पड़ेगी, और यह अच्छी बात नहीं है
    दूसरा, existing React libraries का बड़ा हिस्सा hooks इस्तेमाल करता है, इसलिए यह माना जाता है कि वे client पर चलती हैं
    इसकी वजह से code client की ओर खिंच सकता है
    नए paradigm से जूझने का मकसद fast loading और search engine optimization के लिए server-side rendering है, लेकिन imported library अगर ठीक से साथ न दे तो यह पूरी तरह बेकार हो जाता है
    तीसरा, नए Next.js app directory paradigm में bugs हैं
    यह अभी नया और बहुत जटिल है, इसलिए dynamic routes और parallel routes, और उनका interaction पूरी तरह टूट सकता है
    मैंने खुद Next.js GitHub पर issue डाला था और उस पर “मेरे साथ भी ऐसा है” जैसे कई comments आए
    मैं जो एक approach इस्तेमाल कर रहा था, उसे हाल ही में Vercel developer ने ठीक किया, लेकिन तब तक मैं workaround के लिए दूसरी approach चुन चुका था
    सबसे चिढ़ाने वाली बात यह है कि development environment lazy loading और caching magic इस्तेमाल करता है
    लगता है कि यह page differences calculate करके websocket जैसी किसी चीज़ से partial updates भेजने की कोशिश करता है, लेकिन यह पूरी तरह बिगड़कर ऐसी हालत में जा सकता है जहाँ से recover नहीं होता
    कभी-कभी recompilation server से client तक कोई communication trigger करता है, और जब Chrome tab पर वापस जाते हैं तो tab पूरी तरह freeze हो जाता है, इसलिए Chrome task manager से process kill करना पड़ता है
    कुल मिलाकर यह अभी बहुत नया है और इसमें बहुत सारे rough edges हैं

    • “existing React libraries का बड़ा हिस्सा hooks इस्तेमाल करता है, इसलिए यह माना जाता है कि वे client पर चलती हैं” वाले हिस्से में hooks नहीं, शायद context कहना था?
      कई hooks server side पर भी काम करते हैं, और असल में value initialize करने के अलावा कुछ नहीं करते

  • यह बात दिलचस्प है कि PHP और JavaScript की syntax असल में लगभग एक जैसी थी
    फर्क बस $ symbol या var keyword जैसा था, लेकिन NodeJS ने कहा, “हम server पर JS चलाना चाहते हैं”
    और 15 साल बाद JavaScript आखिरकार पकड़ में आ गई और असल में PHP जैसी हो गई, बस abbreviations ज़्यादा हैं और learning curve ज़्यादा steep है
    बेशक Suspense के साथ server से client components तक data stream करना शानदार है
    मैं NextJS 13 इस्तेमाल कर रहा हूं, और यह SSR को उतना ही आसान बना देता है जितना PHP में हमेशा संभव था; यह बात अच्छी लगती है और मैं इसे जोरदार recommend करता हूं

    • निष्पक्ष होकर कहें तो PHP 7 से पहले, समय के हिसाब से, वह या तो कूड़ाघर था या उससे भी ज़्यादा खतरनाक चीज़
      जब लोग उसे “bad design का fractal” कहते थे तो वह 100% जायज़ था, और समस्या हल करने के लिए लोगों का दूसरी जगह देखना भी सही था
      आज PHP कहीं बेहतर language है और उसे दोबारा देखने लायक है, लेकिन यह दिखावा नहीं करना चाहिए कि वह पहले से ही आज जितनी अच्छी थी
      और React ecosystem के आधार पर NodeJS को judge नहीं करना चाहिए
      React-based systems चलाने के लिए जितनी भारी मात्रा में API और wrappers चाहिए, वह React community की जिम्मेदारी है
      यह typical Stockholm syndrome है
    • PHP में client-side rendering नहीं है, इसलिए यह अजीब तुलना है
    • यह बात अक्सर नज़रअंदाज़ कर दी जाती है कि browser खुद भी काफी बेहतर हुए हैं
      कई modern advances इसलिए संभव हुईं क्योंकि पहले browsers बेहतर हुए
      यह पूरी तरह एक चक्कर लगाकर वहीं लौट आना नहीं है; बल्कि बहुत दूर से देखने पर circle जैसी दिखने वाली कोई गांठ है
    • मुझे NodeJS कभी पसंद नहीं आया
      एक तरफ, concurrency model की वजह से इससे तेज़ backends बनाना संभव हुआ, इसलिए यह innovative था, लेकिन इसमें Java या PHP जैसी मौजूदा backend languages की कई capabilities नहीं थीं, और इसलिए कई patterns फिर से invent किए गए
      language को खुद भी उस “safety” level तक पहुंचने में कई साल लगे जो Java के पास पहले से था और जिसकी ओर PHP बढ़ रहा था
      XML और उससे मिलने वाली contractual guarantees जैसी proven और standardized technologies को भी यह कहकर छोड़ दिया गया कि वे भारी हैं और JSON इंसानों के पढ़ने-लिखने के लिए अच्छा है
      मुझे लगता है कि XML छोड़ने से बहुत समय और मेहनत गंवाई गई
      REST/JSON API documentation अब भी दर्दनाक है
      20–25 साल पहले XML payloads से data models और parsers पहले से generate किए जा सकते थे
      XML में आखिर इतनी समस्या क्या थी, यह मुझे अब भी समझ नहीं आता
      wire पर वह JSON से थोड़ा भारी था, लेकिन compression इस्तेमाल करके या EXI(https://www.w3.org/TR/exi/) के जरिए binary protocol में बदलकर यह हल हो सकने वाली समस्या थी
      मुझे नहीं पता कि EXI सच में अपनाया गया या नहीं, लेकिन उस समय XML कितनी मात्रा में इधर-उधर जा रहा था, यह देखते हुए मुझे उससे काफी उम्मीद थी
    • लगता है NodeJS बनाए जाने की मूल वजहों में से बहुत-सी भुला दी गई हैं
      उस समय non-blocking I/O से बड़ा performance boost मिलता था
      लेकिन modern developers के दिमाग में शायद यह JSON उगलने या toolchain host करने वाला कोई बेवकूफ tool भर बनकर रह गया है

  • शायद लोग वही इस्तेमाल करते हैं जिससे वे परिचित हैं, लेकिन docs site के लिए caching वाले ready-made static site generator या CMS के बजाय React इस्तेमाल करना बर्बादी जैसा लगता है
    developer के नजरिए से React ज़्यादा मजेदार हो सकता है

    • शानदार docs sites में छोटे-छोटे dynamic हिस्से बहुत होते हैं
      Stripe ने ऐसा flow शुरू किया जिसमें account API key वाले code snippets दिखते हैं ताकि उन्हें तुरंत test किया जा सके
      frontend docs sites में लगभग हमेशा executable examples होते हैं जिन्हें सीधे docs के अंदर interact करके आज़माया जा सकता है
    • यह बात मैं अक्सर सुनता हूं, लेकिन ठीक से समझ नहीं पाता
      नया project bootstrap करना बहुत आसान और तेज़ है, सचमुच pure HTML project शुरू करने से भी आसान
      मैं क्या miss कर रहा हूं?
      साथ ही, downvote करने वालों का नजरिया मुझे सच में जानना है
    • सहमत हूं
      यह static content है, तो search box के लिए थोड़ा JavaScript जोड़कर HTML के रूप में generate क्यों नहीं किया जाता, समझ नहीं आता
    • यह statically generate हो रहा है
      React इस्तेमाल करने की वजह पूरे frontend में एक ही language इस्तेमाल करना है
      इससे यह बंटवारा टाला जा सकता है कि कोई एक site पर React इस्तेमाल करे और कोई दूसरा Gatsby/Hugo
      Next.JS वही काम कर सकता है जो Gatsby/Hugo करते हैं, साथ में इसमें ज़्यादा features हैं और यह React-based है
    • “developer के नजरिए से ज़्यादा मजेदार” असल में software developers और employers दोनों पर पड़ा श्राप है

  • मैं इतना पुराना हूँ कि वह दौर याद है जब server सब कुछ render करता था, और CSS व Javascript का इस्तेमाल rendered page को बेहतर बनाने के लिए होता था
    वेब बहुत अंधेरी और over-engineered जगह बन चुका है
    लगभग यकीन करना मुश्किल है
    इसलिए apps बनाने का मेरा तरीका पहले server rendering करना और बाद में enhancement जोड़ना है

    • ज़्यादातर सहमत हूँ
      collapsible dropdown या jQuery drag-and-drop होना अच्छी बात है, लेकिन js/jQuery के दौर का state management hell भी साफ़ याद है, इसलिए वहाँ वापस नहीं जाना चाहता
    • JavaScript इस्तेमाल कर रहे हो?
      मज़ाक कर रहा हूँ; मेरा पहला Geocities page सिर्फ़ visitor counter या marquee जैसी चीज़ों वाला HTML था
      स्कूल में बनाया पहला PHP application/project भी अभी JS इस्तेमाल नहीं करता था; static menu और header के लिए frames इस्तेमाल होते थे और data बस form submit करके backend को भेज दिया जाता था
      ऐसा भी एक दौर था
      university course में शामिल पहली एक साल की internship में Java backend, presentation layer के JSX templates, और dialogs या animated accordion जैसी चीज़ों के लिए PrototypeJS इस्तेमाल किया
      तब animation का मतलब था “इस element की height को प्रति सेकंड कुछ बार बदलना”
      पहली नौकरी में cart में add करना, image carousel जैसी चीज़ों से page को enhance करने वाला JS बहुत इस्तेमाल किया, और वह jQuery का दौर था
      अगली नौकरी में customer support staff के SAP जैसी चीज़ें देखने के लिए UI को BackboneJS से बहुत खराब तरीके से बनाया
      उसके बाद का काम भी customers के लिए investment banking frontend को BackboneJS से फिर से बनाना था
      वह उस समय कही जाने वाली single-page application के लिए बहुत अच्छी fit use case थी
      search engine optimization की ज़रूरत नहीं थी, pure frontend rendering काफ़ी तेज़ थी, API-centric थी, और वह समय था जब लोगों को समझ में आ रहा था कि web और mobile के लिए एक ही API इस्तेमाल की जा सकती है
    • दूसरे नज़रिए से, मुझे CSS और Javascript के invent होने का दौर भी याद है और तब से websites बना रहा हूँ
      मेरे हिसाब से web development tools कभी भी आज से बेहतर नहीं रहे, और user experience भी वर्षों में बहुत ज़्यादा सुधरा है
      जिसे हम AJAX कहते थे, वह एक साफ़-सुथरे add-on खिलौने से बढ़कर client components और single-page apps के रूप में रोज़मर्रा की बुनियादी चीज़ बन गया
      server चाहें तो अब भी powerful है, लेकिन dashboards, maps, games, forums, office apps, online IDE जैसे interactive apps में मजबूत client-side capability अच्छी होती है
      इसी वजह से रोज़मर्रा के apps हर operating system के लिए बने custom desktop apps से हटकर सभी laptops और desktops को cover करने वाले universal platform पर बड़े पैमाने पर जा पाए
      बेशक उस ताकत के लिए ज़्यादा complexity चाहिए थी
      HTML/CSS में blog या landing page लिखना और पूरा web app लिखना बहुत अलग चीज़ें हैं
      Angular और React उस दौर में बनाए गए थे जब server-side languages की तुलना में JS runtime और भाषा खुद कहीं ज़्यादा primitive थे, ताकि पहले से कई गुना complex apps बनाने में मदद मिल सके
      2010s के आख़िरी हिस्से में सचमुच दर्दनाक दौर था, जब कई JS frameworks समस्या के बहुत छोटे-छोटे हिस्से ही हल कर रहे थे
      आजकल ऐसा कम है
      Next जीत गया है और default बन गया है, और इसके अच्छे कारण हैं
      यह मध्यम complexity वाले apps के लिए abstraction का सही level देता है, और server-side rendering व client-side pages को अच्छी तरह mix करने देता है
      React server components उस distinction को और साफ़ first-class concept बना देते हैं
      हालांकि यह केवल एक certain complexity से ऊपर ही meaningful है
      ज़रूरत न हो तो इस्तेमाल न करें
      अगर mostly static blog या documentation site है, तो simpler architectures मौजूद हैं
      अब भी HTML लिख सकते हैं और जितनी ज़रूरत हो उतनी ही JS की कुछ lines छिड़क सकते हैं, और ज़्यादातर small businesses के लिए WordPress या Wix भी इस्तेमाल हो सकता है
      लेकिन अगर आप अधिक complex app बना रहे हैं, तो हर छोटे interaction के लिए server round trip करके UI को फिर से calculate करना और हर बार पूरा HTML page भेजना—उस तरीके की तुलना में React सचमुच सपना जैसा है
      वह तरीका context और page position, आधा भरा हुआ form आदि खो देता था, form data को state की तरह इस्तेमाल करने के लिए उकसाता था, और गलती से back दबाने या आसान cloud scaling आने से पहले अक्सर server failures के कारण काम खो जाना आम था
      मेरे हिसाब से यह over-engineering सिर्फ़ तब है जब इसे गलत जगह लागू किया जाए
      सही use cases में ये tools सचमुच उपयोगी हैं और कभी-कभी essential भी
      अफ़सोस की बात शायद यह है कि जहाँ ज़रूरत नहीं होती या उल्टा नुकसानदेह होता है, वहाँ भी इन्हें बहुत ज़्यादा सिखाया और इस्तेमाल के लिए प्रोत्साहित किया जाता है
      आखिरकार काम के हिसाब से tool इस्तेमाल करना चाहिए
      मेरा मतलब React को Vue, Svelte, HTMX से आगे धकेलना नहीं है, बस यह है कि client-side complexity की भी utility है
    • यही approach, यानी server components, इसी के लिए हैं

  • मुझे लगता है React ज़्यादा modern, आसान, तेज़ और सस्ते alternatives की बराबरी करने की कोशिश कर रहा है
    लेकिन मूल समस्या—re-rendering, बार-बार ज़रूरी memoization, leaking abstractions—को ठीक करने के बजाय React और complex होता जा रहा है
    अगर अंतिम परिणाम शानदार होता तो मैं इस मेहनत को समझता, लेकिन ऐसा नहीं है
    real-world में React benchmarks में दिखने से ज़्यादा slow है, और Next तो उससे भी worse है
    हाल में Next से बनी बहुत slow websites मैंने बहुत देखी हैं
    सचमुच समझ नहीं आता
    अगर React team React को improve करना चाहती है तो core को ठीक करना होगा

    • वे ठीक नहीं कर सकते
      अब ecosystem dependencies इतनी ज़्यादा हैं कि चीज़ें टूटेंगी
      Target.com, Walmart.com, Microsoft Teams और अनगिनत sites React पर हैं
      बहुत बड़ा component ecosystem और उस पर बनी companies भी हैं
      core concept टूटा हुआ है, लेकिन उसे ठीक करने का मतलब बाकी सब कुछ तोड़ देना हो सकता है
      अगर वैसे भी सब कुछ तोड़ना है, तो कुछ और इस्तेमाल करना बेहतर है
      अब dependencies के mass की वजह से React से बंधे रहकर आगे चलते रहना ही पड़ेगा
      React re-rendering को default बनाता है और उससे opt out करना पड़ता है, जबकि Vue, Solid, Preact, Svelte सभी जहाँ ज़रूरत हो वहाँ opt in करने वाले तरीके पर हैं
      यही एक मुख्य वजह है कि इसे सही तरह से इस्तेमाल करना मुश्किल है और कुछ खास तरह के bugs के लिए यह vulnerable है
      बाहर से यह सामान्य JavaScript जैसा दिखता है, फिर भी लगातार ध्यान रखना पड़ता है कि कब opt out करना है; दूसरे frameworks में ऐसे bugs rare या लगभग न के बराबर हैं
    • re-rendering और बार-बार ज़रूरी memoization के लिए यह काम चल रहा है
      https://react.dev/blog/2023/03/22/react-labs-what-we-have-be...

  • मुझे समझ नहीं आता कि अब जाकर backend में React का इस्तेमाल करके HTML render क्यों किया जा रहा है
    क्या हम 10 साल पहले वापस जाना चाहते हैं?

    • “उस environment” में template system होना सच में बहुत मूल्यवान है
      इन दिनों मैं अक्सर Svelte और Django templates के बीच आना-जाना करता हूँ, और सिर्फ इस वजह से कि Svelte DOM को जानता है, experience कहीं बेहतर हो जाता है
      JS के अलावा किसी template system में मैंने ऐसा कभी नहीं देखा
      PHP और jQuery वगैरह का भी अनुभव रहा है
    • React का programming model लोगों को आकर्षक लगता है, और React HTML जैसे predictable output वाली समस्याओं के लिए अच्छी तरह fit बैठता है
      ऊपर से अगर frontend React में है, तो सारी HTML generation को एक जगह रखना कहीं आसान हो जाता है
    • 25 साल के “senior” developers को अपने ego को सहारा देने के लिए किसी पुरानी technology को नीचा दिखाने की जरूरत थी, और PHP उनका निशाना बन गया
    • क्योंकि Vercel आपका backend host करना चाहता है, और React की तरफ हाथ बढ़ा रहा है
    • यह ज्यादातर दूसरे template systems से बेहतर है, और जब interactivity जोड़नी हो तो एक ही language और paradigm में काम हो जाता है, इसलिए अच्छा है
      साथ में static type support भी है

  • मैं RSC या React को अब तक का सबसे अच्छा समाधान बताकर बचाव करने की कोशिश नहीं कर रहा, लेकिन यहाँ की कुछ आपत्तियाँ अधपकी हैं
    React/RSC के फायदे तकनीकी रूप से server द्वारा HTML/CSS और थोड़ी JavaScript लौटाने के समान नहीं हैं
    यह अब भी एक ही app है, और SSR/hydration की तुलना में client/server boundary को ज्यादा intelligent तरीके से संभालने का तरीका है
    React ने खुद को किसी dead end में design कर दिया है या उससे निकलने का रास्ता क्या है—इस पर ज्यादा जानकार आपत्तियाँ मैं खुशी से पढ़ना चाहूँगा, लेकिन PHP पर लौट जाना जवाब नहीं है

    • आजकल HN अच्छी frontend perspective पाने की अच्छी जगह नहीं है
      React सीखना इतना मुश्किल भी नहीं है, और non-developers भी bootcamp के कुछ हफ्तों में basic चीजें सीख लेते हैं, इसकी वजह है
      JSX, Django, PHP, Rails के template systems से objectively बेहतर है
      यूँ ही फेंकी जाने वाली आधी आपत्तियों में तो लगता है कि लोगों ने Lighthouse जैसी चीजों से अपने projects का benchmark भी नहीं किया होगा