आपको NextJS की ज़रूरत नहीं है
React ऐप्स बनाने के लिए Next.js एक डिफ़ॉल्ट जवाब है। यह एक बेहतरीन फ्रेमवर्क है। लेकिन डिफ़ॉल्ट होने का मतलब यह नहीं है कि यह ज़रूरी भी है।
गलत प्रोजेक्ट के लिए इसका उपयोग करने से हमारी गति कम हो गई और टीम में आपसी मतभेद पैदा हुए। हमने डैशबोर्ड और चार्ट के साथ एक डेटा-भारी (data-heavy) प्रोडक्ट बनाया। लगभग हर स्क्रीन लॉगिन के पीछे थी।
इस तरह के ऐप के लिए, server-side rendering (SSR) ने बिना किसी मूल्य वृद्धि के लागत बढ़ा दी।
सही टूल इस बात पर निर्भर करता है कि आप क्या बना रहे हैं।
कंटेंट-फर्स्ट (Content-first) प्रोजेक्ट्स: • मार्केटिंग साइट्स • ब्लॉग्स • स्टोरफ्रंट्स • डॉक्स • यहाँ Next.js का उपयोग करें। SEO महत्वपूर्ण है और कंटेंट स्टैटिक (static) होता है।
एप्लीकेशन-फर्स्ट (Application-first) प्रोजेक्ट्स: • इंटरनल टूल्स • डैशबोर्ड्स • एडमिन पैनल्स • SaaS कंसोल • यहाँ Vite-आधारित SPA का उपयोग करें। ये ऐप्स ऑथ (auth) के पीछे होते हैं और APIs पर निर्भर करते हैं।
हम Next.js से Vite SPA पर चले गए। इसके कारण यहाँ दिए गए हैं:
आसान डिबगिंग (Easier Debugging) सर्वर एरर्स आपके कंपोनेंट्स के साथ स्पष्ट रूप से मैप नहीं होते हैं। क्लाइंट-साइड एरर्स ब्राउज़र में स्पष्ट स्टैक ट्रेसेस (stack traces) के साथ होते हैं। इससे बग्स को ठीक करना तेज़ हो जाता है।
बेहतर टेस्टिंग (Better Testing) आप ऐसे सर्वर कंपोनेंट का आसानी से यूनिट टेस्ट नहीं कर सकते जो अन्य सर्वर कंपोनेंट्स को रेंडर करता है। हमने केवल टेस्ट करने योग्य बने रहने के लिए डिज़ाइन संबंधी कुछ विकल्प चुने थे। वह एक गलती थी।
सरल ऑथ (Simpler Auth) SSR के लिए हर रिक्वेस्ट पर सर्वर द्वारा टोकन को वैलिडेट करना आवश्यक होता है। इससे अटैक सरफेस (attack surfaces) बढ़ जाते हैं और कुकी लॉजिक जटिल हो जाता है। एक क्लाइंट-फर्स्ट ऐप ऑथ को एक ही जगह संभालता है: API।
कम इंफ्रास्ट्रक्चर लागत (Lower Infrastructure Costs) SSR को हर रिक्वेस्ट के लिए हमेशा चालू रहने वाले सर्वर की आवश्यकता होती है। एक स्टैटिक फ्रंटएंड CDN से फाइलों के रूप में भेजा जाता है। आपको चलाने और सुरक्षित करने के लिए एक सर्विस कम हो जाती है।
कम जटिलता (Less Complexity) Next.js सर्वर और क्लाइंट के बीच विभाजन करने के लिए मजबूर करता है। फ्रंटएंड इंजीनियरों को मिडलवेयर (middleware) और कैशिंग (caching) जैसे सर्वर संबंधी मामलों को संभालना पड़ता था। इससे हमारी गति धीमी हो गई।
हमने चरणों (phases) में माइग्रेशन किया। हमने सार्वजनिक SEO-महत्वपूर्ण पेजों के लिए Next.js को बनाए रखा। बाकी सब कुछ हम Vite SPA पर ले गए।
इसके नुकसान (trade-offs) बहुत कम थे: • SEO: लॉगिन के पीछे वाले डैशबोर्ड्स को SEO की आवश्यकता नहीं होती है। • शुरुआती लोड (Initial load): डेटा-भारी ऐप्स आमतौर पर डेटाबेस के कारण धीमे होते हैं, फ्रेमवर्क के कारण नहीं।
यदि SEO और सोशल प्रिव्यू (social previews) महत्वपूर्ण हैं, तो Next.js का उपयोग करें। यदि आपका ऐप इंटरैक्टिव, डेटा-संचालित है और लॉगिन के पीछे है, तो Vite SPA का उपयोग करें।
डिफ़ॉल्ट का उपयोग करना बंद करें। खुद से पूछें कि आप वास्तव में क्या बना रहे हैं।
स्रोत: https://dev.to/moruno21/you-dont-need-nextjs-heres-why-708