जर तुम्ही गेल्या काही वर्षांत विविध meta-frameworks मध्ये फिरत असाल, तर SvelteKit 2 तुम्हाला सुटकेचा निश्वास आणि संशय यांचा एक विचित्र मिलाफ वाटेल. सुटका, कारण ते गुंतागुंत वाढवण्याऐवजी ती प्रत्यक्षात कमी करते. संशय, कारण तुम्हाला सतत काहीतरी गडबड होईल अशी वाटत राहते. पण तसे कधीच घडत नाही. Svelte 5 सोबत जोडून, हे स्टॅक 2026 मध्ये full-stack application तयार करण्याचा सर्वात उत्पादक (productive) मार्ग आहे, आणि आकडेवारी देखील डेव्हलपर एक्सपिरियन्सची (developer experience) पुष्टी करते. Svelte 4 च्या तुलनेत बंडल्स (Bundles) साधारणपणे 35% लहान येतात. Routing, server functions आणि authentication patterns हे सर्व 'first-class citizens' आहेत, ते केवळ एकत्र जोडलेले प्लगइन्स नाहीत.
Runes मुळे reactivity स्पष्ट होते
सर्वात मोठा मानसिक बदल Svelte 5 च्या runes मुळे येतो. Svelte च्या मागील आवृत्त्यांमध्ये dependencies ट्रॅक करण्यासाठी $: लेबल आणि मोठ्या प्रमाणावर कंपायलर मॅजिकचा (compiler magic) वापर केला जात असे. ते काम करत होते, पण जेव्हा काही बिघडायचे, तेव्हा तुम्हाला अदृश्य तारा (invisible wires) शोधून दुरुस्त कराव्या (debugging) लागायच्या. Runes त्या मॅजिकची जागा स्पष्ट फंक्शन्सनी (explicit functions) घेतात. तुम्ही कंपायलरला नेमके काय ट्रॅक करायचे आहे ते सांगता आणि तो ते ऐकतो.
तुम्हाला काय माहित असणे आवश्यक आहे ते खालीलप्रमाणे आहे:
- $state reactive variables हाताळते. कोणत्याही व्हॅल्यूला
$state()मध्ये गुंडाळा (wrap) आणि कंपायलरला ते लक्ष ठेवायचे आहे हे समजते. - $derived इतर state मधून व्हॅल्यूज मोजते (computes). तुम्हाला फिल्टर केलेली लिस्ट किंवा फॉरमॅट केलेले एकूण मूल्य हवे आहे का? तर
$derivedवापरा.$effectपेक्षा मुख्य फरक असा की$derivedहे व्हॅल्यूजसाठी आहे, ॲक्शन्ससाठी नाही. - $effect side effects चालवते. डॉक्युमेंट टायटल अपडेट्स, मॅन्युअल DOM मोजमाप किंवा क्लिनअपची गरज असलेले टाइमर्स यांसारख्या गोष्टींचा विचार करा. हे DOM कमिट (commit) झाल्यानंतर चालते, जे lifecycle hook सारखे आहे पण विशिष्ट reactive dependencies शी जोडलेले असते.
- $props कंपोनंट्समध्ये डेटा प्राप्त करण्यासाठी जुन्या
export letपॅटर्नची जागा घेते. हे अधिक स्पष्ट आहे आणि TypeScript सोबत अधिक चांगल्या प्रकारे काम करते.
हा मॉडेल प्रत्यक्ष वापरात फायदेशीर ठरतो. कारण कंपायलर फक्त तुम्ही मार्क केलेली गोष्टच ट्रॅक करतो, त्यामुळे 'dead code' तसाच राहतो. एखादे व्हेरिएबल अपडेट का झाले, असा विचार करणे थांबवता येते आणि तुम्ही तुमच्या स्वतःच्या स्पष्ट सूचनांवर विश्वास ठेवू शकता.
कॉन्फिगरेशनद्वारे नाही, तर फोल्डर्सद्वारे Routing
SvelteKit routing साठी तुमच्या file system चा वापर करते. मेंटेन करण्यासाठी कोणतीही वेगळी router फाईल नसते. एखाद्या डिरेक्टरीमध्ये +page.svelte फाईल टाका आणि ती डिरेक्टरी एक लाइव्ह रूट (live route) बनते.
Shared UI +layout.svelte द्वारे त्या रूट्सना वेढते (wraps). तुमच्या रूटमध्ये एक ठेवा, आणि प्रत्येक चाइल्ड रूटला ते वारसा (inherit) मिळेल. झाडाच्या (tree) अधिक खोलवर एक ठेवा, आणि फक्त त्या विभागालाच wrapper मिळेल.
Server-side logic +page.server.ts मध्ये असते. हे तुमचे पेज रेंडर होण्यापूर्वी चालते, त्यामुळे डेटाबेस क्वेरी करणे, कुकी व्हॅलिडेट करणे किंवा अन-ऑथेंटिकेटेड युजरला नाकारणे यासाठी हे योग्य ठिकाण आहे. Types तुमच्या load function मधून थेट तुमच्या पेज कंपोनंटमध्ये आपोआप येतात, याचा अर्थ असा की मॅन्युअल इंटरफेस न लिहिता तुमचा डेटा 'typed' असतो.
Raw API endpoints +server.ts फाईल्समध्ये जातात. हे standard HTTP handlers—GET, POST, PUT, DELETE—एक्सपोर्ट करतात, त्यामुळे तुमच्या पेजेससोबत REST back end तयार करणे नैसर्गिक वाटते.
एक कमी लेखले जाणारे वैशिष्ट्य: group routes. फोल्डरचे नाव कंसात (parentheses) टाकून, जसे की (auth), तुम्ही URL मध्ये कोणताही नवीन सेगमेंट न जोडता एक shared layout तयार करू शकता. हे लॉगिन आणि साइनअप पेजेससाठी उत्तम आहे ज्यांना सारखाच साध्या स्वरूपाचा लूक (stripped-down chrome) हवा असतो, पण ते /auth/login ऐवजी /login आणि /signup वर असतात.
डेटा, सुरक्षा आणि progressive enhancement
आधुनिक frameworks full-stack बद्दल बोलण्यास आवडतात, पण अनेकदा auth checks किंवा form logic कुठे ठेवायचे याबाबत तुम्हाला गोंधळात टाकतात. SvelteKit तुम्हाला स्पष्ट hooks देते.
डेटा फेचिंगसाठी (data fetching) +page.server.ts वापरा. तिथली load function फक्त सर्व्हरवर चालते, त्यामुळे तुमचे डेटाबेस क्रेडेंशियल्स (credentials) कधीही ब्राउझरमध्ये लीक होत नाहीत. SvelteKit तुमच्या load return values मधून types तयार करते, ज्यामुळे तुमचे frontend अचूक राहते.
संपूर्ण ॲप्लिकेशन नियंत्रित करण्यासाठी (gate) hooks.server.ts वापरा. हे प्रत्येक रिक्वेस्टवर चालते, ज्यामुळे सेशन्स (sessions) व्हेरिफाय करणे, JWT एक्सपायरी तपासणे किंवा येणाऱ्या इव्हेंट्सना युजर कॉन्टेक्स्ट जोडणे यासाठी हे योग्य ठिकाण ठरते.
Mutations साठी, form actions वापरा. वेगळा API endpoint तयार करून JSON हाताळण्याऐवजी, तुम्ही +page.server.ts मध्ये एक action परिभाषित करता. याचे सौंदर्य 'progressive enhancement' मध्ये आहे. जर JavaScript लोड होण्यास अपयश आले—किंवा युजरने ते डिसेबल केले असेल—तरीही फॉर्म सर्व्हर ॲक्शनला सबमिट होतो आणि पेज रिझल्टसह पुन्हा रेंडर होते. जर JavaScript उपलब्ध असेल, तर SvelteKit पूर्ण रीलोड न करता अनुभव अधिक चांगला करते. तुम्हाला एकाच कोडमधून लवचिकता (resilience) आणि फिनिशिंग मिळते.
लक्षात ठेवण्यासारखा एक नियम: तुमची गणिती प्रक्रिया (math) $derived मध्ये करा, $effect मध्ये नाही. व्हॅल्यूज कॅल्क्युलेट करण्यासाठी $effect वापरल्यास अपडेट लूप्स (update loops) तयार होऊ शकतात जे शोधणे कठीण असते. $effect फक्त खऱ्या side effects साठी ठेवा आणि तुमच्या computed state साठी $derived वापरा.
SvelteKit विरुद्ध Next.js
दोन्ही फ्रेमवर्कद्वारे प्रोडक्शन ॲप्लिकेशन्स लॉन्च करता येतात, परंतु त्यांच्यातील तफावत (trade-offs) वास्तविक आहे.
बंडल साईजच्या (Bundle size) बाबतीत SvelteKit सरस आहे. कारण Svelte कंपोनंट्सना व्हॅनिला JavaScript मध्ये कंपाईल करते आणि Virtual DOM पूर्णपणे वगळते, त्यामुळे रनटाइम फूटप्रिंट (runtime footprint) कमी राहतो. Next.js सोबत React चे reconciliation engine येते.
रिॲक्टिव्हिटीमध्येही (Reactivity) फरक आहे. SvelteKit रनस (runes) कंपाईल टाइमलाच रिझॉल्व्ह करते. ब्राउझरला साधे अपडेट्स मिळतात. Next.js हे React च्या रनटाइम हुक्स (runtime hooks) आणि रिकॉन्सिलिएशनवर अवलंबून असते, ज्याचा अर्थ क्लायंटवर अधिक काम करावे लागते.
SvelteKit सोबत ऑनबोर्डिंग (Onboarding) सोपे आहे. याचे मेंटल मॉडेल (mental model) लहान आहे. री-रेंडरिंग (re-renders) टाळण्यासाठी तुम्हाला useEffect डिपेंडन्सी ॲरे किंवा मेमोइझेशनच्या (memoization) समस्यांशी झुंजावे लागत नाही. TypeScript इंटिग्रेशनचा उल्लेख करणेही महत्त्वाचे आहे. जरी दोन्ही फ्रेमवर्क