מעבר ל-React — Next.js, Astro, Vite ו-SvelteKit

למה צריך משהו מעבר ל-React

בפרק הקודם למדנו ש-React הוא ספרייה לבניית UI — קומפוננטות, props, state. אבל React לבד הוא כמו מנוע שמונח על השולחן. הוא חזק, אבל בלי מכונית מסביבו — אי אפשר לנסוע לשום מקום.

ספציפית, React לבד לא יודע לעשות את הדברים הבאים שכל אתר אמיתי צריך:

• Routing — לעבור בין דפים (מ-/home ל-/about). React לא יודע מה זה "דף" — הוא רואה הכל כקומפוננטה אחת
• SSR/SSG — לרנדר בצד השרת בשביל SEO ומהירות. React בברירת מחדל רץ רק בדפדפן
• API handling — לטפל בבקשות מהשרת (טפסים, בסיסי נתונים, authentication). React הוא frontend בלבד
• Build optimization — לדחוס תמונות, לפצל קוד, לשלוח רק מה שצריך. React לא מנהל את ה-build process
• Deployment — להעלות את האתר לשרת. React לא יודע כלום על hosting

בשביל כל אלה, צריך framework — שכבה שיושבת מעל React ומוסיפה את כל מה שחסר. חשבו על זה ככה: React הוא המנוע, ו-Next.js (או Astro, או SvelteKit) הוא המכונית השלמה — עם הגה, גלגלים, מערכת ניווט, וגגון.

אם אתם זוכרים מפרק 1, דיברנו על ההבדל בין library (כמו React — עושה דבר אחד טוב) ל-framework (כמו Next.js — מנהל את כל המבנה). עכשיו נראה בדיוק מה כל framework מוסיף, ומתי לבחור כל אחד.

הנקודה הקריטית: כשאתם עובדים עם AI tools כמו V0, Bolt או Lovable — הם תמיד משתמשים ב-framework, לא ב-React בודד. לכן, להבין איזה framework הם בחרו ולמה — זה ההבדל בין לקבל מה שאתם רוצים לבין לקבל מה שAI החליט בשבילכם.

סיפור מהשטח: מפתחת ישראלית ב-Vibe Coding בנתה אתר portfolio עם React טהור (בלי framework). הכל עבד — אבל Google לא הצליח לאנדקס את האתר כי הוא רץ ב-JavaScript בלבד (CSR). היא הוסיפה Next.js ושעתיים אחר כך האתר כבר הופיע בגוגל. הלקח: React בלי framework = בעיית SEO כמעט תמיד.

וזה מביא אותנו לשאלה המרכזית של הפרק הזה: איזו מכונית לבחור? כי יש כמה אפשרויות, וכל אחת מתאימה לסוג שונה של נסיעה.

Next.js — ה-Framework המלא

Next.js הוא ה-framework הכי פופולרי בעולם ה-React. הוא נבנה על ידי חברת Vercel — אותה חברה שמפעילה את V0, את Turbopack, ואת פלטפורמת ה-hosting הפופולרית ביותר לפרויקטי React. הוא מוסיף על React את כל מה שחסר: routing, SSR, API routes, image optimization, ועוד הרבה.

נכון לאפריל 2026, הגרסה האחרונה היא Next.js 16.2 — אבל הקונספטים שנלמד כאן יציבים ורלוונטיים לכל גרסה מ-13 ומעלה. חשוב לדעת: כש-AI מייצר קוד Next.js, הוא לפעמים מייצר קוד מגרסה ישנה יותר (Pages Router). תמיד ציינו בפרומפט: "Use Next.js App Router".

בשוק הישראלי, Next.js שולט: רוב הסטארטאפים הישראליים (מ-fintech ועד healthtech) משתמשים בו. אם אתם מחפשים עבודה בהייטק הישראלי — Next.js הוא ה-framework שכולם מצפים שתכירו.

App Router — ניווט מבוסס תיקיות

הרעיון המרכזי של Next.js הוא file-based routing — מבנה הקבצים קובע את כתובות ה-URL. זה עובד ככה:

app/
├── page.tsx          → אתר.com/
├── about/
│   └── page.tsx      → אתר.com/about
├── blog/
│   ├── page.tsx      → אתר.com/blog
│   └── [slug]/
│       └── page.tsx  → אתר.com/blog/any-post-name
└── layout.tsx        → עיצוב שעוטף כל דף

זה קסום בפשטות שלו: אין צורך להגדיר routing בקוד. יצרתם תיקייה? יש לכם דף חדש ב-URL. שמתם [slug] בסוגריים מרובעים? יש לכם דף דינמי שיכול לטעון תוכן שונה לפי הכתובת. הקובץ layout.tsx עוטף את כל מה שמתחתיו — כמו תבנית שחוזרת בכל דף (navigation bar, footer).

למה זה חשוב כשעובדים עם AI? כי כשאתם אומרים ל-AI "add an about page" — הוא יודע בדיוק מה לעשות: ליצור תיקייה app/about/ עם קובץ page.tsx בתוכה. אין הגדרות מסובכות, אין קבצי route configuration. פשוט תיקייה = דף.

טיפ מעשי: כשאתם קוראים קוד שAI ייצר ב-Next.js — תסתכלו קודם כל על מבנה התיקיות. הוא יגיד לכם בדיוק מה הדפים באתר, בלי לקרוא שורת קוד אחת.

קבצים מיוחדים ב-App Router

