Next.js 15.1+ को Vercel के बाहर के environments में व्यावहारिक रूप से इस्तेमाल नहीं किया जा सकता

• Next.js 15.1.8 से metadata को प्रोसेस करने का तरीका बदल गया है, जिससे Vercel के अलावा अन्य deployment environments में गंभीर समस्याएँ पैदा हो रही हैं
  • metadata अब सीधे HTML head में render नहीं होता, बल्कि "metadata streaming" नाम के तरीके से अलग से भेजा जाता है
• अगर search engine JavaScript execute नहीं करता, तो metadata बिल्कुल दिखाई ही नहीं देता, जिससे SEO को घातक नुकसान होता है
  • crawler detection (htmlLimitedBots) से exception handling की जाती है, लेकिन यह पूरी तरह भरोसेमंद नहीं है
• Vercel के अलावा Netlify, Cloudflare, AWS आदि OpenNext के जरिए compatibility की कोशिश कर रहे हैं, लेकिन व्यवहार में Next.js Vercel infrastructure से इतना कसकर जुड़ा है कि porting खुद बहुत कठिन और bug-prone है
• static build में भी metadata HTML head में शामिल नहीं होता, और संरचना ऐसी हो गई है कि हर deployment environment को जटिल crawler detection/JS execution पर निर्भर होना पड़ता है
• security issue (मार्च 2025 में सार्वजनिक हुई critical vulnerability)
  • metadata streaming से बचने के लिए अगर पुराने version पर टिके रहते हैं, तो गंभीर security vulnerability का खतरा रहता है (patch सिर्फ 15.2.3 में दिया गया है)
• metadata streaming वास्तव में page performance समस्याओं को छिपाती है और SEO पर भी नकारात्मक असर डालती है
• निष्कर्ष:
  Next.js दिखने में open source है, लेकिन व्यवहार में यह Vercel पर अत्यधिक निर्भर framework बन चुका है, इसलिए नए projects में दूसरे विकल्पों पर विचार करना अधिक समझदारी है

---

अवलोकन

• Next.js 15.1.8 से Vercel को छोड़कर बाकी environments में metadata handling से जुड़ी गंभीर समस्याएँ सामने आई हैं
• इससे मूल रूप से Vercel infrastructure पर Next.js की निर्भरता और गहरी होती दिखती है, साथ ही search engine optimization (SEO) में गिरावट और यहाँ तक कि security risk भी पैदा होता है

समस्या की शुरुआत: metadata streaming का परिचय

• 2024 में Vercel ने metadata streaming नाम का एक experimental feature पेश किया
• पुराने तरीके के विपरीत, metadata (tags: title, description, Open Graph आदि) को HTML `` में सीधे render नहीं किया जाता, बल्कि initial page load के बाद अलग से भेजा जाता है
• इस feature के लिए JavaScript execution जरूरी हो जाता है

Vercel की तकनीकी व्याख्या और वास्तविक समस्याएँ

• इसे लाने का कारण: metadata generation में आने वाले computing bottleneck को कम करना
• लेकिन वास्तव में metadata आमतौर पर static और बहुत कम मात्रा (1KB से कम) का data होता है
• server round-trip की cost inline processing से ज्यादा होती है
• dynamic metadata केवल बहुत कम exceptional cases में होती है
• metadata streaming implementation की complexity और confusion को बढ़ाती है

performance समस्या की पृष्ठभूमि

• कुछ developers ने external API integration जैसी स्थितियों में metadata generation delay की performance issue का अनुभव किया
• इस समस्या को हल करने के लिए Vercel ने streaming approach विकसित की

search engine crawlers और SEO पर प्रभाव

• जो search engines JavaScript execute नहीं करते, वे metadata पढ़ ही नहीं पाते
• इसका सीधा SEO पर बड़ा नकारात्मक असर पड़ता है
• समाधान के रूप में Vercel ने htmlLimitedBots feature दिया, जिसमें server crawler को पहचान ले तो streaming छोड़कर HEAD में metadata डाल देता है

