اگر آپ نے گزشتہ چند سال مختلف meta-frameworks کے درمیان ادھر ادھر بھٹکتے ہوئے گزارے ہیں، تو SvelteKit 2 آپ کو سکون اور شک کے ایک عجیب امتزاج کی طرح محسوس ہوگا۔ سکون اس لیے، کیونکہ یہ پیچیدگیوں کو بڑھانے کے بجائے انہیں ختم کرتا ہے۔ شک اس لیے، کیونکہ آپ مسلسل اس انتظار میں رہتے ہیں کہ کب کوئی مسئلہ سامنے آئے گا۔ لیکن ایسا کبھی نہیں ہوتا۔ Svelte 5 کے ساتھ مل کر، یہ اسٹیک 2026 میں ایک full-stack application تیار کرنے کے سب سے زیادہ پیداواری طریقوں میں سے ایک ہے، اور اعداد و شمار ڈویلپر کے تجربے (developer experience) کی تصدیق کرتے ہیں۔ بنڈلز کا سائز Svelte 4 کے مقابلے میں تقریباً 35% کم ہوتا ہے۔ Routing، server functions، اور authentication patterns سب بنیادی اور اہم حصے ہیں، نہ کہ کوئی ایسے پلگ انز جنہیں آپ جوڑ توڑ کر استعمال کرتے ہیں۔

runes reactivity کو واضح بناتے ہیں

سب سے بڑی ذہنی تبدیلی Svelte 5 کے runes سے آتی ہے۔ Svelte کے پچھلے ورژن dependencies کو ٹریک کرنے کے لیے $: لیبل اور بہت زیادہ compiler magic کا استعمال کرتے تھے۔ یہ کام تو کرتا تھا، لیکن جب کچھ ٹوٹ جاتا تھا، تو آپ ان دیکھی تاروں کو ڈی بگ (debug) کر رہے ہوتے تھے۔ Runes اس جادو کی جگہ واضح فنکشنز (explicit functions) لے لیتے ہیں۔ آپ کمپائلر کو بالکل بتاتے ہیں کہ اسے کیا ٹریک کرنا ہے، اور وہ آپ کی بات سنتا ہے۔

یہاں وہ چیزیں ہیں جو آپ کو جاننے کی ضرورت ہیں:

  • $state reactive variables کو سنبھالتا ہے۔ کسی بھی ویلیو کو $state() میں لپیٹ دیں اور کمپائلر اسے مانیٹر کرنا جانتا ہے۔
  • $derived دوسرے state سے ویلیوز کا حساب لگاتا ہے۔ کیا آپ کو ایک فلٹر شدہ لسٹ یا فارمیٹ شدہ ٹوٹل چاہیے؟ $derived استعمال کریں۔ $effect سے اس کا بنیادی فرق یہ ہے کہ $derived ویلیوز کے لیے ہے، actions کے لیے نہیں۔
  • $effect side effects چلاتا ہے۔ اس کے بارے میں سوچیں جیسے document title کی اپ ڈیٹس، دستی DOM پیمائش، یا ٹائمرز جنہیں صفائی (cleanup) کی ضرورت ہو۔ یہ DOM commit ہونے کے بعد چلتا ہے، بالکل ایک lifecycle hook کی طرح لیکن مخصوص reactive dependencies سے منسلک۔
  • $props components میں ڈیٹا وصول کرنے کے لیے پرانے export let پیٹرن کی جگہ لیتا ہے۔ یہ زیادہ واضح ہے، اور TypeScript کے ساتھ بہتر طریقے سے کام کرتا ہے۔

یہ ماڈل عملی طور پر بہت فائدہ مند ہے۔ چونکہ کمپائلر صرف اسی چیز کو ٹریک کرتا ہے جسے آپ نشان زد کرتے ہیں، اس لیے غیر ضروری کوڈ (dead code) غیر فعال ہی رہتا ہے۔ آپ یہ سوچنا چھوڑ دیتے ہیں کہ کسی ویلیو نے اپ ڈیٹ کیوں ٹرگر کی، اور آپ اپنی واضح ہدایات پر بھروسہ کرنا شروع کر دیتے ہیں۔

کنفیگریشن کے بجائے فولڈرز کے ذریعے routing

SvelteKit routing کے لیے آپ کے فائل سسٹم کا استعمال کرتا ہے۔ برقرار رکھنے کے لیے کوئی الگ router فائل نہیں ہے۔ کسی ڈائریکٹری میں +page.svelte فائل ڈالیں، اور وہ ڈائریکٹری ایک لائیو روٹ (live route) بن جاتی ہے۔

Shared UI ان routes کو +layout.svelte کے ذریعے لپیٹتا ہے۔ اسے اپنے روٹ (root) میں رکھیں، اور ہر چائلڈ روٹ اسے وراثت میں حاصل کرے گا۔ اسے ٹری (tree) میں مزید گہرائی میں رکھیں، تو صرف وہی حصہ اس wrapper کو حاصل کرے گا۔

Server-side logic +page.server.ts میں ہوتا ہے۔ یہ آپ کے پیج کے رینڈر ہونے سے پہلے چلتا ہے، اس لیے یہ وہ جگہ ہے جہاں آپ ڈیٹا بیس کو کوئری کرتے ہیں، کوکی (cookie) کو ویلیڈیٹ کرتے ہیں، یا کسی غیر تصدیق شدہ صارف کو مسترد کرتے ہیں۔ ٹائپس (types) آپ کے load function سے خود بخود آپ کے پیج کمپوننٹ میں منتقل ہو جاتے ہیں، جس کا مطلب ہے کہ آپ کو دستی interfaces لکھے بغیر آپ کا ڈیٹا ٹائپڈ (typed) رہتا ہے۔