מלבד page.tsx ו-layout.tsx, ה-App Router מזהה עוד קבצים מיוחדים שכל אחד עושה משהו אחר:

למה זה חשוב? כשAI מייצר פרויקט Next.js, הוא לפעמים מוסיף קבצים כמו loading.tsx או error.tsx. אם אתם רואים אותם בקוד — עכשיו אתם יודעים מה הם עושים. ואם AI לא הוסיף אותם — אתם יכולים לבקש: "Add a loading.tsx with a skeleton UI for the blog page".

Route Groups — ארגון בלי השפעה על URL

פיצ'ר שימושי שAI לפעמים משתמש בו: תיקייה עם סוגריים עגולים, כמו (marketing), מארגנת קבצים בלי להשפיע על ה-URL:

app/
├── (marketing)/
│   ├── page.tsx      → אתר.com/     (לא /marketing!)
│   ├── about/
│   │   └── page.tsx  → אתר.com/about
│   └── layout.tsx    → layout רק לדפי marketing
├── (dashboard)/
│   ├── settings/
│   │   └── page.tsx  → אתר.com/settings
│   └── layout.tsx    → layout אחר לדפי dashboard

זה מאפשר לכל חלק באתר לקבל layout שונה — אתר שיווקי עם עיצוב אחד, ודשבורד עם עיצוב אחר — בלי שה-URL משתנה. טיפ: אם אתם רואים סוגריים עגולים במבנה קבצים ש-AI ייצר — זה route group.

Server Components — קוד שרץ בשרת בלבד

זוכרים את Server Components מפרק 2? ב-Next.js הם ברירת המחדל. כל קומפוננטה היא server component אלא אם ציינתם אחרת:

// Server Component (ברירת מחדל) — לא שולח JS לדפדפן
async function BlogPage() {
  const posts = await fetch('https://api.example.com/posts');
  return <PostList posts={posts} />;
}

// Client Component — צריך להוסיף 'use client' בראש הקובץ
'use client';
function LikeButton() {
  const [liked, setLiked] = useState(false);
  return <button onClick={() => setLiked(true)}>❤️</button>;
}

הכלל פשוט: אם הקומפוננטה צריכה אינטראקטיביות (לחיצה, קלט, אנימציה) — היא client component עם 'use client' בראש הקובץ. אם לא — היא server component שלא שולחת JavaScript לדפדפן. זה אומר שרוב האתר שלכם (header, footer, תוכן סטטי, רשימת מוצרים) לא שולח שום JavaScript — רק HTML מוכן. רק החלקים שבאמת צריכים אינטראקציה (כפתור like, טופס, toggle) שולחים JS.

למה זה חשוב? כי זה מקטין דרמטית את כמות ה-JavaScript שנשלחת לדפדפן. פחות JS = דף מהיר יותר = חוויית משתמש טובה יותר = SEO טוב יותר. זו הסיבה שNext.js 15+ הפך את Server Components לברירת מחדל.

כשקוראים קוד Next.js שAI כתב: אם אתם רואים 'use client' בראש הקובץ — זו קומפוננטה שרצה בדפדפן. אם אין את זה — היא רצה בשרת. רוב הקומפוננטות (70-80%) צריכות להיות server components. אם AI שם 'use client' בכל מקום — זה סימן שהוא לא מנצל את הארכיטקטורה כמו שצריך.

הדפוס הנכון: Server Component שמכיל Client Component

הגישה הנכונה ב-Next.js היא ליצור היררכיה: הקומפוננטה החיצונית היא server component שמושכת נתונים ומכילה בתוכה client components קטנים רק איפה שצריך אינטראקטיביות:

// app/products/page.tsx — Server Component (ברירת מחדל)
// שימו לב: אין 'use client' — זה רץ בשרת בלבד
async function ProductsPage() {
  // מושך נתונים מהשרת — לא שולח את הקוד הזה לדפדפן!
  const products = await db.getProducts();

  return (
    <div>
      <h1>המוצרים שלנו</h1>
      {products.map(p => (
        <ProductCard key={p.id} product={p}>
          {/* AddToCart הוא client component — רק הוא שולח JS */}
          <AddToCartButton productId={p.id} price={p.price} />
        </ProductCard>
      ))}
    </div>
  );
}

// components/AddToCartButton.tsx — Client Component
'use client';
import { useState } from 'react';

function AddToCartButton({ productId, price }) {
  const [added, setAdded] = useState(false);
  return (
    <button onClick={() => setAdded(true)}>
      {added ? '✓ נוסף לעגלה' : `הוסף לעגלה — ₪${price}`}
    </button>
  );
}

שימו לב לדוגמה: כל הרשימה של המוצרים רצה בשרת — שום JavaScript לא נשלח לדפדפן בשבילה. רק כפתור "הוסף לעגלה" הוא client component, כי הוא צריך onClick ו-useState. התוצאה: דף מהיר יותר עם פחות JavaScript.

טעות נפוצה של AI: הרבה פעמים AI שם 'use client' על כל הדף — כולל רשימת המוצרים, התמונות, הכותרות. אם אתם רואים את זה, בקשו: "Split this into a server component that fetches data, with small client components only for interactive parts".

עוד יכולות מרכזיות של Next.js

API Routes — backend בתוך הפרויקט

אחד הפיצ'רים החזקים של Next.js הוא API Routes — היכולת לבנות endpoints בצד השרת בתוך אותו פרויקט. במקום להקים שרת Express.js נפרד, פשוט יוצרים קובץ בתיקייה app/api/:

