إذا كنت قد قضيت السنوات القليلة الماضية تتنقل بين أطر العمل الفوقية (meta-frameworks)، فستشعر تجاه SvelteKit 2 بمزيج غريب من الارتياح والريبة. الارتياح، لأنها تزيل التعقيد فعلياً بدلاً من إضافته. والريبة، لأنك تظل تنتظر وقوع المفاجأة غير السارة. لكنها لا تقع أبداً. عند اقترانها بـ Svelte 5، تُعد هذه المجموعة (stack) واحدة من أكثر الطرق إنتاجية لإطلاق تطبيق full-stack في عام 2026، والأرقام تدعم تجربة المطور هذه؛ حيث تأتي الحزم (Bundles) أصغر بنسبة 35% تقريباً مما كانت تنتجه Svelte 4. وتُعد عمليات التوجيه (Routing)، والوظائف البرمجية للخادم (server functions)، وأنماط المصادقة (authentication patterns) مواطنين من الدرجة الأولى، وليست مجرد إضافات (plugins) تقوم بترقيعها معاً.

الـ runes تجعل التفاعلية صريحة

يأتي التحول الذهني الأكبر من الـ runes في Svelte 5. استخدمت الإصدارات السابقة من Svelte علامة $: والكثير من سحر المترجم (compiler magic) لتتبع التبعيات. لقد نجح الأمر، ولكن عندما كان يحدث عطل ما، كنت تضطر لتصحيح أخطاء (debugging) أسلاك غير مرئية. تستبدل الـ runes ذلك السحر بوظائف صريحة؛ فأنت تخبر المترجم بالضبط بما يجب تتبعه، وهو يستجيب.

إليك ما تحتاج إلى معرفته:

  • $state تتعامل مع المتغيرات التفاعلية. قم بتغليف أي قيمة بـ $state() وسيعرف المترجم أنه يجب مراقبتها.
  • $derived تحسب القيم من حالة (state) أخرى. هل تحتاج إلى قائمة مصفاة أو إجمالي منسق؟ استخدم $derived. الفرق الجوهري عن $effect هو أن $derived مخصص للقيم، وليس للإجراءات.
  • $effect تقوم بتشغيل الآثار الجانبية (side effects). فكر في تحديثات عنوان المستند، أو قياسات DOM اليدوية، أو المؤقتات التي تحتاج إلى تنظيف. يتم تشغيلها بعد اعتماد الـ DOM، بشكل مشابه لخطاف دورة الحياة (lifecycle hook) ولكنها مرتبطة بتبعيات تفاعلية محددة.
  • $props تستبدل نمط export let القديم لاستقبال البيانات في المكونات. إنها أكثر وضوحاً، وتتفاعل بشكل أفضل مع TypeScript.

هذا النموذج يؤتي ثماره في الممارسة العملية. نظرًا لأن المترجم يتتبع فقط ما تحدده، فإن الكود غير المستخدم (dead code) يظل غير مستخدم. ستتوقف عن التساؤل عن سبب تسبب متغير ما في تحديث، وستبدأ في الثقة بتعليماتك الصريحة.

التوجيه عبر المجلدات، وليس عبر الإعدادات

يستخدم SvelteKit نظام الملفات الخاص بك للتوجيه. لا يوجد ملف توجيه (router) منفصل يحتاج إلى صيانة. ضع ملف +page.svelte في مجلد ما، وسيصبح ذلك المجلد مساراً (route) حياً.

تقوم واجهة المستخدم المشتركة بتغليف تلك المسارات من خلال +layout.svelte. ضع ملفاً في الجذر (root)، وسترثه كل المسارات الفرعية. ضع ملفاً في مستوى أعمق في الشجرة، وسيتم تطبيق الغلاف على ذلك القسم فقط.

تعيش المنطق البرمجي من جهة الخادم (Server-side logic) في ملفات +page.server.ts. يتم تشغيل هذا قبل عرض صفحتك، لذا فهو المكان المناسب للاستعلام من قاعدة البيانات، أو التحقق من ملف تعريف الارتباط (cookie)، أو رفض مستخدم غير مصرح له. وتتدفق الأنواع (types) تلقائياً من وظيفة التحميل (load function) الخاصة بك إلى مكون الصفحة، مما يعني أن بياناتك محددة الأنواع دون الحاجة لكتابة واجهات (interfaces) يدوية.

توضع نقاط نهاية واجهة برمجة التطبيقات (API endpoints) الخام في ملفات +server.ts. تقوم هذه الملفات بتصدير معالجات HTTP قياسية — GET، POST، PUT، DELETE — لذا فإن بناء خلفية REST بجانب صفحاتك يبدو أمراً طبيعياً.

ميزة واحدة لا تحظى بالتقدير الكافي: تجميع المسارات (group routes). من خلال وضع اسم المجلد بين قوسين، مثل (auth)، يمكنك إنشاء تخطيط مشترك دون إضافة جزء إلى عنوان URL. هذا مثالي لصفحات تسجيل الدخول وإنشاء الحساب التي تحتاج إلى نفس المظهر المبسط ولكنها تعمل تحت /login و /signup وليس /auth/login.

البيانات، والأمان، والتحسين التدريجي

تحب أطر العمل الحديثة التحدث عن الـ full-stack، لكن الكثير منها يتركك في حيرة من أمرك حول مكان وضع فحوصات المصادقة أو منطق النماذج (form logic). يوفر لك SvelteKit خطافات (hooks) واضحة.

استخدم +page.server.ts لجلب البيانات. تعمل وظيفة load هناك حصرياً على الخادم، لذا فإن بيانات اعتماد قاعدة البيانات الخاصة بك لن تتسرب أبداً إلى المتصفح. يقوم SvelteKit بإنشاء الأنواع (types) من قيم الإرجاع لوظيفة load الخاصة بك، مما يحافظ على دقة بيانات الواجهة الأمامية (frontend).

استخدم hooks.server.ts للتحكم في الوصول إلى التطبيق بأكمله. يتم تشغيل هذا مع كل طلب، مما يجعله المكان المناسب للتحقق من الجلسات (sessions)، أو التحقق من انتهاء صلاحية JWT، أو إرفاق سياق المستخدم (user context) بالأحداث الواردة.

بالنسبة لعمليات التعديل (mutations)، استخدم إجراءات النماذج (form actions). بدلاً من ربط نقطة نهاية API منفصلة والتعامل مع JSON، يمكنك تعريف إجراء (action) داخل +page.server.ts. الجمال هنا يكمن في التحسين التدريجي (progressive enhancement)؛ فإذا فشل تحميل JavaScript — أو إذا قام المستخدم بتعطيله — فسيظل النموذج يُرسل إلى إجراء الخادم وتتم إعادة عرض الصفحة مع النتيجة. وإذا كان JavaScript موجوداً، يقوم SvelteKit بتحسين التجربة دون إعادة تحميل كاملة. ستحصل على المرونة والاحترافية من نفس الكود.

قاعدة واحدة يجب وضعها في الاعتبار: قم بإجراء العمليات الحسابية في $derived وليس في $effect. استخدام $effect لحساب القيم يمكن أن يؤدي إلى حلقات تحديث (update loops) يصعب تتبعها. اترك $effect للآثار الجانبية الحقيقية، واجعل $derived يتولى مسؤولية حالتك المحسوبة (computed 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