यदि आपने पिछले कुछ साल मेटा-फ्रेमवर्क्स के बीच स्विच करते हुए बिताए हैं, तो SvelteKit 2 आपको राहत और संदेह का एक अजीब मिश्रण महसूस कराएगा। राहत इसलिए, क्योंकि यह जटिलता बढ़ाने के बजाय उसे वास्तव में कम करता है। संदेह इसलिए, क्योंकि आप किसी समस्या के सामने आने का इंतज़ार करते रहते हैं। लेकिन ऐसा कभी नहीं होता। Svelte 5 के साथ मिलकर, यह स्टैक 2026 में एक फुल-स्टैक एप्लिकेशन लॉन्च करने के सबसे प्रोडक्टिव तरीकों में से एक है, और आंकड़े डेवलपर अनुभव (developer experience) की पुष्टि करते हैं। बंडल्स Svelte 4 द्वारा बनाए गए बंडल्स की तुलना में लगभग 35% छोटे होते हैं। रूटिंग, सर्वर फंक्शन और ऑथेंटिकेशन पैटर्न सभी मुख्य फीचर्स (first-class citizens) हैं, न कि जुगाड़ से जोड़े गए प्लगइन्स।

runes इसे रिएक्टिविटी के लिए स्पष्ट बनाते हैं

सबसे बड़ा मानसिक बदलाव Svelte 5 के runes से आता है। Svelte के पिछले वर्ज़न डिपेंडेंसी को ट्रैक करने के लिए $: लेबल और बहुत सारे कंपाइलर मैजिक का उपयोग करते थे। यह काम तो करता था, लेकिन जब कुछ टूटता था, तो आप अदृश्य तारों को डीबग कर रहे होते थे। Runes उस मैजिक को स्पष्ट फंक्शन्स (explicit functions) से बदल देते हैं। आप कंपाइलर को ठीक-ठीक बताते हैं कि क्या ट्रैक करना है, और वह उसे सुनता है।

यहाँ वह सब कुछ है जो आपको जानने की ज़रूरत है।

  • $state रिएक्टिव वेरिएबल्स को संभालता है। किसी भी वैल्यू को $state() में लपेट दें और कंपाइलर उसे ट्रैक करना जान जाता है।
  • $derived अन्य स्टेट से वैल्यूज कैलकुलेट करता है। क्या आपको एक फ़िल्टर्ड लिस्ट या फ़ॉर्मेटेड टोटल चाहिए? $derived का उपयोग करें। $effect से मुख्य अंतर यह है कि $derived वैल्यूज के लिए है, एक्शन्स के लिए नहीं।
  • $effect साइड इफेक्ट्स (side effects) चलाता है। डॉक्यूमेंट टाइटल अपडेट, मैन्युअल DOM मेजरमेंट, या ऐसे टाइमर के बारे में सोचें जिन्हें क्लीनअप की आवश्यकता होती है। यह DOM कमिट होने के बाद चलता है, जो एक लाइफसाइकिल हुक के समान है लेकिन विशिष्ट रिएक्टिव डिपेंडेंसी से जुड़ा होता है।
  • $props कंपोनेंट्स में डेटा प्राप्त करने के लिए पुराने export let पैटर्न की जगह लेता है। यह अधिक स्पष्ट है, और TypeScript के साथ बेहतर तरीके से काम करता है।

यह मॉडल व्यवहार में बहुत काम आता है। क्योंकि कंपाइलर केवल उसी चीज़ को ट्रैक करता है जिसे आप मार्क करते हैं, इसलिए डेड कोड डेड ही रहता है। आप यह सोचने के बजाय कि कोई वेरिएबल अपडेट क्यों ट्रिगर हुआ, अपने स्वयं के स्पष्ट निर्देशों पर भरोसा करना शुरू कर देते हैं।

कॉन्फ़िगरेशन नहीं, बल्कि फोल्डर्स द्वारा रूटिंग

SvelteKit रूटिंग के लिए आपके फाइल सिस्टम का उपयोग करता है। बनाए रखने के लिए कोई अलग राउटर फाइल नहीं है। किसी डायरेक्टरी में +page.svelte फाइल डालें, और वह डायरेक्टरी एक लाइव रूट बन जाएगी।

शेयर्ड UI (Shared UI) उन रूट्स को +layout.svelte के माध्यम से रैप करता है। इसे अपने रूट में रखें, और हर चाइल्ड रूट इसे इनहेरिट कर लेगा। इसे ट्री में गहराई में रखें, और केवल उसी सेक्शन को रैपर मिलेगा।