// app/api/contact/route.ts — API endpoint
// מטפל בטופס יצירת קשר
export async function POST(request: Request) {
  const data = await request.json();
  const { name, email, message } = data;

  // שולח מייל (או שומר בDB)
  await sendEmail({
    to: 'info@mysite.co.il',
    subject: `פנייה חדשה מ-${name}`,
    body: message,
  });

  return Response.json({ success: true });
}
// URL: אתר.com/api/contact (POST request)

למה זה חשוב? כי Vibe Coders לא צריכים ללמוד backend נפרד. אומרים ל-AI: "Add an API route that receives a contact form and sends an email" — והוא יוצר את הקובץ הנכון בתיקייה הנכונה. זה עובד במיוחד טוב עם שירותים ישראליים כמו SendGrid (שיש לו שרתים באירופה, קרוב לישראל) או Resend.

Middleware — שומר הסף

Middleware הוא קוד שרץ לפני כל בקשה — לפני שהדף נטען, לפני שה-API מגיב. חשבו על שומר בכניסה למועדון: הוא בודק מי אתם לפני שנכנסים.

// middleware.ts — בשורש הפרויקט (לא בתיקייה!)
import { NextResponse } from 'next/server';

export function middleware(request) {
  // בדיקה: האם המשתמש מחובר?
  const token = request.cookies.get('auth-token');

  if (!token && request.nextUrl.pathname.startsWith('/dashboard')) {
    // לא מחובר + מנסה להיכנס לדשבורד = הפניה ל-login
    return NextResponse.redirect(new URL('/login', request.url));
  }

  return NextResponse.next(); // הכל בסדר — תמשיך
}

// הגדרה: על אילו נתיבים ה-middleware רץ
export const config = {
  matcher: ['/dashboard/:path*', '/settings/:path*'],
};

שימושים נפוצים של Middleware:

• Authentication — חסימת דפים למשתמשים לא מחוברים (הדוגמה למעלה)
• Redirects — הפניית /old-page ל-/new-page אוטומטית
• שפה (i18n) — זיהוי שפת המשתמש והפניה ל-/he/ או /en/
• A/B Testing — שליחת חלק מהמשתמשים לגרסה א' וחלק לגרסה ב'
• Geolocation — זיהוי שהמשתמש מישראל והצגת מחירים ב-₪

טיפ לעבודה עם AI: אם אתם בונים אתר שצריך authentication (למשל דשבורד ללקוחות), בקשו מ-AI: "Add middleware that protects /dashboard routes — redirect to /login if no auth token". AI מכיר את הפורמט ויצור middleware.ts נכון.

Next.js בשוק הישראלי — מי משתמש ובמה

בהייטק הישראלי, Next.js הוא ברירת המחדל. הנה כמה דוגמאות:

• סטארטאפי fintech (כמו Melio, Lemonade) — דשבורדים מורכבים עם real-time data, authentication, ו-API routes
• חברות e-commerce — חנויות עם SSR בשביל SEO ו-ISR בשביל עדכוני מחירים. מחירים ב-₪, תמיכה ב-RTL
• חברות SaaS (Monday.com, Wix, Elementor) — אפליקציות ענן מורכבות שצריכות server components וperformance
• סוכנויות digital ישראליות — רוב הסוכנויות בתל אביב והרצליה בונות landing pages ו-microsites עם Next.js + Vercel

אם אתם מחפשים עבודה בהייטק הישראלי — מספיק לחפש "Next.js" ב-LinkedIn Israel או ב-All Jobs כדי לראות מאות משרות. ידע ב-Next.js הוא יתרון מובהק, גם אם אתם לא מפתחים "קלאסיים" אלא Vibe Coders שמנחים AI.

בשורה התחתונה: Next.js הוא ה-framework ה"שלם" ביותר — כמו שוויצרי. הוא עושה הכל, ורוב כלי ה-AI יודעים לעבוד איתו מעולה.

למה V0, Bolt ו-Lovable בוחרים Next.js

אם ניסיתם את התרגיל הקודם — כנראה שמתם לב: כמעט כל כלי AI בוחר Next.js כברירת מחדל. זה לא מקרי. יש 3 סיבות:

1. Training Data — הנתונים שהם למדו מהם. רוב הקוד באינטרנט (GitHub, Stack Overflow, בלוגים) הוא React + Next.js. כש-AI למד לכתוב קוד — הוא למד בעיקר Next.js. אז כשלא מציינים framework, הוא חוזר למה שהוא מכיר הכי טוב.

2. Ecosystem — האקוסיסטם. V0 הוא של Vercel — אותה חברה שבנתה Next.js. Bolt ו-Lovable בחרו Next.js כי הוא הכי פופולרי ויש לו את הכי הרבה ספריות UI (כמו shadcn/ui). יותר ספריות = יותר דברים שAI יודע לייצר.

3. Full-Stack — פתרון מלא. Next.js נותן frontend + backend + deployment באריזה אחת. ל-AI, זה אידיאלי — הוא יכול לייצר אפליקציה שלמה בלי לשלב כלים נוספים.

4. Vercel = V0 = Next.js — הקשר העסקי. חברת Vercel בנתה את Next.js, את V0, ואת Turbopack. כש-V0 מייצר קוד — הוא מייצר Next.js שעובד מושלם ב-Vercel. זה לא קונספירציה — זה מודל עסקי חכם. V0 מייצר פרויקטים שקל ל-deploy ב-Vercel (ומשלמים עבור hosting). חשוב לדעת את זה כי זה מסביר למה V0 לעולם לא ייצר Astro + Cloudflare Pages כברירת מחדל.