अन्य cloud providers की सीमाएँ

• Netlify, Cloudflare, AWS आदि ने भी Next.js compatibility के लिए OpenNext नाम का adapter project बनाया
• लेकिन Next.js, Vercel पर इतना अधिक निर्भर है कि portability के लिए reverse engineering की जरूरत पड़ती है
• OpenNext की quality issues के कारण यह व्यवहार में ठीक से काम नहीं करता

static build भी अधूरा

• static site build में भी metadata अब HTML head में शामिल नहीं होता
• यह React Server Components के साथ bundle होता है, इसलिए JavaScript execution जरूरी हो जाता है
• basic HTML metadata के लिए भी crawler detection logic खुद implement करनी पड़ने जैसी अव्यावहारिक स्थिति बनती है

गंभीर security vulnerability और update की समस्या

• 21 मार्च 2025 को critical vulnerability (security score 9.1, GHSA-f82v-jwr5-mffw/CVE-2025-29927) सार्वजनिक हुई
• इस vulnerability में खास header manipulation के जरिए middleware authentication security को bypass किया जा सकता है
• इसका patch Next.js 15.2.3 में दिया गया, लेकिन metadata streaming से बचने के लिए अगर 15.1.8 पर ही रुकते हैं, तो security के लिहाज से बहुत बड़ा जोखिम रहता है

streaming लागू होने के नकारात्मक परिणाम

• metadata streaming छिपी हुई performance समस्याओं को और ज्यादा ढक देती है
• page metadata processing में delay होने पर actual users को इसका पता नहीं चलता
• लेकिन search engine crawlers slow response के कारण SEO score penalty दे सकते हैं

निष्कर्ष

• Next.js, open source framework के रूप में छिपा हुआ Vercel vendor lock-in बनता जा रहा है
• अगले project के tech stack का चुनाव करते समय, Next.js के बजाय दूसरे frameworks पर विचार करना ज्यादा समझदारी होगी

[kansm]

तो remix एक विकल्प बन जाता है?

[bth15923]

जैसा कि मुख्य लेख में बताया गया है, हद से ज़्यादा vendor lock-in, बेहद black box जैसे व्यवहार, और सहज न लगने वाले APIs। ऊपर से React की तरफ़ से भी इस तरह के server-side rendering आधारित development को ऐसे मार्केट किया जा रहा है मानो यही React का मानक development तरीका हो। मुझे लगता है कि ज़्यादातर apps के लिए Vite-आधारित SPA ही काफ़ी है।

[pcj9024]

vendor lock-in होना एक हद तक मान भी लें, लेकिन Next.js तकनीक खुद को लेकर जो राय दी जा रही है, उसे बस देखते हुए यही लगता है कि वह "मैं यह लेख पढ़ना ही नहीं चाहता" वाले स्तर से आगे नहीं बढ़ती।

[ndrgrd]

पहले से ही लगातार खुला होने का दिखावा करते हुए बंद रवैया दिखा रहे थे, और अब तो उन्होंने लगभग दरवाज़ा ही बंद कर लिया है।

[GN⁺]

Hacker News की राय

