- Next.js का middleware logging configuration के मामले में सीमित है, और default logging सिर्फ development environment में सक्रिय होती है, जिससे production environment में issues को trace करना मुश्किल हो जाता है
- middleware में सिर्फ headers ही pass किए जा सकते हैं, और multiple middleware chaining संभव नहीं है, इसलिए complex logging implementation सीमित हो जाती है
- AsyncLocalStorage का उपयोग करने वाली logging Edge runtime में अनपेक्षित behavior दिखाती है, और page तथा middleware के बीच context sharing ठीक से काम नहीं करती
- custom server का उपयोग करने पर भी logging problems हल करना कठिन है, और Next.js की design constraints developers को एक खास तरीके तक सीमित कर देती हैं
- Vercel का SvelteKit flexible middleware और data transfer mechanism प्रदान करता है, और Next.js की तुलना में अधिक developer-friendly design दिखाता है
Next.js की logging problem की पृष्ठभूमि
- Next.js service चलाते समय production log recording लागू करने की कोशिश में यह पता चला कि default log feature केवल development environment में ही सक्रिय है
- production environment के लिए उपयुक्त logging system implementation की आवश्यकता के दौरान Next.js की सीमाएँ सामने आती हैं
middleware की सीमाएँ
- official documentation के अनुसार middleware routing से पहले execute होता है और authentication, logging, redirection जैसी features के implementation के लिए उपयुक्त है
- व्यवहार में middleware को pass किए जा सकने वाले parameters 4 तक सीमित हैं, और वास्तव में केवल headers ही उपयोगी रूप से pass किए जा सकते हैं
- कई middleware को chain या combine करने वाली structure का समर्थन नहीं है
- Node.js में Express आदि के माध्यम से स्थापित middleware conventions मौजूद हैं, लेकिन Next.js में उन्हें ठीक से लागू नहीं किया जा सकता
AsyncLocalStorage से workaround की कोशिश
- pino और AsyncLocalStorage का उपयोग करके middleware level पर logging instances को manage करने की कोशिश की गई
- middleware में हर request के लिए unique context के साथ logs store किए जा सकते हैं, लेकिन यह सिर्फ browser environment में सही तरह काम करता दिखाई दिया
- इसका कारण यह है कि Next.js middleware मूल रूप से edge runtime का उपयोग करता है, और nodejs runtime पर सेट करने के बाद भी project की स्थिति के अनुसार यह अस्थिर रह सकता है
page components में रुकावट
- वास्तविक page या layout components में logging function call करने पर logger() null return करता है
- middleware में बनाया गया logger context asynchronous rendering context तक pass नहीं होता, यह एक structural problem है
- समाधान के रूप में केवल headers में requestId जैसे logging data डालकर pass करने का तरीका बचता है, जिससे code जटिल हो जाता है और import structure भी उलझ जाता है
- client components में भी इसी तरह के structural separation की अतिरिक्त आवश्यकता पड़ती है
custom server अपनाने की कोशिश
- official documentation के custom server example का अनुसरण करते हुए http.createServer और next.js के app.getRequestHandler के उपयोग पर प्रयोग किया गया
- इस environment में AsyncLocalStorage को फिर से उपयोग करने की कोशिश की गई, लेकिन middleware–page–custom server के बीच context linkage संभव नहीं होने की समस्या दोबारा सामने आई
- मूल रूप से Next.js के अंदर ही AsyncLocalStorage का सही उपयोग किया जा रहा है, लेकिन developers को वही स्तर की क्षमता नहीं दी जाती
- middleware से page तक pass किया जा सकने वाला तरीका व्यावहारिक रूप से केवल response headers में बदलाव तथा redirect/rewrite path movement तक सीमित है
- user के दृष्टिकोण से flexible extension या custom context transfer बहुत कठिन है
SvelteKit से तुलना
- Vercel का SvelteKit, Next.js की तुलना में अधिक flexible middleware system प्रदान करता है
- event.locals object के माध्यम से request data को स्वतंत्र रूप से pass किया जा सकता है
- multiple handle functions को define करके chain किया जा सकता है, जिससे complex logic implement करना आसान होता है
- SvelteKit एक developer-friendly design दिखाता है, जो Next.js की constraints के विपरीत है
- SvelteKit, Vercel का product होने के बावजूद, Next.js की तुलना में secondary project माना जाता है, फिर भी बेहतर अनुभव प्रदान करता है
issue tracker और ecosystem culture की आलोचना
- Next.js का official GitHub issue tracker user feedback पर लगभग प्रतिक्रिया नहीं देने जैसी स्थिति दिखाता है
- लोकप्रिय issues या bugs भी लंबे समय तक बिना जवाब या समाधान के पड़े रहने के मामले अक्सर दिखाई देते हैं
- minimal reproduction code तैयार करके issue उठाने पर भी कोई ठोस response या follow-up action नहीं मिलता
निष्कर्ष और आत्मचिंतन
- Next.js में दिखने वाले bugs और structural boundaries बार-बार developer productivity को नुकसान पहुँचाते हैं, और यह बुनियादी सुधार की माँग करता है
- अन्य frameworks (SvelteKit आदि) से तुलना करने पर, मुख्य product होने के बावजूद Next.js usability में पीछे दिखता है
- अभी तुरंत Next.js को replace करने की योजना कठिन है, लेकिन भविष्य की projects में दूसरे विकल्पों पर विचार करने की इच्छा पैदा होती है
7 टिप्पणियां
लगता है उन्होंने अभी तक यह नहीं सोचा कि React productivity को नुकसान पहुँचाता है।
इस बार मैंने सिर्फ अपनी व्यक्तिगत रुचि से, अपने मूल डेवलपमेंट क्षेत्र से बिल्कुल अलग वेब डेवलपमेंट को एक बार आज़माया। मैंने next.js v15 app router से एक बोर्ड बनाया था.. लेकिन हर बार ऐसे लेख देखता हूँ तो लगता है कि वेब की तरफ कुछ नया करने की इच्छा ही कम हो जाती है। यह ecosystem इतना अस्थिर क्यों है? फिर अगर कुछ नया आ गया तो क्या सब लोग उधर दौड़ पड़ेंगे, थोड़ा इस्तेमाल करेंगे, फिर उसे कोसते हुए कुछ और ढूँढ़ने लगेंगे? वेब डेवलपमेंट सच में काफ़ी मुश्किल लगता है।
इंडस्ट्री की प्रकृति ऐसी है कि बदलाव तेज़ी से होना एक फ़ायदा भी है और एक नुकसान भी, हाहाहा। लेकिन मुख्य लेख में जो समस्या है, उसकी जड़ में असल में Vercel की गड़बड़ी है। अगर आप फ्रंटएंड कर रहे हैं, तो Vercel पर थोड़ा सावधानी से नज़र रखने की ज़रूरत है, उफ़ उफ़
शायद इसलिए कि मैंने अपना करियर web से शुरू किया था, web में (खासकर front-end में) मूलतः ऐसे ही मज़े(?) के साथ development किया जाता है, हाहा
तेज़ी से बदलते रहने वाला स्वाद...
JS की तरफ़ थोड़ा ऐसा ही लगता है। ऐसी बहुत-सी चीज़ें हैं जिन्हें अच्छा कहा जाता है, लेकिन उनमें से हर एक में थोड़ी-थोड़ी समस्या है, और ट्रेंड के हिसाब से वे बहुत जल्दी बदलती भी रहती हैं...
हो सकता है मुझे ऐसा इसलिए लगता हो, क्योंकि मैंने Java, EJB, Struts को मुख्य रूप से इस्तेमाल किया था।
Hacker News की राय
मैं 100% सहमत हूँ, मुझे भी बिल्कुल यही समस्या हुई थी, और मैं आगे कभी भी Next.js का इस्तेमाल नहीं करूँगा, बल्कि अपनी कंपनी की सभी टीमों को भी दूसरे विकल्प अपनाने की सलाह दूँगा।
Next.js में 99.9999% प्रोजेक्ट्स के लिए बिल्कुल गैर-ज़रूरी, बहुत भारी abstraction layer है। जिन बहुत कम मामलों में सच में इसकी ज़रूरत पड़ती भी हो, वहाँ भी मुझे लगता है कि निचले स्तर के components से custom solution बनाना बेहतर है।
मैंने जिन technologies का इस्तेमाल किया है, उनमें Next.js अब तक की सबसे खराब रही है।
यह जानकर सच में राहत मिली कि सिर्फ मैं ही ऐसा नहीं सोचता।
मैंने Next.js से मध्यम जटिलता वाला revenue-generating production app बनाया था। शुरुआत में Vercel और Google Firebase का इस्तेमाल किया, फिर बाद में self-hosting पर गया और Pocketbase पर migrate किया।
Pocketbase ही अकेला हिस्सा था जिसका अनुभव ठीक रहा, बाकी सब कुछ सच में भयानक था।
अनंत complexity, लगातार breaking changes, और मुश्किल से समझ आने वाले docs — कुछ भी आसान नहीं था।
मुझे पूरा यक़ीन है कि अगर पिछले 5 सालों की FE trends को पीछे घुमा कर, उस समय मौजूद technologies को ठीक से सिखाने पर ध्यान दिया जाता, तो आज हालात इससे बेहतर होते।
मैंने कुछ complex React frontend भी बनाए हैं। React भी मुझे बहुत पसंद नहीं, लेकिन Next.js उससे भी ज़्यादा खराब लगा।
मैंने Go और vanilla JS से CMS भी बनाया है। DX शायद थोड़ा कम हो, लेकिन कम से कम यह एहसास तो रहता है कि असल में क्या हो रहा है, यह मुझे पता है।
समझ नहीं आता कि React और Next.js में 6 साल बाद भी हर बार अंदाज़ा ही लगाना पड़ता है कि क्या होने वाला है।
मैंने framework की उलझनों को संभालने का experience तो बना लिया, लेकिन कुल मिलाकर यह बहुत गंदा और खराब design लगता है।
Go में पहले 6 महीनों के बाद शायद ही कभी कोई चौंकाने वाली बात हुई, और पुराना codebase भी अब तक मज़बूत है।
दुख इस बात का है कि frontend में वैसा अनुभव बन ही नहीं पा रहा।
मेरे अनुभव में Next.js के rough edges bugs नहीं, features हैं।
ऐसा लगता है जैसे सब कुछ जानबूझकर इस तरह बनाया गया हो कि users हार मान लें और Vercel hosting से बँध जाएँ।
मुझे लगता है कि आगे हालात और बिगड़ेंगे।
अभी PluralSight जैसे online courses भी React courses में सिर्फ Next.js को ही push कर रहे हैं।
यह स्थिति क्यों बनी, पता नहीं, लेकिन हम यहाँ तक पहुँच चुके हैं।
मेरे मामले में Sharepoint की यादें उससे भी गंदी हैं, इसलिए Next.js मेरे लिए दूसरी सबसे खराब चीज़ है।
Next.js में सबसे ज़्यादा निराशाजनक बात यह है कि यह Rails, Wordpress, Meteor जैसे full-stack frameworks की तरह सब कुछ देने का दावा करता है, लेकिन असल में यह सिर्फ सबसे नीरस और सीमित हिस्सों पर ही opinionated है — जैसे middleware, image resizing, SSR वगैरह — जबकि जो फैसले सच में मूल्यवान हैं, जैसे database, ORM, communication protocol, वे सब user पर छोड़ देता है।
असल में यह Rails/Wordpress/Meteor से काफ़ी अलग है। Framework को infrastructure define करना चाहिए, लेकिन यहाँ तो infrastructure ही framework को नियंत्रित कर रहा है।
मेरे dashboard में "Fluid Active CPU" और "ISR Writes" सबसे ऊपर usage items हैं, और मैं बस $20 देकर यही दुआ करता रहता हूँ कि 100% cross न हो जाए।
इन items के नाम Star Trek जैसी jargon से भरे हुए हैं, और लगता है अगली major version में फिर बदल जाएँगे, इसलिए इन्हें सीखने का भी मन नहीं करता।
Zeit के समय जिन लोगों को मैं जानता था और जो इस पर फिदा थे, उनमें से काफ़ी लोग आख़िरकार अपने projects और clients कहीं और ले गए।
अगर Vercel मुझसे पूछे कि अगली major release में क्या बदलना चाहिए, तो मैं बस यही कहूँगा: "App Router सहित उसके बाद लिए गए लगभग सारे फैसले गलत थे।"
मुझे नहीं पता यह अब कैसे ठीक हो सकता है।
मुझे लगता है Next.js की बहुत-सी समस्याएँ इस बात से आती हैं कि code असल में कहाँ run हो रहा है, यह साफ़ नहीं होता।
Browser, middleware, edge और node, SSR — सब कुछ मिलकर बहुत भारी complexity पैदा करते हैं।
यह setup सिर्फ इन स्थितियों में समझ आता है:
जब आप global users के लिए B2C service चला रहे हों और edge semantics से latency कम करना चाहते हों
जब आप Vercel की महँगी hosting के लिए तैयार हों
जब architecture बहुत complex न हो और background jobs की ज़रूरत न पड़े
इसके अलावा react-vite SPA या Rails जैसे traditional SSR कहीं ज़्यादा सीधा रास्ता हैं।
मैं ऊपर की शर्तों से भी सहमत नहीं हूँ।
मान लो Next.js किसी case में fit भी बैठता हो, तब भी productivity और maintainability में जो गिरावट आती है, वह उसके लायक बिल्कुल नहीं लगती।
मैं Gleam का Lustre इस्तेमाल कर रहा हूँ और पीछे मुड़कर देखने का कोई इरादा नहीं है।
Elm founder का keynote भी मुझे Next.js के उलट एक उदाहरण लगता है।
https://www.youtube.com/watch?v=sl1UQXgtepE
मैं Vercel को modern web का cancer कहूँगा।
यह हर framework ecosystem में घुसपैठ करता है, paid plans बेचने के लिए उसका दुरुपयोग करता है, और open source, competition और web की प्रगति की परवाह करने का सिर्फ दिखावा करता है।
पहली शर्त वाले case में भी यह मानना मुश्किल है कि Vercel और SSR इस्तेमाल करने भर से performance bottleneck खत्म हो जाएगा।
ज़्यादातर performance issues की जड़ कहीं ज़्यादा बुनियादी होती है — जैसे बहुत बड़ा bundle size, ढेर सारी धीमी API calls वगैरह।
बेसिक profiling, optimization और simplification पहले करना, architecture को जटिल बनाने से कहीं ज़्यादा असरदार होता है।
"code कहाँ execute हो रहा है, यह साफ़ न होना" — इस हिस्से से मैं पूरी तरह सहमत हूँ।
पहले मुझे JavaScript-everywhere वाला विचार advantage लगता था, लेकिन अब वही समस्या जैसा लगता है।
हमारी कंपनी Inertia.js + Vue इस्तेमाल करती है। कुल मिलाकर setup काफ़ी simple है, frontend rendering की ताकत भी बनी रहती है, routing 100% server side पर handle होती है, और अलग API की भी ज़रूरत नहीं पड़ती।
React और Svelte में भी Inertia इस्तेमाल किया जा सकता है।
शुरुआत में हमने Nuxt इस्तेमाल किया था, लेकिन backend server और frontend server दोनों साथ चलाने जितनी complexity थी, और code कहाँ run हो रहा है, यह समझना भी मुश्किल था।
अब PHP server पर है, JS browser में है — यह साफ़ विभाजन होने से हमें कुछ सोचने की ज़रूरत ही नहीं पड़ती।
हमारे लिए यह बहुत बड़ा फ़ायदा है।
बात का सार काफ़ी अच्छी तरह रखा गया है।
Vercel React Server Components, Partial Pre-rendering, Edge servers, streaming आदि के ज़रिए performance optimization करना चाहता है।
इसके कई अजीब design और API decisions इसी से निकले हैं।
ज़रूरत हो तो यह मददगार हो सकता है, लेकिन edge function के कुछ हिस्सों में SSR का सही इस्तेमाल भर भी काफ़ी सुधार ला सकता है।
feedback छोड़ने के लिए धन्यवाद।
हमें Middleware में DX issues का पता है, और version 15.5 में Node runtime support को एक बड़े सुधार के रूप में दिया गया है[1]।
अगर पीछे जा सकता, तो शायद इसका नाम Routing Middleware या Routing Handler जैसा रखता, ताकि यह साफ़ हो कि यह routing phase में CDN edge को handoff करने वाले advanced escape hatch जैसा है।
अगर logs चाहिए हों, तो OpenTelemetry का इस्तेमाल करके
instrumentation.tsconvention[2] के अनुसार handle किया जा सकता है।[1] https://nextjs.org/blog/next-15-5#nodejs-middleware-stable
[2] https://nextjs.org/docs/app/api-reference/file-conventions/instrumentation
जवाब के लिए धन्यवाद।
लेकिन instrumentation और observability की बात आते ही ऐसा लगता है कि एक साधारण logging समस्या को फिर किसी और complex layer से solve किया जा रहा है।
हर app को OpenTelemetry की ज़रूरत नहीं होती।
समझ नहीं आता
logger().info()जैसा सामान्य तरीका क्यों नहीं चल सकता।दूसरी languages और frameworks में यह सब होता है, तो यहाँ इतना मुश्किल क्यों है, यह समझना कठिन है।
यहाँ माहौल काफ़ी negative है, इसलिए पहले यह साफ़ कर दूँ: Next.js अपने असली purpose के लिए अच्छी तरह बना हुआ शानदार software है।
मुझे लगता है इसने लाखों sites को support करने लायक अच्छा software दिया है।
समस्या detailed reference और documentation की कमी में है। Docs यह तो बताते हैं कि क्या मौजूद है, लेकिन असल में उसे कैसे इस्तेमाल करना है, कब execute होता है, common pitfalls क्या हैं — यह सब कम बताते हैं।
Beginners के लिए यह friendly है, लेकिन complex runtime context और derived complexity पर guidance कम है।
आजकल कई projects में यह एक trend बन गया है।
User friendly होने और विस्तार से समझाने के बीच संतुलन बनाना बहुत कठिन है।
उम्मीद है यह आगे भी evolve करता रहेगा।
एक और सीधी बात।
इस पोस्ट का author असल में domain differences को समझे बिना हर जगह functions को एक ही तरह call करना चाहता था।
Next.js की गलती वहीं से शुरू होती है, जहाँ यह अलग प्रकृति वाले domains को ज़बरदस्ती एक में मिलाने की कोशिश करता है।
जब आप edge, SSR, Node और client को इस तरह आपस में गड्डमड्ड करेंगे, तो complexity ही बढ़ेगी।
यह docs से solve नहीं होता, उल्टा confusion और बढ़ता है।
मुझे Reddit comments में instrumentation approach सुझाई गई थी।
करीब उसी समय अगर मैं opentelemetry को Next में setup कर रहा होता, तो docs अलग भी होते, तब भी इस experience के बाद मैं blog post ज़रूर लिखता।
यह तुम्हारी गलती नहीं है, लेकिन लगभग सारे opentelemetry packages पर experimental का label लगा होता है, इसलिए production में उन पर भरोसा करना मुश्किल है।
pino instrumentation setup करना भी बहुत कठिन था।
ठीक से काम कराने के लिए pino को
serverExternalPackagesमें जोड़ना पड़ा।Auto-instrumentation import order के प्रति बेहद sensitive था, और pino के सिर्फ default export पर instrumentation होता था।
Module-local variables भी उम्मीद के मुताबिक काम नहीं कर रहे थे, इसलिए
globalThisइस्तेमाल करना पड़ा।और इसके बाद भी आख़िर में मैं https://github.com/vercel/next.js/issues/80445 से टकरा गया।
आख़िरकार यह काम तो करने लगा, लेकिन setup सच में बहुत दर्दनाक था।
यह experience manual router की वजह से था (=
vercel/otelइस्तेमाल नहीं किया)।अगर server-side middleware support देने का फैसला किया गया है, तो फिर अब तक middleware chain — यानी कई functions को जोड़ना — क्यों supported नहीं है, यह समझ नहीं आता।
यह तो लगभग हर दूसरे server framework में होता है।
मुझे शक हुआ कि "कई middleware chain नहीं हो सकती" वाली बात सच है भी या नहीं।
https://nextjs.org/docs/messages/nested-middleware
अगर कई हों, तो उन्हें एक file में merge करके चलाना चाहिए — यह बात सच में यक़ीन करने लायक नहीं लगती।
अगर मैं सही पढ़ रहा हूँ, तो Next.js सच में कह रहा है कि कई files में structure मत बनाओ, सब कुछ एक ही file में जोड़ दो?
क्या scoping issues की वजह से कई files इस्तेमाल करना मुश्किल है? Framework के लिए यह सच में बेहूदा माँग है।
यह शक दूर नहीं होता कि ऐसे ज़्यादातर बेहूदा decisions framework के हित में नहीं, बल्कि Vercel के हित में ज़्यादा लिए गए हैं।
Next.js को पहली बार देखते ही मुझे Meteor.js याद आ गया था।
मैंने personal projects में इसे सीखने के लिए काफ़ी समय लगाया, लेकिन इसकी over-the-top abstractions और rigidity की वजह से prototype से आगे बढ़ना मुश्किल था।
ऐसी “batteries included” solutions बार-बार आती रहती हैं, क्योंकि setup करना आसान होता है।
हाल में Hacker News पर Laravel vs Symphony तुलना में भी यही बात चली थी कि complexity बढ़ते ही यह मॉडल टूटने लगता है।
अगर इस approach की तुलना पुराने NodeJS/React SPA जैसे composable setup से करें, तो वहाँ हर part lower-level abstraction के साथ स्वतंत्र होता है, इसलिए flexibility ज़्यादा होती है और parts को बदलना भी आसान होता है।
उसके अपने नुकसान हैं, लेकिन overengineering — यानी परत-दर-परत जमा complexity — की तुलना में यह कहीं ज़्यादा smooth लगता है।
मुझे पूरी तरह समझ आता है कि batteries included approach लोकप्रिय क्यों है।
अलग-अलग tools और libraries को जोड़कर compatibility बैठाना सच में बहुत झंझट का काम है।
ऐसा composable approach तभी अच्छे से चलता है जब कोई ज़्यादा skilled व्यक्ति शुरुआत में setup करे।
मैं asp.net का आदी हूँ। Startup dev community में इसकी reputation बहुत अच्छी नहीं है, लेकिन असल में यह शानदार तरीके से designed framework है।
यह batteries included है, लेकिन मैं जब चाहूँ framework से बाहर निकलकर override कर सकता था, और मुझे कभी ऐसा नहीं लगा कि मैं framework से लड़ रहा हूँ।
Blazor Server और Blazor Webasm दोनों में frontend C# में लिखा जा सकता है, और दोनों अपने-अपने तरीके से internal panels या SaaS apps के लिए अच्छे हैं।
सबसे अच्छी बात यह है कि traditional server-side rendering से भी बहुत कुछ solve हो जाता है।
अगर किसी को web framework से निराशा है, तो मैं इसे ज़रूर आज़माने की सलाह दूँगा।
अब इसका cross-platform support भी अच्छा है, यह तेज़ है, और सीखना भी आसान है।
Learning curve है, लेकिन module structure समझते ही मैं आसानी से overrides कर पाया।
दूसरे frameworks की तुलना में इसकी limits से टकराना बहुत कम हुआ।
NodeJS/React SPA जैसे composable parts Angular में उतने परिचित नहीं हैं।
Angular library नहीं, framework है, इसलिए ज़्यादातर ज़रूरी चीज़ें उसमें पहले से शामिल हैं।
(RxJS की learning curve थोड़ी है, लेकिन basics सीख लेने पर यह काफ़ी शक्तिशाली है।)
आम तौर पर SPA में framework से जूझने जैसा अनुभव मुझे कम ही हुआ है।
इसके docs और tutorials (
Tour of Heroesसहित) बहुत अच्छे हैं।https://v17.angular.io/tutorial/tour-of-heroes
नए docs https://angular.dev/ पर मिल सकते हैं।
Laravel overengineered abstractions की सफल मिसाल है।
Laravel की वजह से मुझे production में कभी पछताना नहीं पड़ा।
थोड़ी अलग बात है, लेकिन लगातार छोटे-छोटे incompatibility वाले tools और libraries को जोड़ते रहना ही मेरा पूरा काम है।
हमारी team छोटी है, इसलिए हम लगातार upgrades और maintenance में बहुत समय खर्च करते हैं, और पुराने unsupported packages की समस्या भी बार-बार आती रहती है।
सिर्फ experience ही नहीं, system बनाने में लगने वाला शुरुआती समय और maintenance cost भी उम्मीद से कहीं ज़्यादा बड़ी होती है।
खुद करके देखने पर मुझे लगा कि Node में टुकड़ों-टुकड़ों में libraries जोड़ने की तुलना में Rails लगभग 10 गुना ज़्यादा productive है।
समस्या तब आती है जब आपको framework की बुनियादी philosophy से ही दिक्कत हो — जैसे ActiveRecord पसंद न हो।
"complexity बढ़ते ही सब टूट जाता है" — यह बात skill की कमी दिखाती है।
मैं React का बहुत बड़ा समर्थक हूँ, और class components से hooks पर जाने वाला बदलाव भी मुझे पसंद आया था।
लेकिन जब भी Next.js इस्तेमाल करता हूँ, समझ ही नहीं आता कि आखिर गड़बड़ शुरू कहाँ से हुई।
मुझे बहुत सारे frameworks और अजीब भाषाएँ भी पसंद हैं, लेकिन Next.js ही एकमात्र ऐसी चीज़ है जहाँ मुझे आधे error messages तक समझ नहीं आते।
खासकर अजीब hydration issues पर मैंने बेहिसाब समय बर्बाद किया है।
मैं React या Next.js इस्तेमाल नहीं करता।
व्यक्तिगत रूप से मुझे HTML+CSS के साथ थोड़ा vanilla JS पसंद है।
मैंने एक simple Next.js landing page को Firefox में टूटते हुए भी देखा है।
और इससे भी बुरा यह था कि failure mode में सारे content के ऊपर सिर्फ काली screen और सफ़ेद text में "An application client side error has occurred" दिख रहा था।
यह देखकर हैरानी हुई कि एक simple landing page भी render नहीं हो सका, और जब पता चला कि वजह JS frontend framework है, तो बस लगा — हाँ, ठीक है, ऐसा हो सकता है।
जो लोग users को मनाने की कोशिश कर रहे हैं, उनके लिए यह शायद स्वीकार्य हो, लेकिन industry के बाहर के लोगों को यह काफ़ी अटपटा लग सकता है।
मुझे लगता है Next ने खुद को पहले ही बिगाड़ लिया है।
VC cycle से गुज़रने वाली चीज़ों का यही हश्र होता है।
अब यह इस्तेमाल करने लायक नहीं रहा, और Vite मेरा default option है।
मैं हमेशा हल्के solutions को तरजीह देता हूँ।
Next.js में “middleware” शब्द आसानी से भ्रम पैदा करता है।
असल में यह request app तक पहुँचने से पहले चलने वाली एक lightweight edge function है — जैसे headers check करना, routing, simple guards वगैरह।
यह edge runtime में चलती है, जो app server से अलग environment है।
लेखक भी शायद edge और server runtime को आपस में मिला रहा है।
मुझे भी शुरुआत में यह boundary confusing लगी थी, और JavaScript-केंद्रित दुनिया में यह distinction और धुंधला हो जाता है।
मुझे लगता है कि इसके लिए एक साफ़ mental model चाहिए।
Next.js की complexity को दोष देना थोड़ा ऐसा है जैसे किसी toolbox को इस बात के लिए दोष देना कि उसमें hammer के अलावा और भी tools हैं।
समस्या यह है कि Next.js की complexity largely self-inflicted है।
“middleware” शब्द का लगभग हर framework में पहले से एक स्थापित अर्थ है।
आमतौर पर middleware runtime में request से पहले बुलाए जाने वाले functions की chain होता है, और यह माना जाता है कि वे एक ही process में execute होंगे।
Next.js ने इसे edge पर रखकर एक ही middleware तक सीमित कर दिया।
ज़्यादातर apps में edge capabilities की ज़रूरत ही नहीं होती; इसे तभी opt-in होना चाहिए जब सच में आवश्यकता हो।
Toolbox वाली analogy में भी वही सही है — जो tools चाहिएँ, वही जोड़ो।
Next.js को इस context में “middleware” शब्द इस्तेमाल नहीं करना चाहिए था।
यह सिर्फ misuse नहीं, terminology abuse भी है।
Web app industry में middleware की परिभाषा बहुत पुरानी और स्पष्ट है, इसलिए अगर मतलब कुछ और था, तो यह शब्द इस्तेमाल ही नहीं करना चाहिए था।
मैं Next.js app router इस्तेमाल करता हूँ और काफ़ी संतुष्ट हूँ।
Next.js में frontend और backend के बीच आना-जाना बहुत आसान है, इसलिए लोग समझ लेते हैं कि यह हिस्सा भी पूरी तरह abstract हो गया है।
असल में यह बहुत जटिल system है, और उस complexity को आपको खुद समझकर संभालना पड़ता है।
Complexity ज़्यादा होना हमेशा slow या unproductive होने का मतलब नहीं है।
Frontend और backend अलग-अलग हों, तो system ज़्यादा manageable होता है, लेकिन उतना ही ज़्यादा झंझट भी होता है।
React जानने के बाद भी Next.js ऐसा लगता है जैसे पूरी तरह नई चीज़ सीख रहे हों, और बहुत सी बातें बिना खुद झेले समझ नहीं आतीं।
फिर भी, जब कुछ familiarity बन जाती है, तो frontend और backend के बीच सहजता से जाने वाला यह बहुत सुविधाजनक system है।
मेरे comment को बहुत downvote मिले, तो अच्छा होता अगर लोग वजह भी बताते।
मैं हमेशा सीखना चाहता हूँ।
ऐसी discussions में अंधी नकारात्मकता के बजाय सही बहस होनी चाहिए।
आखिरकार मुझे एक समझदारी वाली राय दिखी।
उदाहरण के लिए, अगर आप Python के package/module और Go के module concept को बिना सोचे-समझे मिला दें, तो फिर Go को बुरा कहकर शिकायत करना वैसा ही होगा।
जो technology इस्तेमाल कर रहे हैं, उसकी बुनियादी समझ होना ज़रूरी है।
Next.js के app router में बदलने के बाद से ऐसा लगा जैसे express API को बेहतर बनाने का काम bootcamp graduates के हाथ में दे दिया गया हो।
हालाँकि सभी server interfaces — servlet, rack, plug आदि — वर्षों से एक रूसी-गुड़िया जैसी layered design के साथ विकसित हुए हैं, और उस तुलना में express API फिर भी एक mature approach लगती है।
सिर्फ खराब middleware API ही नहीं, बल्कि request params हटाकर उनकी जगह
cookies()/headers()जैसी global functions लाना भी अजीब decision था।लगता है कुछ गहरे design constraints छिपे हुए हैं, लेकिन बाहर से देखने पर ऐसा दिखता है कि जैसे पिछली सारी सीखें फेंक दी गईं और वही गलतियाँ फिर दोहराई जा रही हैं।
इसके ऊपर lowest common denominator वाले edge runtime support को भी जोड़ दें, तो constraints और सख्त हो जाना स्वाभाविक है।
मैं हमेशा नए projects में अलग-अलग stacks आज़माता हूँ।
express+react, angular, vue, next, nuxt, go, .net, node, php — frontend और backend दोनों तरफ़ बहुत कुछ इस्तेमाल किया है।
ज़्यादातर frameworks में मुझे कुछ अच्छाइयाँ, कुछ कमियाँ और कुछ नया सीखने का मज़ा मिला।
Next.js अकेला अपवाद है: एक काफ़ी बड़ा app बनाते हुए शुरू से अंत तक हर चीज़ अजीब, धीमी, असुविधाजनक या बेतुके ढंग से designed लगी।
मैं अभी भी उसे maintain कर रहा हूँ, और वही एकमात्र “चीज़” है जिससे मुझे सच में नफ़रत है।
लोग कहते हैं ecosystem ठीक है, popularity भी बहुत है, लेकिन मेरा real experience इतना नकारात्मक रहा कि वापसी का सवाल ही नहीं उठता।
अजीब है, लेकिन यही सच है।
क्या किसी को Vercel का mailing address पता है?
यह issue अगले साल school जाने की उम्र का हो जाएगा, तो सोचा कंपनी को “स्कूल जीवन के लिए शुभकामनाएँ!” वाला card भेज दूँ।
https://github.com/vercel/next.js/issues/10084
नीचे लगे Hacker News कमेंट में कही गई बात बिल्कुल सही है.
"Next.js में 99.9999% प्रोजेक्ट्स के लिए अनावश्यक रूप से बहुत बड़ा abstraction layer है, और जिन कुछ मामलों में सच में इसकी ज़रूरत पड़ती भी है, वहाँ भी लो-लेवल components के साथ custom solution बनाना ज़्यादा बेहतर लगता है"
बेकार में ज़रूरत से ज़्यादा complex API, अस्थिर और अधूरा होने के बावजूद लगातार production ready बताकर प्रचार करना, और Vercel पर इतनी भारी निर्भरता कि Vercel के बिना इसे ढंग से ऑपरेट करना भी मुश्किल है.