מה זה אומר ל-Vibe Coders? כלי AI הם מצוינים — אבל הם לא ניטרליים. V0 מעדיף Next.js + Vercel. Bolt ו-Lovable מעדיפים מה שעובד הכי טוב עם ה-infrastructure שלהם. אם אתם רוצים Astro + Cloudflare — תצטרכו לבקש את זה במפורש, או לעבוד עם Claude Code / Cursor שלא מחויבים לshל framework ספציפי.

Astro — אפס JavaScript כברירת מחדל

אם Next.js הוא ה"סכין השוויצרי" — Astro הוא ה"כתב יד מושלם": מהיר, נקי, ושולח רק מה שבאמת צריך.

הרעיון המרכזי: Astro לא שולח JavaScript לדפדפן כברירת מחדל. כלום. אפס. הוא בונה HTML סטטי, ורק כשאתם אומרים במפורש "הקומפוננטה הזו צריכה אינטראקטיביות" — הוא מוסיף JavaScript רק לה.

Islands Architecture — אדריכלות האיים

תארו לעצמכם דף אינטרנט כים של HTML סטטי. ברוב הדף אין צורך ב-JavaScript — טקסט, תמונות, כותרות. אבל יש כמה מקומות שצריכים אינטראקטיביות — כפתור "הוסף לעגלה", תפריט נפתח, carousel. אלה האיים.

כל "אי" נטען בנפרד. תפריט כבד בתחתית הדף? לא חוסם את ה-header מלהיות אינטראקטיבי. זה ההבדל הגדול מ-Next.js, שם כל ה-JavaScript נטען כיחידה אחת.

איך Islands עובדים בקוד

ב-Astro, כל קומפוננטה היא סטטית כברירת מחדל. כדי להפוך קומפוננטה ל"אי" אינטראקטיבי, מוסיפים directive — הוראה שאומרת מתי לטעון את ה-JavaScript:

<!-- קומפוננטה סטטית — אפס JavaScript -->
<Header />

<!-- "אי" שנטען מיד כשהדף נפתח -->
<MobileMenu client:load />

<!-- "אי" שנטען רק כשהוא נכנס לview של המשתמש -->
<ImageCarousel client:visible />

<!-- "אי" שנטען רק כשהדפדפן idle (לא עסוק) -->
<Newsletter client:idle />

<!-- "אי" שנטען רק במסך רחב (desktop) -->
<SidebarWidget client:media="(min-width: 768px)" />

שימו לב ל-4 סוגי directives — כל אחד קובע מתי ה-JavaScript נטען:

למה זה כל כך חזק? כי במקום לטעון 180KB של JavaScript מיד — טוענים רק מה שצריך, רק מתי שצריך. משתמש עם 3G איטי בישראל (למשל באזורי קצה ברמת הגולן)? הדף ייטען מהר כי הוא HTML בלבד — ורק כשהמשתמש גולל למטה, נטענים ה"איים" הרלוונטיים.

המספרים מדברים

Multi-Framework — שימוש בכמה ספריות באותו פרויקט

יתרון ייחודי של Astro: אפשר להשתמש ב-React, Vue, Svelte, ו-Solid באותו פרויקט. יש לכם קומפוננטת React מוכנה? שימו אותה ב-Astro בתור "אי". יש לכם חלק ב-Svelte? גם הוא עובד. זה נקרא framework agnostic.

Content Collections — ניהול תוכן חכם

Content Collections הם הפיצ'ר שהופך את Astro לאידיאלי לאתרי תוכן. כותבים בלוג פוסט ב-Markdown? Astro יודע לקרוא אותו, לתת לו type safety (לוודא שיש כותרת, תאריך, תמונה), ולהפוך אותו לדף HTML מהיר.

ככה זה נראה בפועל:

// src/content/config.ts — הגדרת ה-collection
import { defineCollection, z } from 'astro:content';

const blog = defineCollection({
  schema: z.object({
    title: z.string(),           // חובה — שם הפוסט
    date: z.date(),              // חובה — תאריך פרסום
    author: z.string(),          // חובה — שם הכותב
    image: z.string().optional(), // רשות — תמונה ראשית
    tags: z.array(z.string()),   // חובה — תגיות
    draft: z.boolean().default(false), // טיוטה?
  }),
});

// src/content/blog/my-first-post.md
// ---
// title: "איך בניתי אתר ב-10 דקות עם AI"
// date: 2026-04-10
// author: "דנה כהן"
// tags: ["vibe-coding", "AI", "astro"]
// ---
// תוכן הפוסט כאן ב-Markdown...

מה קורה כאן? Astro מגדיר סכמה (schema) — רשימה של שדות שכל פוסט חייב להכיל. אם יצרתם פוסט בלי כותרת — Astro יתריע על שגיאה בזמן build, לא אחרי שהאתר כבר באוויר. זה נקרא type safety לתוכן.

למה זה מושלם לAI? אומרים ל-AI: "Create an Astro blog with content collections — each post needs title, date, author, tags, and an optional hero image" — והוא ייצר את כל המבנה הנכון. פשוט כותבים פוסטים ב-Markdown ו-Astro דואג לשאר.

דוגמה מהשוק הישראלי: בלוג טכני של סטארטאפ ישראלי עם 200+ פוסטים — Content Collections מאפשרות ניהול מסודר עם תגיות בעברית, תאריכים, ו-draft mode לפוסטים שעדיין בעבודה. ה-build time של 200 פוסטים: פחות מ-10 שניות.