• मैं Next के इस्तेमाल की बिल्कुल सिफारिश नहीं करता। डेवलपर अनुभव भयानक है, vendor lock-in बहुत ज़्यादा है, और undocumented अजीब conventions की वजह से अगर यह CRUD-केंद्रित साधारण B2B SaaS नहीं है, तो हर जगह landmine बिछी होने जैसा लगता है। खासकर Next <Image /> टैग के कारण उसी पेज के webgl scene का FPS 2 तक गिर जाने का अनुभव हुआ

  • समझ नहीं आता कि Vercel ने आम React users को vendor lock-in में धीरे-धीरे कैसे फंसा लिया। React, Meta का ऐसा प्रोजेक्ट था जो open source पर ज़ोर देता था, और उम्मीद थी कि open source vendor lock-in को रोकने का काम करेगा, लेकिन हकीकत वैसी नहीं निकली—यह निराशाजनक है

  • पूरी तरह सहमत। हाल ही में मैंने लंबे समय बाद फिर से Next इस्तेमाल किया, और डेवलपमेंट अनुभव बहुत निराशाजनक था। docs अस्पष्ट थे और ढूंढना मुश्किल था, और app खुद ही डिफ़ॉल्ट रूप से धीमा लगता था। Docker के साथ AWS पर deploy करने की कोशिश करते हुए Vercel के दिए sample Dockerfile की वजह से अनगिनत मुश्किलें झेलनी पड़ीं

  • जानना चाहूंगा कि आपने <Image /> issue का खुद analysis किया था या बस अंदाज़ा लगाया कि यह NextJs की समस्या है। मैं NextJs, <Image>, RTF के combination के साथ काम करता हूँ, लेकिन मुझे ऐसी समस्या कभी नहीं हुई

• पिछले 3 साल से काम में Next.js इस्तेमाल कर रहा हूँ, और यह सच में पीड़ादायक लगा। Vercel पर host किया था, और कंपनी ने Vercel की लगभग सारी services अपना लीं, इसलिए असली vendor lock-in का अनुभव हुआ। पहले Dan ने RSC के बारे में HN पर जो लिखा था, उसमें मैंने अपना खराब अनुभव साझा किया था, और मुझे लगा उसकी बात बिल्कुल सही थी। जैसे उसने कहा था, "RSC खुद अब काफ़ी solid है, लेकिन Next.js जैसे framework अभी भी थोड़े rough हैं"। कुल मिलाकर React भी अब average से नीचे लगता है, और Next.js तो उसकी खराब प्रतिष्ठा को और तेज़ कर रहा है। इससे दूर रहना ही बेहतर है

• Vercel इस bug को ठीक कर देगा, लेकिन अब इस तरह की छोटी-छोटी समस्याएँ जुड़कर Next.js से थका चुकी हैं। उदाहरण के लिए middleware में prefetch पहचानने का तरीका कई हफ़्तों से, शायद महीनों से, टूटा हुआ है। ऐसी छोटी समस्याएँ लगातार जमा हो रही हैं, इसलिए Next.js fatigue बहुत है। फिर भी JS ecosystem से अब भी लगाव है

  • मैं Next.js छोड़कर Astro पर चला गया। मैं basics पर लौटना चाहता था, लेकिन routes/templates/static assets/build को खुद configure करना झंझट लगता था। Astro यह सब संभालता है, और डिफ़ॉल्ट रूप से SSR है। React/Vue को वैसे ही interaction layer की तरह ऊपर जोड़ने का एहसास होता है जैसा मूल रूप से इरादा था, और इससे समझ आता है कि JS frameworks वास्तव में कितने अनावश्यक हो सकते हैं। Next में जादुई चीज़ें बढ़ती जा रही हैं, server actions अटपटे लगते हैं, और बहुत कुछ "NextJS-style" implementation बन गया था

  • मैं अभी काम और side projects में Next.js इस्तेमाल कर रहा हूँ, लेकिन यह पहले एक मज़ेदार और productive tool था; pages से app router पर शिफ्ट होने के बाद इसकी दिशा निराशाजनक लगी

  • 15.1.8 version के बाद कुछ libraries 1 टूट गईं, इसलिए लेखक द्वारा बताए गए vulnerable version पर downgrade करना पड़ा

  • सहमत। आगे से मैं Next.js को सिर्फ static sites या prebuilt SPA के लिए ही इस्तेमाल करने की योजना रखता हूँ

