आपको Next.js की ज़रूरत नहीं है - हमने Next से React में माइग्रेट क्यों किया

 (comfydeploy.com)
23 पॉइंट द्वारा GN⁺ 2025-01-03 | 17 टिप्पणियां | WhatsApp पर शेयर करें
  • ComfyDeploy डैशबोर्ड को Next.js से React में माइग्रेट करने के बाद मिले नतीजे:
    • बिल्ड समय 3 मिनट → 18 सेकंड तक घट गया
    • हॉट रीलोड 200ms से कम तक बेहतर हुआ
    • टीम के सदस्य कहीं ज़्यादा संतुष्ट रहे
  • शुरुआत में हमने Next.js का उपयोग करके एक full-stack application बनाया था, और Drizzle व Server Actions की वजह से type safety और साफ़ कोड के साथ यह अच्छी तरह काम कर रहा था, लेकिन बाद में ये समस्याएँ सामने आईं:
    • एक खास user की वजह से Vercel पर $2,000 का ऊँचा API खर्च आया
    • API testing की जटिलता बढ़ गई: Server Actions और API routes आपस में मिल गए
    • धीमा बिल्ड समय और अक्षम local development environment
    • छोटे बदलाव पर भी पूरा SSR reload हो जाता था
  • समस्याएँ
    • Next.js की बढ़ती जटिलता: Next.js का all-in-one (full-stack) approach, ऐप के बढ़ने के साथ development complexity बढ़ाता गया
    • हमारा डैशबोर्ड मुख्य रूप से React-आधारित है, और उसे Next.js की server capabilities की ज़रूरत नहीं है
  • Next.js से React में बदलाव
    • TanStack Router और Rspack का उपयोग करके Next.js से React में बदलाव किया
      • development server शुरू होने में: 2 सेकंड से कम
      • Vercel build time: 18 सेकंड
    • API setup बेहतर हुआ, अनावश्यक dependencies हटाईं, और कोड को सरल बनाकर productivity बढ़ाई
  • प्रदर्शन तुलना
    • Next.js 15 (Turbo mode के साथ)
      • पहला page build: 10.4 सेकंड
    • React + TanStack Router + Rspack
      • route calculation: 200ms से कम
      • initial bundle build: 1.67 सेकंड
  • trade-offs
    • जो खोया
      • frontend और backend code की co-location: frontend और backend को अलग करने से boundaries ज़्यादा स्पष्ट हो गईं
      • Next.js की caching functionality: real-time updates वाले बहुत से data के कारण इसे custom caching से बदला गया
      • pre-rendering और initial load: Static Generation की जगह बेहतर UX लागू किया गया - अब disabled buttons नहीं दिखते
      • server components और actions: server components का "जादू" खो गया, लेकिन ज़्यादा intentional API design से सुधार हुआ
    • जो मिला
      • API contract design और मज़बूत हुआ
      • caching सिर्फ़ वहीं लागू की गई जहाँ ज़रूरत थी
      • data flow और state management को सोच-समझकर डिज़ाइन किया गया
  • निष्कर्ष
    • Next.js landing pages और SEO जैसे कामों के लिए उपयुक्त है, लेकिन ज़्यादातर products के लिए यह अनावश्यक जटिलता लाता है
    • landing pages और SEO के लिए अब भी Next.js का उपयोग किया जाता है
    • dashboard को Pure React + TanStack Router + Rspack में बदला गया
    • API को Python FastAPI server पर Google Cloud Run में चलाया जाता है और ज़रूरत के अनुसार अपने-आप scale होता है
  • सही tool चुनना महत्वपूर्ण है, और हमारे लिए Next.js ज़रूरत से ज़्यादा था

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

17 टिप्पणियां

 
zerocyber 2025-01-04

हमारी कंपनी में front-end को next.js पर
एकीकृत/माइग्रेट करने की तैयारी चल रही है, ऐसे समय में यह लेख पढ़कर काफी सोचने पर मजबूर होना पड़ रहा है....
 