सर्वर-साइड लॉजिक +page.server.ts में रहता है। यह आपके पेज रेंडर होने से पहले चलता है, इसलिए यहीं पर आप डेटाबेस क्वेरी करते हैं, कुकी वैलिडेट करते हैं, या अन-ऑथेंटिकेटेड यूजर को रिजेक्ट करते हैं। टाइप्स आपके लोड फंक्शन से अपने आप आपके पेज कंपोनेंट में फ्लो होते हैं, जिसका अर्थ है कि बिना मैन्युअल इंटरफेस लिखे आपका डेटा टाइप किया हुआ रहता है।

रॉ API एंडपॉइंट्स +server.ts फाइलों में जाते हैं। ये स्टैंडर्ड HTTP हैंडलर्स—GET, POST, PUT, DELETE—एक्सपोर्ट करते हैं, जिससे अपने पेजों के साथ-साथ एक REST बैक एंड बनाना स्वाभाविक लगता है।

एक कम आंका गया फीचर: ग्रुप रूट्स (group routes)। किसी फोल्डर के नाम को कोष्ठक (parentheses) में लपेटकर, जैसे (auth), आप URL में कोई सेगमेंट जोड़े बिना एक शेयर्ड लेआउट बना सकते हैं। यह लॉगिन और साइनअप पेजों के लिए एकदम सही है जिन्हें एक ही न्यूनतम डिज़ाइन की आवश्यकता होती है लेकिन वे /auth/login के बजाय /login और /signup पर रहते हैं।

डेटा, सुरक्षा और प्रोग्रेसिव एनहांसमेंट

आधुनिक फ्रेमवर्क्स फुल-स्टैक के बारे में बात करना पसंद करते हैं, लेकिन कई बार वे आपको यह सोचने पर मजबूर कर देते हैं कि auth चेक या फॉर्म लॉजिक कहाँ रखना है। SvelteKit आपको स्पष्ट हुक्स देता है।

डेटा फेचिंग के लिए +page.server.ts का उपयोग करें। वहां लोड फंक्शन विशेष रूप से सर्वर पर चलता है, इसलिए आपके डेटाबेस क्रेडेंशियल्स कभी भी ब्राउज़र में लीक नहीं होते हैं। SvelteKit आपके लोड रिटर्न वैल्यूज से टाइप्स जेनरेट करता है, जिससे आपका फ्रंटएंड सटीक रहता है।

पूरी एप्लिकेशन को नियंत्रित करने के लिए hooks.server.ts का उपयोग करें। यह हर रिक्वेस्ट पर चलता है, जिससे यह सेशन वेरिफाई करने, JWT एक्सपायरी चेक करने, या आने वाले इवेंट्स में यूजर कॉन्टेक्स्ट जोड़ने के लिए सही जगह बन जाती है।

म्यूटेशन (mutations) के लिए, फॉर्म एक्शन्स का उपयोग करें। एक अलग API एंडपॉइंट को जोड़ने और JSON को हैंडल करने के बजाय, आप +page.server.ts के अंदर एक एक्शन को परिभाषित करते हैं। इसकी खूबसूरती प्रोग्रेसिव एनहांसमेंट (progressive enhancement) में है। यदि JavaScript लोड होने में विफल रहता है—या यदि किसी यूजर ने इसे डिसेबल कर दिया है—तो भी फॉर्म सर्वर एक्शन पर सबमिट हो जाता है और पेज परिणाम के साथ फिर से रेंडर हो जाता है। यदि JavaScript मौजूद है, तो SvelteKit बिना फुल रीलोड के अनुभव को बेहतर बना देता है। आपको एक ही कोड से मजबूती और फिनिशिंग मिलती है।

एक नियम याद रखें: अपनी गणना $derived में करें, $effect में नहीं। वैल्यूज कैलकुलेट करने के लिए $effect का उपयोग करने से ऐसे अपडेट लूप ट्रिगर हो सकते हैं जिन्हें ट्रैक करना मुश्किल होता है। $effect को वास्तविक साइड इफेक्ट्स के लिए रखें, और $derived को अपने कंप्यूटेड स्टेट का स्वामित्व दें।

SvelteKit बनाम Next.js

Both frameworks can ship production applications, but the trade-offs are real.

Bundle size favors SvelteKit. Because Svelte compiles components to vanilla JavaScript and skips the Virtual DOM entirely, the runtime footprint stays small. Next.js carries React’s reconciliation engine with it.

Reactivity also differs. SvelteKit resolves runes at compile time. The browser receives plain updates. Next.js relies on React’s runtime hooks and reconciliation, which means more work happens on the client.

Onboarding is gentler with SvelteKit. The mental model is smaller. You are not juggling useEffect dependency arrays or memoization puzzles to avoid re-renders. TypeScript integration deserves a mention too. While both frameworks