Cloudflare + Astro — מה הרכישה אומרת

בינואר 2026, Cloudflare רכשה את צוות Astro. זו עסקה משמעותית שכדאי להבין למה:

Cloudflare היא אחת מחברות התשתית הגדולות באינטרנט — היא מפעילה CDN (רשת שרתים גלובלית), Cloudflare Workers (שרת edge), ו-Cloudflare Pages (hosting). היא משרתת כ-20% מכל התעבורה באינטרנט.

מה המשמעות?

• Astro נשאר open source — הקוד פתוח, אפשר להשתמש בו בכל מקום
• Astro 6 (בפיתוח) — שרת הפיתוח עובר ל-workerd, אותו runtime שרץ ב-production ב-Cloudflare Workers. זה אומר: מה שעובד בפיתוח = מה שעובד ב-production
• אינטגרציה עמוקה — Cloudflare Pages כבר היום ה-hosting המומלץ ל-Astro, והרכישה תעמיק את זה
• חברות גדולות כמו Webflow ו-Wix כבר בונות על Astro + Cloudflare

למה זה רלוונטי לישראל? Cloudflare מאוד פופולרית בסטארטאפים ישראליים — Workers, Pages, ו-R2 Storage נמצאים בשימוש נרחב. הרכישה של Astro אומרת שאתרי תוכן על Cloudflare ייהנו מאינטגרציה חזקה עוד יותר.

מה המשמעות המעשית ל-Vibe Coders

הרכישה של Astro על ידי Cloudflare משפיעה על ההחלטות שלכם בכמה דרכים:

• Hosting חינמי ומהיר — Cloudflare Pages נותן hosting חינמי (עד 500 builds בחודש) עם CDN גלובלי. ל-Astro sites זה אידיאלי — אתר סטטי שרץ על edge servers קרובים למשתמשים בישראל
• Dev = Production — ב-Astro 6 (בפיתוח), שרת הפיתוח המקומי ישתמש באותו runtime כמו Cloudflare Workers. מה שעובד אצלכם על הלפטופ — מובטח שיעבוד ב-production
• Serverless functions — אם צריכים backend logic (טופס יצירת קשר, API), אפשר להשתמש ב-Cloudflare Workers ישירות מתוך פרויקט Astro — בלי שרת נפרד
• R2 Storage — אחסון תמונות וקבצים ב-Cloudflare R2 (תואם S3, זול יותר מ-AWS) — אינטגרציה טבעית עם Astro

בשביל Vibe Coders ישראלים: Cloudflare Pages + Astro = הדרך הכי זולה והכי מהירה לבנות אתר תוכן. התמחור הוא free tier נדיב מאוד, ה-CDN קרוב לישראל (יש נקודת נוכחות בתל אביב), וה-deploy פשוט כמו git push.

Astro vs Next.js — מתי כל אחד

זו אחת השאלות הכי חשובות שתצטרכו לענות עליה כ-Vibe Coders. הנה הכלל הפשוט:

דוגמאות מייצגות מהשוק הישראלי:

• סטארטאפ SaaS (דשבורד + login + API) → Next.js
• אתר תוכן לעסק קטן בתל אביב → Astro
• פורטפוליו אישי של מפתח/ת → Astro
• פלטפורמת e-commerce עם עגלת קניות → Next.js
• בלוג טכני עם 500+ פוסטים → Astro (Content Collections מושלם)
• אפליקציית fintech עם עדכונים real-time → Next.js

Frameworks בשוק הישראלי — תמונת מצב 2026

אם אתם עובדים בשוק הישראלי, חשוב להבין את התפלגות השימוש:

מגמה מעניינת: סוכנויות digital ישראליות מתחילות להשתמש ב-Astro לאתרי לקוחות — במיוחד landing pages שצריכים Lighthouse score מושלם. הלקוח שמח (האתר מהיר), Google שמח (Core Web Vitals ירוקים), והסוכנות שמחה (פחות תחזוקה). מחיר hosting: 0 ₪ על Cloudflare Pages free tier.

Vite — כלי הבנייה שמאחורי הקלעים

עד עכשיו דיברנו על frameworks — Next.js ו-Astro. עכשיו נדבר על שכבה אחרת לגמרי: build tools — כלי הבנייה.

Vite (נקרא "ויט", מצרפתית — "מהיר") הוא כלי בנייה שנוצר על ידי Evan You (היוצר של Vue). הוא לא מתחרה ב-Next.js — הוא רץ מתחת ל-frameworks. חשבו על זה ככה:

מה Vite עושה?

HMR — למה Vite "מרגיש מהיר"

HMR (Hot Module Replacement) הוא הפיצ'ר שגורם ל-Vite להרגיש כמו קסם. ככה זה עובד:

1. אתם משנים קובץ CSS — למשל, מחליפים צבע כפתור מכחול לסגול
2. Vite מזהה את השינוי תוך מילישניות
3. במקום לטעון מחדש את כל הדף (כמו refresh), הוא מחליף רק את המודול שהשתנה
4. הכפתור משנה צבע בדפדפן — בלי לאבד state, בלי scroll position שמשתנה, בלי הבהוב

ההבדל מ-Webpack (הכלי הישן): Webpack היה צריך לרכיב מחדש את כל הפרויקט בכל שינוי — פרויקט גדול = 5-15 שניות המתנה. Vite משתמש ב-native ES modules של הדפדפן, אז הוא מעדכן רק את מה שהשתנה — תמיד מהיר, גם בפרויקטים ענקיים.

