اگر چند سال گذشته را صرف جابهجایی بین متا-فریمورکهای مختلف کرده باشید، SvelteKit 2 برای شما ترکیبی عجیب از آرامش و تردید خواهد بود. آرامش، چون به جای اضافه کردن پیچیدگی، واقعاً آن را حذف میکند. تردید، چون مدام منتظر هستید که مشکلی پیش بیاید. اما هیچ مشکلی پیش نمیآید. در کنار Svelte 5، این استک یکی از پربازدهترین روشها برای عرضه یک اپلیکیشن full-stack در سال ۲۰۲۶ است و اعداد نیز تجربه توسعهدهنده را تأیید میکنند. حجم باندلها تقریباً ۳۵٪ کمتر از خروجی Svelte 4 است. مسیریابی (Routing)، توابع سرور و الگوهای احراز هویت همگی جزو قابلیتهای اصلی (first-class citizens) هستند، نه پلاگینهایی که باید با چسب به هم وصل کنید.
رونها (runes) واکنشگرایی را صریح میکنند
بزرگترین تغییر ذهنی از runes در Svelte 5 ناشی میشود. نسخههای قبلی Svelte از برچسب $: و مقدار زیادی جادوی کامپایلر برای ردیابی وابستگیها استفاده میکردند. کار میکرد، اما وقتی چیزی خراب میشد، انگار داشتید سیمهای نامرئی را دیباگ میکردید. runes آن جادو را با توابع صریح جایگزین میکنند. شما دقیقاً به کامپایلر میگویید چه چیزی را ردیابی کند و او گوش میدهد.
در اینجا آنچه باید بدانید آمده است:
- $state متغیرهای واکنشگرا را مدیریت میکند. هر مقداری را در
$state()قرار دهید تا کامپایلر متوجه شود باید آن را زیر نظر بگیرد. - $derived مقادیر را از سایر stateها محاسبه میکند. به یک لیست فیلتر شده یا یک مجموع فرمتشده نیاز دارید؟ از
$derivedاستفاده کنید. تفاوت اصلی با$effectاین است که$derivedبرای مقادیر است، نه عملیات (actions). - $effect اثرات جانبی (side effects) را اجرا میکند. به مواردی مثل بهروزرسانی عنوان سند (document title)، اندازهگیری دستی DOM یا تایمرهایی که نیاز به پاکسازی (cleanup) دارند فکر کنید. این تابع پس از ثبت (commit) در DOM اجرا میشود، مشابه یک lifecycle hook اما متصل به وابستگیهای واکنشگرای خاص.
- $props جایگزین الگوی قدیمی
export letبرای دریافت دادهها در کامپوننتها میشود. این روش شفافتر است و تعامل بهتری با TypeScript دارد.
این مدل در عمل نتیجه میدهد. چون کامپایلر فقط آنچه را که شما علامتگذاری کردهاید ردیابی میکند، کدهای مرده (dead code) همان مرده باقی میمانند. دیگر از خود نمیپرسید که چرا یک متغیر باعث بهروزرسانی شده است، بلکه شروع به اعتماد به دستورات صریح خود میکنید.
مسیریابی بر اساس پوشهها، نه پیکربندی
SvelteKit از سیستم فایل شما برای مسیریابی استفاده میکند. نیازی به نگهداری یک فایل جداگانه برای router نیست. یک فایل +page.svelte در یک دایرکتوری قرار دهید و آن دایرکتوری به یک مسیر زنده تبدیل میشود.
رابط کاربری مشترک (Shared UI) از طریق +layout.svelte آن مسیرها را در بر میگیرد. یکی در ریشه (root) قرار دهید تا تمام مسیرهای فرزند از آن ارثبری کنند. اگر آن را در لایههای عمیقتر قرار دهید، فقط همان بخش شامل آن wrapper خواهد بود.
منطق سمت سرور در +page.server.ts قرار دارد. این کد قبل از رندر شدن صفحه اجرا میشود، بنابراین جایی است که کوئری دیتابیس میزنید، کوکی را اعتبارسنجی میکنید یا کاربر احراز هویت نشده را رد میکنید. تایپها بهطور خودکار از تابع load به کامپوننت صفحه منتقل میشوند، به این معنی که دادههای شما بدون نوشتن اینترفیسهای دستی، دارای تایپ هستند.
نقاط پایانی API خام در فایلهای +server.ts قرار میگیرند. این فایلها هندلرهای استاندارد HTTP شامل GET، POST، PUT و DELETE را صادر میکنند، بنابراین ساخت یک بکاِند REST در کنار صفحات، بسیار طبیعی به نظر میرسد.
یک ویژگی که کمتر به آن توجه میشود: گروهبندی مسیرها (group routes). با قرار دادن نام پوشه داخل پرانتز، مثلاً (auth)، یک layout مشترک ایجاد میکنید بدون اینکه بخش جدیدی به URL اضافه شود. این برای صفحات ورود و ثبتنام که نیاز به ظاهر ساده و مشابه دارند اما در آدرسهای /login و /signup قرار میگیرند (و نه /auth/login) عالی است.
دادهها، امنیت و بهبود تدریجی (progressive enhancement)
فریمورکهای مدرن عاشق صحبت از full-stack هستند، اما بسیاری از آنها شما را در سردرگمی رها میکنند که بررسیهای auth یا منطق فرم را کجا قرار دهید. SvelteKit قلابهای (hooks) مشخصی در اختیار شما میگذارد.
از +page.server.ts برای واکشی دادهها استفاده کنید. تابع load در آنجا منحصراً روی سرور اجرا میشود، بنابراین اطلاعات حساس دیتابیس شما هرگز به مرورگر نشت نمیکند. SvelteKit تایپها را از مقادیر بازگشتی load تولید میکند تا فرانتاند شما همیشه دقیق و هماهنگ باقی بماند.
از hooks.server.ts برای کنترل دسترسی کل اپلیکیشن استفاده کنید. این کد در هر درخواست اجرا میشود و بهترین مکان برای تأیید نشستها (sessions)، بررسی انقضای JWT یا پیوست کردن context کاربر به رویدادهای ورودی است.
برای تغییرات (mutations)، از form actions استفاده کنید. به جای اتصال یک endpoint جداگانه API و مدیریت JSON، یک action داخل +page.server.ts تعریف میکنید. زیبایی این کار در "progressive enhancement" است. اگر جاوااسکریپت بارگذاری نشود - یا اگر کاربر آن را غیرفعال کرده باشد - فرم همچنان به server action ارسال میشود و صفحه با نتیجه دوباره رندر میشود. اگر جاوااسکریپت فعال باشد، SvelteKit تجربه کاربری را بدون نیاز به بارگذاری کامل صفحه بهبود میبخشد. شما از یک کد واحد، هم پایداری و هم ظرافت (polish) به دست میآورید.
یک قانون که باید به خاطر داشته باشید: محاسبات ریاضی را در $derived انجام دهید، نه در $effect. استفاده از $effect برای محاسبه مقادیر میتواند باعث ایجاد حلقههای بهروزرسانی (update loops) شود که ردیابی آنها دشوار است. $effect را برای اثرات جانبی واقعی نگه دارید و اجازه دهید $derived مسئولیت stateهای محاسباتی شما را بر عهده بگیرد.
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