nemorize 2025-01-04

हम केवल ऐसी सेवाएँ चलाते हैं जहाँ mobile "app"-first संभव है।
जहाँ SEO की ज़रूरत होती है, वहाँ हम React (या उसके जैसे किसी विकल्प) का इस्तेमाल ही नहीं करते और उसे बहुत हल्का रखते हैं।
वेब का उपयोग केवल SEO आकर्षण के लिए करते हैं, और app की ओर ले जाते हैं...
 
beenzinozino 2025-01-04

"सही टूल चुनना महत्वपूर्ण है, और हमारे लिए Next.js ज़रूरत से ज़्यादा था"

लगता है कि आखिरी पंक्ति ही सबसे अहम बात है।

सही टूल चुनने के लिए इस तरह की कई तरह की असफलताओं का अनुभव करना भी महत्वपूर्ण लगता है।
 
iolothebard 2025-01-03

अगर SEO की ज़रूरत है, तो इसका मतलब है कि content ही मुख्य है,
लेकिन जब UI components(?) और state ही केंद्र में हों… तो SSR, ISR, Hydrate… जैसी अजीब जीव-जंतु पैदा हो जाते हैं…
 
schang124 2025-01-03

मैं इस बात से काफ़ी हद तक सहमत हूँ.
मैं SEO की ज़रूरत न हो तो कभी भी Next.js नहीं अपनाता.
ऊपर की पोस्ट की तरह, अगर सिर्फ React इस्तेमाल किया जाए तो इसके कई फायदे हैं:

  • Next.js की अपनी अनावश्यक जटिलता और पैटर्न खत्म हो जाते हैं.
    • maintenance ज़्यादा सरल हो जाता है
  • अनावश्यक SSR लागत से मुक्ति मिलती है
  • Router, bundler आदि जैसे FE infra libraries के चुनाव की गुंजाइश बढ़ जाती है
 
jhj0517 2025-01-03

मुझे ठीक से नहीं पता, लेकिन लगता है कि build time में काफ़ी अंतर है।
 
bichi 2025-01-03

लगता है आपको अभी तक पता नहीं चला कि react दूसरे frameworks की तुलना में कई वजहों से धीमा है
 
slowandsnow 2025-01-03

क्योंकि speed इतनी महत्वपूर्ण नहीं है। अगर speed महत्वपूर्ण होती, तो आज भी expressjs इस्तेमाल नहीं हो रहा होता। community और libraries की संख्या बेहद ज़्यादा है।
 
devheerim 2025-01-03

लगता है फोकस Next से React में migration करने पर है, haha
 
bbulbum 2025-01-03

React कम्युनिटी ने शुरुआती चरण में CRA को छोड़कर frameworks की तरफ रुख कर लिया, इसलिए नहीं पता कि इसके खिलाफ जाना आसान विकल्प है या नहीं।
 
sacru2red 2025-01-03

ज़्यादातर चीज़ें vite पर चली गईं, और framework अभी भी ज़रूरत के मुताबिक इस्तेमाल कर रहे हैं।
 
bbulbum 2025-01-06

अगर आप कोई नया application या पूरी साइट React से बना रहे हैं, तो framework इस्तेमाल करने की सलाह दी जाती है.

क्योंकि react.dev पर ऐसा ही लिखा है~
 
kandk 2025-01-03

दिलचस्प है। क्या React की तुलना में Next ज़्यादा भारी है?
मैंने Next में सिर्फ़ project setting ही करके देखा है, और उसमें project setup करके development शुरू करना बहुत आसान लगा था।
 
cichol 2025-01-03

"सरलता से" <= इसे हासिल करने के लिए बहुत सारे trade-off पैदा करने वाला छिपा हुआ magic(?) मौजूद है।
 
beenzinozino 2025-01-04

सहमत हूँ। Next.js की सतह के नीचे बहुत सारी भारी dependencies छिपी हुई हैं...
 