מה זה אומר בפועל? כש-AI מייצר קוד ואתם רוצים לעשות שינוי קטן (שנו צבע, שנו טקסט, הזיזו אלמנט) — הדפדפן מתעדכן מיד. אין המתנה. זו חוויית פיתוח שפשוט מרגישה טוב.

איפה Vite רץ מאחורי הקלעים? הוא ה-build tool של Astro, SvelteKit, ו-Remix. גם Lovable משתמשת ב-Vite. Next.js הוא היוצא מן הכלל — הוא משתמש ב-Turbopack (של Vercel, כתוב ב-Rust). Turbopack מתחרה ב-Vite על תואר "ה-build tool המהיר ביותר".

React + Vite בלבד — מתי זה מספיק?

אפשר לבנות פרויקט React עם Vite בלי framework בכלל. הפקודה npm create vite@latest my-app -- --template react-ts נותנת לכם פרויקט React טהור עם TypeScript. השאלה היא: מתי זה מספיק?

מתי להשתמש ב-Vite ישירות (בלי framework)?

טיפ: Lovable משתמשת ב-Vite + React (לא Next.js). זו הסיבה שהפלט שלה קצת שונה מ-V0. אם אתם משתמשים ב-Lovable — שימו לב שאין לכם App Router, אין server components, ואין API routes. זה React טהור.

Vite בתוך frameworks: שימו לב שגם כשאתם משתמשים ב-Astro או SvelteKit — Vite רץ מתחת. הם בנויים על Vite. זה אומר שתמיד תיהנו מ-HMR מהיר ו-dev experience מצוין. ההבדל הוא שב-Astro ו-SvelteKit אתם מקבלים גם routing, SSR, ועוד — דברים ש-Vite לבד לא נותן. אם פתחתם את package.json של פרויקט Astro ומצאתם שם "vite" — זה לא טעות. Astro משתמש ב-Vite כ-build engine שלו.

מתי Vite+React עדיף על Next.js? כשאתם לא צריכים SSR, SEO, או server logic. למשל: דשבורד admin פנימי שרק עובדים ניגשים אליו (לא צריך SEO), כלי תמחור פנימי (לא צריך להיות ב-Google), או prototype שצריך לעבוד "עכשיו" בלי כל ה-overhead של framework מלא. מחיר ה-hosting: כמעט 0 — שמים את ה-build על Cloudflare Pages או GitHub Pages ומסיימים.

SvelteKit — האלטרנטיבה שגדלה

כל מה שדיברנו עליו עד עכשיו — Next.js, Astro — בנוי על React (או לפחות תומך בו). אבל יש עולם אחר: Svelte.

Svelte (נקרא "סוולט") הוא לא framework ב-React — הוא שפה אחרת לגמרי שמתקמפלת ל-vanilla JavaScript. בלי Virtual DOM, בלי runtime. SvelteKit הוא ה-framework המלא שבנוי מעל Svelte — כמו ש-Next.js בנוי מעל React.

מה ההבדל מ-React?

בואו נשווה את אותו counter פשוט:

// React — 12 שורות
import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      Clicked {count} times
    </button>
  );
}

<!-- Svelte — 5 שורות -->
<script>
  let count = 0;
</script>

<button on:click={() => count++}>
  Clicked {count} times
</button>

שימו לב: ב-Svelte אין צורך ב-useState, אין import, אין function wrapper. פשוט כותבים let count = 0 ו-Svelte מבין שזה state. פחות קוד = פחות מקום לבאגים.

Svelte — עוד השוואות מעשיות

בואו נראה עוד דוגמה — fetch data והצגה ברשימה:

<!-- Svelte: fetch + display -->
<script>
  let products = [];

  async function loadProducts() {
    const res = await fetch('/api/products');
    products = await res.json();
  }

  // נטען אוטומטית כשהקומפוננטה נטענת
  loadProducts();
</script>