• Next अब मज़ाक बनने की हालत में है। Remix के react-router में बदल जाने के बाद, समझ ही नहीं आता क्यों, अच्छे React frameworks बेहद कम बचे हैं। आखिरकार मैं plain vite और tanstack router के combination पर वापस आ गया

  • हैरानी होती है कि इस तरह की आलोचनात्मक पोस्ट Hacker News पर बनी हुई है। पहले मैंने एक पोस्ट डाली थी कि Remix में यह काम ज़्यादा आसान था, तो Vercel के कई कर्मचारियों ने मुझे message भेजकर उसे हटाने या meeting करने को कहा था। उन्होंने कई SNS accounts से एक साथ संपर्क किया

  • क्या आपका मतलब यह है कि brand change के बाद आप Remix अब इस्तेमाल नहीं करते, या यह कि वह framework नहीं रहा? RR7(React Router 7) भी framework की तरह ठीक से काम करता है 1। मैं 15 साल backend में था और हाल ही में full-stack में आया, एक अच्छे दोस्त की सलाह पर RR7 इस्तेमाल कर रहा हूँ, और हर दिन प्रभावित होता हूँ

  • मैंने नए project में TanStack Router इस्तेमाल किया, इतना पसंद आया कि TanStack Query और TanStack Form भी जोड़ लिए

  • जानना चाहता हूँ कि सबसे अच्छा alternative क्या है, और आप Vite क्यों इस्तेमाल करते हैं। मैं छोटे projects में Next इस्तेमाल करता हूँ, क्योंकि सुना है उसका सबसे बड़ा फ़ायदा SEO है। अगर static files बनाकर S3 पर upload कर दूँ तो क्या वही काफ़ी नहीं है?

  • जानना चाहता हूँ कि Remix का react-router में बदलना आख़िर समस्या क्या है। मुझे तो यह सिर्फ rebranding लगता है

• मैं वर्षों से ज़ोर देता आया हूँ कि Vercel जैसी कंपनियों के नेतृत्व में चलने वाले React, Next, Svelte आदि को कहीं अधिक सावधानी से अपनाना चाहिए। उनका लक्ष्य Heroku जैसा कुछ करना है, लेकिन उससे कहीं ज़्यादा आक्रामक तरीके से पूरे stack (language-runtime-machine) में complete lock-in पैदा करना। दूसरी कंपनियाँ भी समस्या पैदा करती हैं। उदाहरण के लिए Cloudflare का CLI deploy tool सिर्फ macOS 13.5+ को support करता है, जो मुश्किल से 2 साल पुराना है, और क्यों, यह स्पष्ट नहीं। दुख होता है कि 2 साल पहले आया OS अब पुराना माना जा रहा है। पुराना wrangler version आज़माया जा सकता है, लेकिन docs और features मेल नहीं खाते, और लगता है आगे और बिगड़ेगा। किसी दिन compatibility भी टूट सकती है। दूसरी तरफ़ vim, neovim, emacs जैसे tools अब भी पुराने OS X पर चलते हैं। मुझे लगता है कि ऐसे open tools में lock-in की प्रेरणा नहीं होती

• Next और RSC frontend में मेरे लिए सबसे ज़्यादा घुटन पैदा करने वाली चीज़ें रही हैं। frontend पहले ही काफ़ी सिरदर्द है, और उसके ऊपर Next का "magic", फिर Vercel का vendor lock-in। हमारी team इस हफ़्ते tanstack router और vite पर switch करके एक साधारण CSA बनाने वाली है, और मैं इसे लेकर उत्साहित हूँ

  • जानना चाहता हूँ कि RSC में ऐसा क्या घुटनभरा है। मेरे अनुभव में यह सचमुच अच्छी तरह काम करता है, और अभी भी मैं Next.js सिर्फ RSC की वजह से इस्तेमाल करता हूँ

