אם ביליתם את השנים האחרונות בקפיצה בין meta-frameworks שונים, SvelteKit 2 ירגיש לכם כמו שילוב מוזר של הקלה וחשדנות. הקלה, כי הוא באמת מסיר מורכבות במקום להוסיף אותה. חשדנות, כי אתם ממשיכים לחכות שמשהו יקרה. הוא אף פעם לא באמת קורה. בשילוב עם Svelte 5, ה-stack הזה הוא אחת הדרכים הפרודוקטיביות ביותר להוציא לאור אפליקציית full-stack בשנת 2026, והמספרים תומכים בחוויית המפתח (developer experience). ה-bundles יוצאים בערך 35% קטנים יותר ממה ש-Svelte 4 ייצרה. routing, פונקציות שרת ודפוסי אימות (authentication) הם כולם אזרחים מדרגה ראשונה, ולא פלאגינים שאתם מדביקים יחד עם "סרט דביק".

ה-runes הופכים את ה-reactivity למפורש

השינוי המנטלי הגדול ביותר מגיע מה-runes של Svelte 5. גרסאות קודמות של Svelte השתמשו בתגית $: ובהרבה "קסם קומפיילר" כדי לעקוב אחר תלויות (dependencies). זה עבד, אבל כשמשהו נשבר, הייתם עושים debugging לחוטים בלתי נראים. ה-runes מחליפים את הקסם הזה בפונקציות מפורשות. אתם אומרים לקומפיילר בדיוק מה לעקוב אחריו, והוא מקשיב.

הנה מה שאתם צריכים לדעת:

  • $state מטפל במשתנים ריאקטיביים. עטפו כל ערך ב-$state() והקומפיילר ידע לעקוב אחריו.
  • $derived מחשב ערכים מתוך state אחר. צריכים רשימה מסוננת או סכום מעוצב? השתמשו ב-$derived. ההבדל המרכזי מ-$effect הוא ש-$derived מיועד לערכים, לא לפעולות.
  • $effect מריץ side effects. חשבו על עדכוני כותרת מסמך (document title), מדידות DOM ידניות, או טיימרים שזקוקים לניקוי (cleanup). הוא רץ אחרי שה-DOM מתבצע (commits), בדומה ל-lifecycle hook אך קשור לתלויות ריאקטיביות ספציפיות.
  • $props מחליף את תבנית ה-export let הישנה לקבלת נתונים בתוך קומפוננטות. זה ברור יותר, וזה מתקשר טוב יותר עם TypeScript.

המודל הזה משתלם בפועל. מכיוון שהקומפיילר עוקב רק אחרי מה שסימנתם, קוד מת (dead code) נשאר מת. אתם מפסיקים לתהות למה משתנה מסוים גרם לעדכון, ומתחילים לסמוך על ההוראות המפורשות שלכם.

ניתוב (Routing) לפי תיקיות, לא לפי קונפיגורציה

SvelteKit משתמשת במערכת הקבצים שלכם לצורך routing. אין קובץ router נפרד שצריך לתחזק. הניחו קובץ +page.svelte בתוך תיקייה, והתיקייה הזו הופכת ל-route חי.

UI משותף עוטף את ה-routes הללו באמצעות +layout.svelte. הניחו אחד בשורש (root), וכל route בן יירש אותו. הניחו אחד עמוק יותר בעץ, ורק אותו חלק יקבל את העטיפה.

לוגיקה בצד השרת נמצאת ב-+page.server.ts. זה רץ לפני שהדף שלכם מרונדר, כך שזה המקום שבו אתם מבצעים שאילתות למסד נתונים, מאמתים cookie, או דוחים משתמש לא מחובר. הטיפוסים (types) זורמים אוטומטית מפונקציית ה-load שלכם אל קומפוננטת הדף, מה שאומר שהנתונים שלכם הם עם טיפוסים (typed) מבלי שתצטרכו לכתוב interfaces ידנית.

נקודות קצה (endpoints) של API גולמיות הולכות לקבצי +server.ts. אלו מייצאים standard HTTP handlers—GET, POST, PUT, DELETE—כך שבניית back end מסוג REST לצד הדפים שלכם מרגישה טבעית.

תכונה אחת שאינה זוכה להערכה מספקת: group routes. על ידי עטיפת שם תיקייה בסוגריים, כמו (auth), אתם יוצרים layout משותף מבלי להוסיף segment ל-URL. זה מושלם עבור דפי התחברות והרשמה שזקוקים לאותה מעטפת מינימליסטית אך חיים בכתובות /login ו-/signup, ולא ב-/auth/login.

נתונים, אבטחה ו-progressive enhancement

frameworks מודרניים אוהבים לדבר על full-stack, אבל רבים משאירים אתכם לנחש איפה לשים בדיקות אימות או לוגיקת טפסים. SvelteKit נותנת לכם hooks ברורים.

השתמשו ב-+page.server.ts עבור שליפת נתונים (data fetching). פונקציית ה-load שם רצה אך ורק בשרת, כך שפרטי הגישה למסד הנתונים שלכם לעולם לא ידלפו לדפדפן. SvelteKit מייצרת טיפוסים מערכי ההחזרה של ה-load, כך שה-frontend שלכם נשאר עקבי.

השתמשו ב-hooks.server.ts כדי לשלוט על האפליקציה כולה. זה רץ על כל בקשה, מה שהופך את זה למקום הנכון לאימות sessions, בדיקת תוקף JWT, או הצמדת הקשר משתמש (user context) לאירועים נכנסים.

עבור שינויים בנתונים (mutations), השתמשו ב-form actions. במקום לחבר endpoint נפרד של API ולטפל ב-JSON, אתם מגדירים action בתוך +page.server.ts. היופי כאן הוא ה-progressive enhancement. אם ה-JavaScript נכשל בטעינה—או אם משתמש ביטל אותו—הטופס עדיין נשלח ל-server action והדף מרונדר מחדש עם התוצאה. אם ה-JavaScript קיים, SvelteKit משפרת את החוויה מבלי לבצע טעינה מלאה. אתם מקבלים עמידות וגימור מקצועי מאותו קוד.

כלל אחד שכדאי לזכור: בצעו את החישובים ב-$derived, לא ב-$effect. שימוש ב-$effect כדי לחשב ערכים עלול להפעיל לולאות עדכון שקשה לעקוב אחריהן. שמרו את $effect עבור side effects אמיתיים, ותנו ל-$derived לנהל את ה-computed state שלכם.

SvelteKit לעומת Next.js

שתי המסגרות יכולות להוציא אפליקציות לסביבת ייצור, אך ישנן פשרות ממשיות.

גודל ה-Bundle מועד לטובת SvelteKit. מכיוון ש-Svelte מקמפל רכיבים ל-vanilla JavaScript ומדלג לחלוטין על ה-Virtual DOM, טביעת הרגל בזמן ריצה נשארת קטנה. Next.js נושא עמו את מנוע ה-reconciliation של React.

גם ה-Reactivity שונה. SvelteKit פותר runes בזמן קומפילציה. הדפדפן מקבל עדכונים פשוטים. Next.js מסתמך על ה-runtime hooks וה-reconciliation של React, מה שאומר שחלק גדול יותר של עבודה מתבצע בצד הלקוח.

תהליך ה-Onboarding קל יותר עם SvelteKit. המודל המנטלי קטן יותר. אינך צריך להתמודד עם מערכי תלות (dependency arrays) של useEffect או חידות של memoization כדי להימנע מ-re-renders. גם האינטגרציה עם TypeScript ראויה לציון. בעוד ששתי המסגרות