{#each products as product}
  <div class="card">
    <h3>{product.name}</h3>
    <p>₪{product.price}</p>
  </div>
{/each}

ב-React אותו קוד דורש useState, useEffect, ו-cleanup function. ב-Svelte — פשוט כותבים מה שרוצים והוא עובד. הסינטקס {#each} הוא הדרך של Svelte לעשות loops, ו-{#if} לתנאים.

SvelteKit — מה הוא מוסיף

SvelteKit מוסיף ל-Svelte את כל מה שNext.js מוסיף ל-React:

• File-based routing — כמו ב-Next.js, מבנה התיקיות קובע את ה-URL (תיקייה src/routes/about/ = URL /about)
• SSR + SSG — רינדור בצד השרת או יצירת HTML סטטי, לפי הצורך
• Server-side data loading — קבצי +page.server.ts שטוענים נתונים בשרת לפני שהדף נשלח
• API routes — קבצי +server.ts שמשמשים כ-endpoints
• Adapter system — deploy ל-Cloudflare, Vercel, Netlify, Node.js — עם adapter אחד מתאים

מתי SvelteKit באמת עדיף? כשהביצועים קריטיים. ה-bundle size של SvelteKit קטן ב-50-70% מ-Next.js, כי Svelte מתקמפל ל-vanilla JavaScript בלי runtime. לאפליקציות שמשרתות מיליוני משתמשים — ההבדל מורגש. סטארטאפים ישראליים שמשרתים שוק גלובלי (כמו אפליקציות productivity או fintech) מתחילים לשקול SvelteKit בדיוק בגלל זה.

SvelteKit בצד AI

הנה האמת הכואבת: רוב כלי ה-AI עדיין לא תומכים ב-Svelte ברמה טובה. V0 מייצר React. Bolt יכול לייצר Svelte אבל לא כברירת מחדל. Lovable — React בלבד.

זה אומר שאם אתם עובדים בעיקר עם AI tools — Next.js עדיין הבחירה הבטוחה יותר. אבל SvelteKit שווה להכיר כי:

• Bundle קטן יותר — 20-40KB (לעומת 70KB ב-Next.js)
• ביצועים עדיפים — 1,200 RPS לעומת 850 RPS ב-Next.js (עלייה של 41%)
• צמיחה מהירה — גידול של 300% במשרות בשנה האחרונה
• DX מעולה — Developer Experience פשוט ואינטואיטיבי

SvelteKit בישראל — מצב 2026

בישראל, SvelteKit עדיין נישתי — אבל גדל מהר. כמה דברים שכדאי לדעת:

• משרות: כ-50 משרות SvelteKit בישראל (לעומת 2,000+ ב-Next.js). רוב הביקוש הוא מסטארטאפים קטנים שמעדיפים ביצועים על גודל אקוסיסטם
• קהילה: יש קהילת Svelte ישראלית קטנה אבל פעילה — meetups בתל אביב ובאונליין
• כלי AI: Cursor ו-Claude Code מייצרים Svelte לא רע בכלל — אפילו אם V0 ו-Bolt עדיין מתמקדים ב-React. אם אתם עובדים עם Claude Code, SvelteKit הוא אופציה לגיטימית
• RTL: SvelteKit תומך ב-RTL כמו כל framework — פשוט מוסיפים dir="rtl" ל-HTML. Tailwind CSS עובד באותו אופן

השורה התחתונה: אם אתם Vibe Coders שעובדים בעיקר עם V0 ו-Bolt — תישארו עם Next.js. אם אתם מעדיפים קוד נקי ופשוט, ומוכנים ללמוד סינטקס חדש — SvelteKit שווה התנסות. הוא יהפוך לנפוץ יותר בשנים הקרובות.

Remix — עוד שם ששווה להכיר

Remix היה framework פופולרי לReact, שנבנה על ידי צוות React Router. הסיפור שלו קצת מסובך אבל שווה לדעת בקצרה:

• 2021-2024: Remix היה framework נפרד — מתחרה ישיר של Next.js, עם דגש על web standards וביצועים
• 2024: הצוות הכריז שRemix מתמזג עם React Router v7 — כל מה שהיה ב-Remix נכנס ל-React Router "framework mode"
• 2026: Remix 3 הוכרז — שכתוב מחדש בלי React (עם Preact). זה מוצר שונה לגמרי

מה זה אומר בפועל? אם אתם רואים קוד עם Remix — הוא כנראה React Router v7 מאחורי הקלעים. אם מישהו מזכיר Remix 3 — זה כבר לא React בכלל. לא צריך להתעמק — מספיק לדעת שזה קיים.

למה בכל זאת להכיר? מפתחים ותיקים שעובדים בהייטק הישראלי יכולים לדבר על Remix בראיונות עבודה או ב-code reviews. הם כנראה מתכוונים ל-React Router v7 עם "framework mode". אם שומעים "Remix" — אל תיבהלו. זה עוד דרך לבנות אתרי React, עם דגש על web standards (טפסים שעובדים בלי JavaScript, progressive enhancement) ו-nested routing (כל חלק בדף יכול לטעון את הנתונים שלו בנפרד).

בפועל: אם AI מייצר Remix — בקשו: "Use Next.js App Router instead of Remix". אלא אם כן יש לכם סיבה ספציפית להשתמש ב-Remix.

הנחיה ל-AI: איך לציין framework בפרומפט

עכשיו שאתם מכירים את ה-frameworks — בואו נלמד איך להגיד ל-AI באיזה framework להשתמש. זה ההבדל בין לקבל מה שAI בוחר בשבילכם — לבין לקבל בדיוק מה שאתם צריכים.

הפרומפט הגרוע

"Build me a blog website"

מה AI ייצר? כנראה Next.js עם 70KB+ של JavaScript — אפילו שבלוג לא צריך את זה.

הפרומפט הטוב

"Build a blog website using Astro 5 with:
- Content Collections for blog posts (Markdown)
- Tailwind CSS for styling
- File-based routing
- Zero JavaScript except for a mobile menu toggle
- Deploy target: Cloudflare Pages
- RTL support for Hebrew content"

שימו לב מה השתנה: ציינו framework, גרסה, ספריית CSS, סוג ה-routing, כמה JavaScript, ואיפה ה-deploy. AI מקבל הנחיות ברורות ומייצר בדיוק מה שצריך.

תבנית Prompt לבחירת Framework

Build a [סוג האתר] using [Framework] [גרסה] with:
- [ספריית CSS]: Tailwind / CSS Modules / vanilla
- [Routing]: file-based / dynamic / API routes
- [Rendering]: SSR / SSG / static / islands
- [Features]: authentication / CMS / i18n / RTL
- [Deploy]: Vercel / Cloudflare / Netlify
- [Language]: TypeScript / JavaScript

5 תבניות Prompt מוכנות — העתיקו והתאימו

הנה תבניות מוכנות לכל framework — פשוט החליפו את מה שבסוגריים:

תבנית 1: Next.js — אפליקציית SaaS

"Build a [SaaS dashboard / CRM / project management tool] using Next.js 16 App Router with:
- TypeScript
- Tailwind CSS + shadcn/ui for components
- Server Components for data display, Client Components only for interactive parts
- API routes in app/api/ for backend logic
- Middleware for authentication (redirect unauthenticated users to /login)
- ISR for pages that update periodically
- RTL support with dir='rtl' for Hebrew interface
- Deploy target: Vercel"

תבנית 2: Astro — אתר תוכן/בלוג

"Build a [blog / documentation site / portfolio] using Astro 5 with:
- Content Collections for [blog posts / docs pages] in Markdown
- Tailwind CSS for styling
- Zero client-side JavaScript except for [mobile menu / search / newsletter form]
- Use client:visible for below-fold interactive components
- RSS feed
- Sitemap generation
- RTL support for Hebrew content
- Deploy target: Cloudflare Pages"

תבנית 3: Astro + React — אתר שיווקי עם חלקים אינטראקטיביים

"Build a [marketing website / landing page] using Astro 5 with React islands:
- Static HTML for all content sections (hero, features, testimonials, footer)
- React components only for: [pricing calculator / contact form / demo booking]
- Use client:visible for React components below the fold
- Tailwind CSS
- Mobile-first responsive design
- Hebrew RTL with prices in ₪
- Deploy target: Cloudflare Pages"

תבנית 4: Vite + React — כלי פנימי / Prototype

"Build a [admin dashboard / internal tool / prototype] using Vite + React with:
- TypeScript
- React Router for client-side navigation
- Tailwind CSS
- No SSR needed (SPA only)
- Mock data for development
- Hebrew interface with RTL"

תבנית 5: SvelteKit — אפליקציה עם ביצועים קריטיים

"Build a [real-time app / high-performance tool] using SvelteKit with:
- TypeScript
- Server-side data loading with +page.server.ts
- Tailwind CSS
- File-based routing
- API endpoints with +server.ts
- Deploy target: Cloudflare Pages with adapter-cloudflare"

טיפ מתקדם — תוספת RTL: כשאתם בונים אתר בעברית, תמיד הוסיפו לפרומפט: "Hebrew RTL with dir='rtl' on html tag. Use logical CSS properties (margin-inline-start instead of margin-left). Prices in ₪ (NIS). Date format: DD/MM/YYYY." — זה חוסך המון תיקונים אחר כך.

Decision Framework: 5 שאלות לבחירת Framework

במקום לזכור טבלאות השוואה — ענו על 5 שאלות. התשובות יובילו אתכם ל-framework הנכון.

טבלת השוואה מלאה — 4 Frameworks, 8 קריטריונים

הנה הטבלה שתשמש אתכם כ-reference מהיר בכל פעם שצריכים לבחור framework:

שימו לב: אין "מנצח" בכל הקטגוריות. Astro מנצח בביצועים אבל לא מתאים לאפליקציות מורכבות. Next.js מנצח באקוסיסטם אבל כבד יותר. SvelteKit מנצח ביחס ביצועים-למורכבות אבל עם פחות תמיכת AI. הבחירה תמיד תלויה בפרויקט הספציפי.

תרגילים

שגרת עבודה — Frameworks ביום-יום

5 טעויות נפוצות כש-AI בוחר Framework — ואיך להימנע מהן

אחרי שעבדנו עם עשרות Vibe Coders, אלה הטעויות שחוזרות שוב ושוב:

1. AI בוחר Next.js לאתר סטטי. הבעיה: 180KB JavaScript לבלוג שצריך 0KB. הפתרון: ציינו "Use Astro" בפרומפט.
2. AI שם 'use client' על כל קובץ. הבעיה: מבטל את כל היתרונות של Server Components. הפתרון: בקשו "Use server components by default, 'use client' only for interactive parts".
3. AI מתעלם מ-RTL. הבעיה: כל הטקסט העברי נראה הפוך או שבור. הפתרון: תמיד הוסיפו "RTL support with dir='rtl', Hebrew UI text" בפרומפט.
4. AI משתמש ב-Pages Router (הישן) במקום App Router (החדש). הבעיה: קוד מיושן שלא מנצל server components. הפתרון: ציינו "Use Next.js App Router (not Pages Router)".
5. AI לא מוסיף loading states. הבעיה: המשתמש רואה מסך ריק בזמן טעינה. הפתרון: בקשו "Add loading.tsx with skeleton UI for async pages".

סיכום ומעבר לפרק הבא

בדוק את עצמך

צ'קליסט — סיכום פרק 3

• מבין/ה למה React לבד לא מספיק ומה frameworks מוסיפים
• מכיר/ה את Next.js — App Router, Server Components, API routes
• יודע/ת למה V0/Bolt/Lovable בוחרים Next.js כברירת מחדל
• מכיר/ה את Astro — islands architecture, אפס JS, content collections
• יודע/ת מה הרכישה של Astro על ידי Cloudflare אומרת
• מבין/ה מתי לבחור Astro ומתי Next.js — עם דוגמאות
• מכיר/ה את Vite כ-build tool (לא framework) ומה הוא עושה
• מכיר/ה את SvelteKit כאלטרנטיבה עם יתרונות וחסרונות
• יודע/ת שRemix התמזג עם React Router v7
• יודע/ת לציין framework ב-prompt ל-AI עם גרסה והגדרות
• בנה/תה decision tree עם 5 שאלות לבחירת framework
• השוו/תם prompt בסיסי לעומת prompt עם framework — וראיתם את ההבדל