• सबको Next.js dev mode में route compile होने में 10 सेकंड लगने वाली समस्या को ज़्यादा गंभीरता से लेना चाहिए। Rust compiler तो इसके सामने जैसे एक कोने में सिगरेट पी रहा हो

  • यह इस्तेमाल के लायक ही नहीं। मेरे अनुभव का सबसे खराब devx। आख़िरी बार किसी stack से इतनी नफ़रत तब हुई थी जब मुझे Sharepoint site में मदद करनी पड़ी थी

  • अब तो साधारण scripting language JS भी कई build/compile stages से गुजरती है, और अब C++ compiler से भी ज़्यादा समय लेती है। हालात ऐसे हैं कि शायद browser में Clang डाल दें तो बेहतर अनुभव मिले। वैसे हमारी कंपनी में PHP भी इस्तेमाल होती है, और वहाँ भी यही समस्या है। scripting language होने के कारण लगा था कि यह आसान होगी, लेकिन PHP की अपनी performance limits की वजह से code pre-generation और composer build stages अलग से रखने पड़ते हैं। और PHP developers द्वारा बनाया गया यह build भी धीमा है। शायद इसलिए कि इसे GCC बनाने वालों ने नहीं बनाया

  • अजीब बात है कि next dev —-turbo option भी हमारी company codebase में तेज़ नहीं है

  • Rust compiler सचमुच compilation करता है, लेकिन Next.js compiler वास्तव में उतना जटिल काम करता भी है या नहीं, इस पर संदेह है

• Next.js की मौजूदा हालत दुखद है। मैं अब भी इसे इस्तेमाल करता हूँ, लेकिन इस हद तक कि खुद fork करके patch लगाकर चलाना पड़ता है। next.config.js default behavior बदलने का एक कठिन escape hatch है, और मेरा मानना है कि ऐसे options को असली extension points के रूप में देना चाहिए था, न कि "feature flag" के पीछे छिपाना चाहिए था। अभी यह लगभग spaghetti code जैसा D-grade framework बन चुका है

• सवाल यह है कि अगर NextJS नहीं, तो पूरे stack के हिसाब से recommended combination क्या है। मैं 15 साल के अनुभव वाला backend developer हूँ, लेकिन frontend AngularJS के बाद पहली बार कर रहा हूँ। हाल में side project के लिए full-stack app बनाने की कोशिश में खोजा तो Gemini और official docs दोनों ने NextJS recommend किया। मैं अभी शुरुआती चरण में हूँ, इसलिए alternatives सीखना चाहता हूँ। सब कुछ Docker के साथ VPS पर self-host करने का इरादा है, इसलिए Vercel/Netlify से बच रहा हूँ

  • अगर server rendering की ज़रूरत नहीं है, तो framework-less React और Vite 1 का combination recommend करूँगा। development के दौरान Vite पर चलाओ, और production build में सिर्फ HTML + JS files निकलती हैं, जिन्हें S3 जैसी static hosting पर डालना काफ़ी है। 10 साल से ज़्यादा समय से ऐसा कर रहा हूँ और कोई समस्या नहीं हुई। backend में जो तुम्हें सुविधाजनक लगे वह इस्तेमाल करो; मैं आजकल ज़्यादातर PostgREST 2 इस्तेमाल करता हूँ। client में API calls के लिए react-query 3 recommend करूँगा

  • जानना चाहता हूँ कि आप किस तरह का project बना रहे हैं। मैं एक typical SaaS web app बना रहा हूँ, और React/Refine.dev/Vite का combination काफ़ी अच्छा लगा। Refine.dev की वजह से CRUD pages की चिंता किए बिना सिर्फ feature development पर ध्यान दे पाया

• मुझे लगता है कि इस issue को बढ़ा-चढ़ाकर पेश किया गया है। जिन्हें पता है कि React में streaming कैसे काम करती है, उनके लिए यह सामान्य बात है कि HTML को line-by-line stream नहीं किया जा सकता। metadata की वजह से first paint को block नहीं करना चाहिए, और वह भी HTML के लिए, JS के लिए नहीं। इस व्यवहार में कुछ user agents के लिए exception रखना तर्कसंगत है। ज़्यादातर traffic में जितनी जल्दी हो सके display होना ज़्यादा महत्वपूर्ण है। लेकिन अगर कुछ users में metadata load होने में बहुत समय लगता है, तो इसे कैसे हल किया जाए, यह जानना दिलचस्प होगा