GN⁺ 2025-01-03
Hacker News की राय

  • बहुत से लोग इस बात पर ज़रूरत से ज़्यादा ध्यान दे रहे हैं कि क्या उनके आइडिया को अरबों यूज़र्स तक स्केल किया जा सकता है। इसी वजह से कभी-कभी ऐसी वेबसाइटों में भी Kubernetes इस्तेमाल किया जाता है जिन पर सिर्फ़ 5 विज़िटर आते हैं। मैंने छात्रों को Next.js का इस्तेमाल करके ऐसी वेबसाइटें बनाते भी देखा है जिन्हें बस साधारण HTML + CSS से लिखा जा सकता था

  • मैंने Next.js से प्रोजेक्ट बनाया, लेकिन यह इस्तेमाल करने में जटिल लगा। क्लाइंट और सर्वर के बीच cookie access API अलग है, और environment variables को process.env.NEXT_PUBLIC_* से access करना पड़ता है, जिससे भ्रम होता है। मैं ऐसा कोड लिखना चाहता था जो क्लाइंट और सर्वर दोनों पर बहुत कम बदलाव के साथ चले, लेकिन ऐसा नहीं था। Next.js जो देता है, उसके मुकाबले इसकी learning और overhead मुझे क़ीमती नहीं लगी

  • कोडबेस ज़्यादा सरल हो गया और पेज rendering की गति भी तेज़ हुई। यह देखकर अफ़सोस होता है कि community बिना ज़रूरत ऐसे frameworks की ओर धकेली जा रही है। ज़्यादातर लोगों को बस npx rsbuild init की ज़रूरत है। rspack और rsbuild से मुझे एक simple router और खूबसूरत सादगी मिली

  • मैं Next.js v14 रिलीज़ के बाद से इसका इस्तेमाल कर रहा हूँ, और इससे बहुत संतुष्ट हूँ। RSCs की वजह से client-side JS बंद होने पर भी ऐप के कई हिस्से अच्छी तरह काम करते हैं। इसमें PHP apps जैसी सीधी ताकत है, और साथ ही type system तथा interactive state-based client components को view tree के "leaf level" पर सहजता से शामिल किया जा सकता है

  • Rails और Hotwire की बदौलत मैं React ecosystem की अव्यवस्था से बाहर निकल पाया। state management libraries, meta frameworks, data fetching libraries वगैरह में विकल्प बहुत ज़्यादा हैं। सर्वर से आए डेटा को पेज पर दिखाने जैसे सरल काम को इतना जटिल बनाने की ज़रूरत नहीं है

  • मैं NextJS इस्तेमाल करने वाले CMS(PayloadCMS) में काम करता हूँ, और NextJS मेरे द्वारा इस्तेमाल की गई तकनीकों में सबसे ख़राब है

  • Next.js, React, Vue जैसे भारी frontend frameworks/libraries का इस्तेमाल करने वाले लगभग सभी प्रोजेक्ट्स के लिए backend में templates render करने वाली लाइब्रेरी इस्तेमाल करना बेहतर होगा। कभी-कभी EJS के ज़रिए client-side rendering समझ में आती है। समझ नहीं आता कि framework का इस्तेमाल क्यों किया जा रहा है

  • मैं SEO और crawling optimization के लिए Next.js इस्तेमाल करता हूँ। अगर पेज को crawl किए जाने की ज़रूरत नहीं है (जैसे login के पीछे वाला dashboard), तो Next.js की ज़रूरत नहीं है और pure React ज़्यादा सरल होगा

  • यह देखकर हैरानी होती है कि Next.js एक default starting option बन गया है। 2~3 साल पहले की तुलना में यह बड़ा बदलाव लगता है

  • मैं Vike का इस्तेमाल करके NextJS app को replace करने की कोशिश कर रहा हूँ, और इससे संतुष्ट हूँ। बिना रुकावट के चीज़ों को अपने मनचाहे तरीके से बनाया जा सकता है
 
aer0700 2025-01-03

सिर्फ 5 यूज़र वाले ऐप के लिए k8s... कमाल है