Raw API endpoints +server.ts فائلوں میں جاتے ہیں۔ یہ معیاری HTTP handlers—GET, POST, PUT, DELETE—ایکسپورٹ کرتے ہیں، اس لیے اپنے پیجز کے ساتھ ایک REST back end بنانا بالکل فطری محسوس ہوتا ہے۔

ایک کم اہمیت یافتہ فیچر: group routes۔ کسی فولڈر کے نام کو بریکٹ میں رکھ کر، جیسے (auth)، آپ URL میں کوئی نیا حصہ شامل کیے بغیر ایک مشترکہ لے آؤٹ (shared layout) بنا سکتے ہیں۔ یہ لاگ ان اور سائن اپ پیجز کے لیے بہترین ہے جنہیں ایک ہی سادہ ڈیزائن کی ضرورت ہوتی ہے لیکن وہ /login اور /signup پر رہتے ہیں، نہ کہ /auth/login پر۔

ڈیٹا، سیکیورٹی، اور progressive enhancement

جدید فریم ورکس full-stack کے بارے میں بات کرنا پسند کرتے ہیں، لیکن بہت سے آپ کو یہ اندازہ لگانے پر مجبور کر دیتے ہیں کہ auth checks یا form logic کہاں رکھنا ہے۔ SvelteKit آپ کو واضح hooks فراہم کرتا ہے۔

ڈیٹا فیچنگ کے لیے +page.server.ts استعمال کریں۔ وہاں موجود load function صرف سرور پر چلتا ہے، اس لیے آپ کے ڈیٹا بیس کے کریڈنشلز کبھی بھی براؤزر تک نہیں پہنچتے۔ SvelteKit آپ کے load return values سے ٹائپس تیار کرتا ہے، تاکہ آپ کا فرنٹ اینڈ درست رہے۔

پورے ایپلی کیشن کو کنٹرول کرنے کے لیے hooks.server.ts استعمال کریں۔ یہ ہر ریکویسٹ پر چلتا ہے، جو اسے سیشنز کی تصدیق کرنے، JWT کی میعاد چیک کرنے، یا آنے والے ایونٹس کے ساتھ یوزر کانٹیکسٹ (user context) منسلک کرنے کے لیے صحیح جگہ بناتا ہے۔

Mutations کے لیے form actions استعمال کریں۔ ایک الگ API endpoint بنانے اور JSON کو سنبھالنے کے بجائے، آپ +page.server.ts کے اندر ایک action ڈیفائن کرتے ہیں۔ اس کی خوبصورتی progressive enhancement میں ہے۔ اگر JavaScript لوڈ ہونے میں ناکام ہو جائے—یا اگر صارف نے اسے ڈس ایبل کر دیا ہو—تب بھی فارم سرور ایکشن پر سبمٹ ہو جاتا ہے اور پیج نتیجے کے ساتھ دوبارہ رینڈر ہو جاتا ہے۔ اگر JavaScript موجود ہے، تو SvelteKit مکمل ری لوڈ کے بغیر تجربے کو بہتر بنا دیتا ہے۔ آپ کو ایک ہی کوڈ سے استحکام اور نفاست ملتی ہے۔

ایک اصول جو ذہن میں رکھنا ضروری ہے: حساب کتاب $derived میں کریں، $effect میں نہیں۔ ویلیوز کیلکولیٹ کرنے کے لیے $effect کا استعمال ایسے اپ ڈیٹ لوپس (update loops) پیدا کر سکتا ہے جن کا سراغ لگانا مشکل ہوتا ہے۔ $effect کو حقیقی side effects کے لیے رکھیں، اور $derived کو اپنے computed state کا ذمہ دار بنائیں۔

SvelteKit بمقابلہ Next.js

دونوں فریم ورکس پروڈکشن ایپلی کیشنز لانچ کر سکتے ہیں، لیکن ان کے درمیان توازن (trade-offs) کا فرق حقیقی ہے۔

بنڈل سائز کے معاملے میں SvelteKit بہتر ہے۔ چونکہ Svelte کمپوننٹس کو vanilla JavaScript میں کمپائل کرتا ہے اور Virtual DOM کو مکمل طور پر چھوڑ دیتا ہے، اس لیے runtime footprint چھوٹا رہتا ہے۔ Next.js اپنے ساتھ React کا reconciliation engine لے کر چلتا ہے۔

ری ایکٹیویٹی (Reactivity) بھی مختلف ہے۔ SvelteKit runes کو compile time پر حل کرتا ہے۔ براؤزر کو سادہ اپ ڈیٹس موصول ہوتی ہیں۔ Next.js، React کے runtime hooks اور reconciliation پر انحصار کرتا ہے، جس کا مطلب ہے کہ کلائنٹ پر زیادہ کام ہوتا ہے۔

SvelteKit کے ساتھ سیکھنے کا عمل (onboarding) آسان ہے۔ اس کا ذہنی ماڈل (mental model) کم پیچیدہ ہے۔ آپ کو re-renders سے بچنے کے لیے useEffect dependency arrays یا memoization کے پیچیدہ مسائل سے نہیں لڑنا پڑتا۔ TypeScript کے انٹیگریشن کا ذکر کرنا بھی ضروری ہے۔ اگرچہ دونوں فریم ورکس