موقعك على Gatsby يُطلق الآن. لكن على الأقل، نظام الإضافات يتحلل، والمستندات الرسمية تحول إلى مستودعات مؤرشفة، وآخر تحديث أمان جاء من فرع المجتمع. لقد قمت بترحيل ثلاثة مشاريع Gatsby للمؤسسات إلى Next.js منذ أوائل 2025 — استغرق أحدها 11 يومًا، واستغرق الآخر 6 أسابيع، والثالث لا يزال يعمل بالتوازي. جمعت Gatsby 46 مليون دولار، تم الاستحواذ عليها من قبل Netlify في 2023، وتم إيقافها بهدوء بحلول الربع الثالث من 2025. هذا ليس مقارنة إطار عمل — إنه تشريح لمكدس واحد ودليل ميداني للمكدس الذي نجا. تُظهر البيانات أدناه بالضبط السبب في فوز Next.js، وما ستكلفه الترجمة فعليًا، والسيناريو الوحيد حيث لا يزال البقاء على Gatsby منطقيًا.

إذا كنت لا تزال تشغل Gatsby في الإنتاج، فأنت بحاجة إلى خطة ترجمة. إذا كنت تختار إطار عمل لمشروع جديد، فالإجابة واضحة لكن دقيقة. دعني أتناول كل هذا معك.

جدول المحتويات

Next.js مقابل Gatsby في 2026: دليل القرار الإنتاجي الكامل

حالة Gatsby في 2026

دعنا لا نلطف الأمور. Gatsby مهجور فعليًا.

استحوذت Netlify على Gatsby Inc. في فبراير 2023. كان الوعد هو التطوير المستمر والتكامل مع منصة Netlify. ما حدث فعليًا كان بطء الإغلاق التدريجي. تم نشر آخر إصدار ذي معنى من Gatsby (v5.13) في أواخر 2023. احتوى مستودع GitHub على الحد الأدنى من تعليقات الصيانة منذ منتصف 2024. غادر المسؤولون الرئيسيون. نظام الإضافات توقف عن النمو — العديد من الإضافات الشهيرة لم يتم تحديثها لأكثر من 18 شهرًا.

هنا الجدول الزمني الذي يعتبر:

التاريخ الحدث
فبراير 2023 استحوذت Netlify على Gatsby Inc.
الربع الثالث 2023 تم إطلاق Gatsby v5.13 (آخر إصدار مهم)
الربع الأول 2024 تم إيقاف Gatsby Cloud رسميًا
الربع الثاني 2024 غادر أعضاء الفريق الأساسي Netlify
الربع الرابع 2024 تنزيلات npm الأسبوعية تنخفض إلى أقل من 150k (من ذروة 800k+)
الربع الأول 2025 أزالت Netlify مستندات خاصة بـ Gatsby من التنقل الأساسي
2026 لا إصدار v6، لا خارطة طريق، بشكل فعلي في وضع الصيانة

أرقام تنزيلات npm تروي القصة. في ذروتها في 2021، كانت Gatsby تحصل على أكثر من 800,000 تنزيل أسبوعي. اعتبارًا من أوائل 2026، يحوم حول 100,000 — ومعظم تلك من خطوط أنابيب CI/CD الموجودة، وليس مشاريع جديدة.

لا أقول هذا للانتقاص من Gatsby. لقد دفعت النظام البيئي React للأمام حقًا. الفكرة الخاصة بطبقة بيانات وقت البناء مع GraphQL، وتحسين الصور في وقت البناء، ومعمارية الإضافات — كانت هذه ابتكارات حقيقية. لكن الإطار فقد الحجة التقنية عندما نشرت Next.js ISR في أواخر 2020، وفقدت الحجة التجارية عندما توقفت Netlify عن الاستثمار فيها.

إذا كنت تشغل Gatsby في الإنتاج الآن، فإن أكبر المخاطر لديك هي:

  • الثغرات الأمنية في التبعيات غير المحتفظ بها
  • عدم توافق إصدار Node.js مع تقدم النظام البيئي
  • تحلل الإضافات — الإضافات التابعة للأطراف الثالثة تنكسر بدون إصلاحات علوية
  • صعوبة التوظيف — المطورون لا يريدون Gatsby في سيرتهم الذاتية في 2026

Next.js في 2026: ما الذي تغير فعليًا

وصل Next.js 15 في أواخر 2024، والإصدارات التكرارية خلال 2025 عززت App Router كنموذج التطوير الأساسي. إليك حالة الأمور:

React Server Components (RSC) هي الآن الافتراضية. عندما تنشئ مكونًا في App Router، فهو Server Component ما لم تضيف صراحة 'use client'. لم تكن هذه تغييرًا للصيغة فقط — لقد غيرت بشكل أساسي كيفية تفكيرنا في جلب البيانات ومعمارية المكونات.

Partial Prerendering (PPR) ضربت الاستقرار في Next.js 15.1. هذه هي الميزة التي كانت ستقتل Gatsby حتى لو كان Gatsby لا يزال قيد التطوير بنشاط. تسمح PPR بخدمة قشرة ثابتة على الفور أثناء بث المحتوى الديناميكي. تحصل على سرعة SSG مع مرونة SSR. إنه أفضل من كلا العالمين، وهي شيء لا يمكن لمعمارية Gatsby دعمه أبدًا.

Server Actions نضجت بشكل كبير. معالجة الأشكال والطفرات وإعادة التحقق من الصحة — الأنماط راسخة الآن واستبدلت الكثير من غلاف API route الذي اعتدنا كتابته.

// Next.js 15 - مثال Server Action
// app/actions.ts
'use server'

import { revalidatePath } from 'next/cache'

export async function updateProduct(formData: FormData) {
  const id = formData.get('id') as string
  const title = formData.get('title') as string
  
  await db.product.update({
    where: { id },
    data: { title }
  })
  
  revalidatePath(`/products/${id}`)
}

حزمة Turbopack bundler هي الآن الافتراضية للتطوير (والاستقرار للبناء الإنتاجي اعتبارًا من أوائل 2026). انخفضت أوقات البدء البارد لـ next dev بنسبة 50-70% مقارنة بـ webpack. بناء الإنتاج أسرع أيضًا، على الرغم من أن التحسن هناك أكثر تواضعًا — حول 20-30%.

معايير الأداء: Lighthouse وحجم الحزمة و Core Web Vitals

قمت بتشغيل المعايير على مواقع معادلة — موقع تسويقي بـ 50 صفحة، مدونة بـ 200 منشور، قسم محفظة غني بالصور. نفس المحتوى، نفس الاستضافة (Vercel for Next.js، Netlify for Gatsby). إليك النتائج من يناير 2026:

درجات Lighthouse (الجوال، الوسيط من 5 أشواط)

المقياس Next.js 15 (App Router) Gatsby 5.13 Next.js 15 (Pages Router)
الأداء 96 88 93
إمكانية الوصول 98 97 98
أفضل الممارسات 100 95 100
SEO 100 100 100
LCP (ثانية) 1.1s 1.8s 1.3s
FID/INP (ms) 45ms 120ms 85ms
CLS 0.02 0.08 0.03
TBT (ms) 120ms 380ms 190ms

مقارنة حجم الحزمة

هنا الأشياء تصبح مثيرة حقًا للاهتمام. تشحن Gatsby وقت التشغيل من جانب العميل الذي يتضمن React، وقت تشغيل Gatsby، وطبقة البيانات. Next.js مع App Router و RSC تشحن JavaScript أقل بكثير للعميل لأن Server Components لا تساهم بأي شيء في حزمة العميل.

المقياس Next.js 15 (App Router) Gatsby 5.13
First Load JS 87 KB (مضغوط) 210 KB (مضغوط)
Route JS (المتوسط) 12 KB 45 KB
إجمالي JS (موقع 50 صفحة) 145 KB 380 KB
تحسين الصور مدمج (عند الطلب) وقت البناء (gatsby-plugin-image)
تحسين الخط مدمج (next/font) يدوي أو إضافة

فرق حجم الحزمة يرجع في الغالب إلى RSC. في موقع Gatsby نموذجي، كل مكون يشحن إلى العميل حتى لو عرض محتوى ثابت فقط. في Next.js مع Server Components، مكون يجلب البيانات ويعرض HTML لا يصل أبدًا إلى حزمة العميل. هذا فوز ضخم.

Core Web Vitals في الحقل

معايير المختبرات مفيدة، لكن بيانات الحقل أكثر أهمية. بناءً على بيانات CrUX (تقرير تجربة المستخدم Chrome) من المواقع التي عملت معها:

  • مواقع Next.js: 85% تمرير جميع عتبات Core Web Vitals الثلاثة
  • مواقع Gatsby: 62% تمرير جميع الثلاثة (يفشل في الغالب على INP و TBT)

مقياس INP (Interaction to Next Paint) هو حيث يكافح Gatsby حقًا. حزمة JavaScript الأكبر من جانب العميل تعني عملًا أكثر على الخيط الرئيسي، مما يعني تفاعلات أبطأ. نموذج ترطيب Gatsby يتطلب معالجة بيانات الصفحة بأكملها على العميل، بينما Next.js مع RSC يتجنب هذا تمامًا للمحتوى المعروض من الخادم.

Next.js مقابل Gatsby في 2026: دليل القرار الإنتاجي الكامل - العمارة

مقارنة العمارة: RSC و App Router و SSG و ISR

استراتيجيات العرض

تم بناء Gatsby حول استراتيجية عرض واحدة: Static Site Generation (SSG). كل شيء يُبنى في وقت البناء. أضافت Gatsby DSG (Deferred Static Generation) في v4، والذي كان ردهم على ISR من Next.js، لكنه تطلب Gatsby Cloud ولم يكن مرنًا أبدًا.

Next.js يعطيك كل شيء:

// الجيل الثابت (معادل لافتراضي Gatsby)
// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map((post) => ({ slug: post.slug }))
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug)
  return <Article post={post} />
}

// ISR - أعد التحقق كل 60 ثانية
export const revalidate = 60

// أو إعادة التحقق عند الطلب عبر API route
// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache'
import { NextRequest } from 'next/server'

export async function POST(request: NextRequest) {
  const { path } = await request.json()
  revalidatePath(path)
  return Response.json({ revalidated: true })
}

مشكلة طبقة البيانات

كانت طبقة بيانات GraphQL الخاصة بـ Gatsby مبتكرة لكن أصبحت في النهاية مسؤولية. كل مصدر بيانات يحتاج إلى مكون إضافة للمصدر. إذا لم توجد المكون الإضافي أو لم يتم الاحتفاظ به، فأنت عالق في كتابة واحدة بنفسك. كانت نظام GraphQL في وقت البناء قوية لكن أضافت تعقيدًا كبيرًا ووقت بناء.

Next.js يتخذ نهجًا مختلفًا: فقط جلب البيانات. استخدم أي شيء تريد — REST APIs، عملاء GraphQL، استعلامات قاعدة البيانات، SDKs CMS. لا توجد طبقة بيانات فرضها الإطار. هذا أبسط وأكثر مرونة.

// Next.js - جلب من أي مصدر، بأي طريقة تريد
async function getProducts() {
  // استعلام قاعدة البيانات المباشرة
  const products = await prisma.product.findMany()
  
  // أو REST API
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 3600 }
  })
  
  // أو headless CMS SDK
  const entries = await contentful.getEntries({ content_type: 'product' })
  
  return products
}

بالنسبة للفريق الذي يستخدم إعدادات headless CMS — Contentful، Sanity، Storyblok، أيا كان — Next.js أسهل بكثير في الدمج. لا تحتاج إلى مكون إضافة للمصدر. تُستدعي فقط API. نغطي هذا بعمق في عمل تطوير headless CMS الخاص بنا.

Server Components تغير كل شيء

أعود باستمرار إلى RSC لأنها في الواقع أهم تحول معماري في React منذ hooks. إليك السبب في أهميته لهذه المقارنة:

في Gatsby، شجرة مكونات الصفحة بأكملها تشحن إلى العميل. حتى لو كان المكون يعرض قائمة بعناوين منشورات المدونة المجلوبة من CMS، فإن كود المكون وبيانات المكون يتم تسلسلها وإرسالها إلى المتصفح للترطيب.

في Next.js مع RSC، يعمل نفس المكون على الخادم، يعرض HTML، والعميل لا يرى أبدًا كود المكون أو البيانات الخام. يحصل المتصفح على HTML. هذا فقط.

هذا يعني:

  • حزم أصغر (كما هو موضح أعلاه)
  • لا توجد أخطاء عدم تطابق الترطيب للمكونات الخاصة بالخادم فقط
  • يمكنك استخدام كود خاص بالخادم فقط (استعلامات قاعدة البيانات، الوصول إلى نظام الملفات) مباشرة في المكونات
  • البيانات الحساسة (مفاتيح API، منطق العمل) تبقى على الخادم

تجربة المطورين والنظام البيئي

الجانب Next.js 15 Gatsby 5
دعم TypeScript الدرجة الأولى، أنواع مولدة تلقائيًا لائق، لكن بعض أنواع الإضافات مفقودة
سرعة الإعادة الساخنة ~200ms (Turbopack) 1-3 ثوانٍ (webpack)
وقت البناء (200 صفحة) ~45 ثانية ~3-5 دقائق
نظام الإضافات حزم npm (عالمي) إضافات Gatsby محددة (راكدة)
التوثيق يتم الاحتفاظ به بنشاط معظمه مجمد منذ 2023
المجتمع (Discord/GitHub) نشط جدًا صامت تقريبًا
طلب سوق العمل مرتفع ينخفض بسرعة
موارد التعلم (2025-2026) وفيرة نادرة

فجوة تجربة المطورين اتسعت بشكل كبير. Next.js مع Turbopack يعطيك إعادة تحميل ساخنة فورية تقريبًا. خادم التطوير المستند إلى webpack في Gatsby يبدو بطيئًا بالمقارنة، خاصة على المواقع الأكبر.

أوقات البناء تستحق الإشارة الخاصة. موقع Gatsby بـ 500 صفحة مع معالجة صور ثقيلة يمكن أن يستغرق 15-20 دقيقة للبناء. موقع Next.js المعادل مع تحسين الصور عند الطلب يُبنى في أقل من دقيقتين لأن الصور تُعالج في وقت الطلب (ثم تُخزن مؤقتًا)، وليس في وقت البناء.

رأى فريق تطوير Next.js الخاص بنا هذا يحدث عبر العشرات من المشاريع. أوقات البناء تؤثر مباشرة على إنتاجية المطورين وتكاليف CI/CD.

إجمالي تكلفة الملكية

دعنا نتحدث عن المال. هنا حيث يصبح القرار حقيقيًا لأصحاب المصلحة في الأعمال.

تكاليف الاستضافة

السيناريو Next.js على Vercel Gatsby على Netlify
موقع صغير (< 100 صفحة، حركة منخفضة) $0-20/mo $0-19/mo
موقع متوسط (500 صفحة، 100k زيارة/mo) $20-150/mo $19-99/mo
موقع كبير (5000+ صفحة، 1M+ زيارة/mo) $150-500/mo $99-300/mo*

*تكاليف استضافة Gatsby أقل لأنها ثابتة تمامًا — لا حسابة الخادم. لكنك تدفع في أوقات البناء ودقائق البناء.

يمكن أيضًا نشر Next.js على منصات أخرى: AWS (عبر SST أو Amplify)، Cloudflare، مستضاف ذاتيًا مع Node.js. الإخراج الثابت النقي من Gatsby يعطيه مرونة استضافة أكثر نظريًا، لكن عمليًا تفقد ISR وأي ميزات ديناميكية.

تكاليف التطوير

هنا حيث يعيش فرق التكلفة الحقيقي:

  • معدلات مطور Gatsby: $120-180/hr (نادر، قسط للمعرفة القديمة)
  • معدلات مطور Next.js: $100-200/hr (نطاق أوسع بسبب حمام المواهب الأكبر)
  • تكلفة الترجمة (موقع Gatsby متوسط → Next.js): $15,000-50,000 اعتمادًا على التعقيد
  • الصيانة المستمرة (Gatsby): أعلى بسبب إدارة التبعيات وإصلاحات الإضافات
  • الصيانة المستمرة (Next.js): أقل، مسارات ترقية أكثر وضوحًا

التكلفة المخفية للبقاء على Gatsby هي الدين التقني الذي يتراكم يوميًا. كل شهر تنتظر، تصبح الترجمة أصعب قليلاً.

للحصول على تقييم مفصل لما قد تكلفه الترجمة لموقفك المحدد، تفقد صفحة التسعير أو تواصل معنا.

مسار الترجمة: Gatsby إلى Next.js

لقد فعلت هذا بما يكفي لدي عملية قابلة للتكرار. إليك نهج المستوى العالي:

المرحلة 1: التدقيق (1-2 أسبوع)

  • جرد جميع إضافات Gatsby ومعادلاتها Next.js
  • خريطة طبقة بيانات GraphQL لاستدعاءات API المباشرة أو استخدام SDK
  • تحديد منطق gatsby-node.js (إنشاء الصفحات، تخصيص النظام)
  • قائمة جميع الميزات الديناميكية (البحث، الأشكال، المصادقة)

المرحلة 2: الأساس (1-2 أسبوع)

  • إنشاء مشروع Next.js مع App Router
  • قم بتكوين TypeScript و ESLint و Tailwind (أو نهج CSS)
  • إعداد التكامل CMS مباشرة (لا توجد حاجة إلى إضافات المصدر)
  • تنفيذ استراتيجية تحسين الصور باستخدام next/image

المرحلة 3: ترجمة الصفحة (2-6 أسابيع، اعتمادًا على الحجم)

  • تحويل قوالب الصفحة إلى مكونات صفحة Next.js
  • استبدل gatsby-image / gatsby-plugin-image بـ next/image
  • استبدل <Link> من Gatsby بـ <Link> من Next.js (API متشابهة، لحسن الحظ)
  • ترجمة منطق gatsby-node.js createPages إلى generateStaticParams
  • تحويل منطق gatsby-browser.js / gatsby-ssr.js لمكونات التخطيط

المرحلة 4: التحسين (1-2 أسبوع)

  • تنفيذ ISR حيث يكون مناسبًا
  • إضافة Server Components للأقسام الغنية بالبيانات
  • إعداد webhooks إعادة التحقق عند الطلب من CMS
  • اختبار الأداء والتحسين
// نمط ترجمة شائع: استعلام صفحة Gatsby → جلب بيانات Next.js

// BEFORE (Gatsby)
export const query = graphql`
  query BlogPostBySlug($slug: String!) {
    contentfulBlogPost(slug: { eq: $slug }) {
      title
      body { raw }
      publishDate
      heroImage {
        gatsbyImageData(width: 1200)
      }
    }
  }
`

// AFTER (Next.js App Router)
import { createClient } from 'contentful'

const client = createClient({
  space: process.env.CONTENTFUL_SPACE_ID!,
  accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!
})

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const entries = await client.getEntries({
    content_type: 'blogPost',
    'fields.slug': params.slug,
    limit: 1
  })
  
  const post = entries.items[0].fields
  
  return (
    <article>
      <h1>{post.title}</h1>
      <Image
        src={`https:${post.heroImage.fields.file.url}`}
        width={1200}
        height={630}
        alt={post.title}
      />
      <RichText content={post.body} />
    </article>
  )
}

export const revalidate = 3600 // ISR: أعد التحقق كل ساعة

أكبر مشكلة في الترجمة هي التعامل مع الصور. كان خط أنابيب صور Gatsby ممتازًا حقًا — الحجب للأعلى، المجموعات المتجاوبة، التحميل الكسول. والخبر السار أن next/image يتعامل مع كل هذا الآن، لكن API مختلفة ويجب عليك تحديث كل مرجع صورة.

عندما لا يكون Next.js هو الإجابة

أريد أن أكون عادلاً هنا. Next.js ليس الخيار الصحيح لكل مشروع.

إذا كنت تحتاج إلى بساطة مطلقة لموقع مدونة أو مستندات، فكر في Astro. Astro لا يشحن أي JavaScript بشكل افتراضي وله دعم ممتاز لمجموعة المحتوى. بالنسبة للمواقع التي تعتمد بدقة على المحتوى حيث لا تحتاج إلى تفاعلية React، ستمنحك Astro أداءً أفضل مع تعقيد أقل.

إذا كنت تبني موقعًا ثابتًا بسيطًا بدون ميزات ديناميكية، فحتى 11ty أو Hugo قد تخدمك بشكل أفضل. لا تحضر إطار عمل لمحاربة الترميز.

إذا كنت عالقًا في نظام Vue أو Svelte البيئي، فإن Nuxt و SvelteKit هي بدائل قوية في النظم البيئية الخاصة بهم.

لكن إذا كنت بحاجة إلى React، بحاجة إلى مزيج من المحتوى الثابت والديناميكي، بحاجة إلى أداء رائع، وبحاجة إلى إطار عمل سيتم صيانته بنشاط لسنوات قادمة — Next.js هو الخيار الواضح في 2026.

الحكم

Next.js يفوز. إنه ليس قريبًا حتى، ولم يكن قريبًا منذ 2022.

لقد طرحت Gatsby أفكارًا مهمة في النظام البيئي React: التحسين في وقت البناء، خطوط معالجة الصور، مفهوم طبقة بيانات موحدة. هذه الأفكار تعيش بأشكال مختلفة عبر الأطر الحديثة. لكن كإطار إنتاج في 2026، Gatsby هو مسؤولية.

الحجج التقنية ساحقة:

  • RSC و App Router تعطي Next.js ميزة معمارية لا يمكن لـ Gatsby مطابقتها
  • أحجام الحزمة أصغر بـ 40-60%
  • درجات Core Web Vitals متسقة بشكل أفضل
  • ISR و PPR توفران مرونة عرض لم تحققها Gatsby أبدًا
  • النظام البيئي مزدهر مقابل راكد

الحجج التجارية واضحة بالقدر نفسه:

  • إجمالي تكلفة ملكية أقل
  • حمام مواهب أكبر
  • التطوير النشط والدعم من Vercel
  • مسارات ترقية واضحة للمستقبل المنظور

إذا كنت تبدأ مشروعًا جديدًا، استخدم Next.js (أو Astro إذا كنت لا تحتاج إلى React). إذا كان لديك Gatsby قيد التشغيل في الإنتاج، ابدأ بالتخطيط للترجمة الآن. كلما طال انتظارك، أصبح الأمر أصعب وأكثر تكلفة.

هل تحتاج إلى مساعدة في تلك الترجمة؟ قام فريقنا بذلك عدة مرات. دعنا نتحدث.

— Aaron Mitchell، رئيس مهندس Headless في Social Animal

الأسئلة الشائعة

هل Gatsby ميت تمامًا في 2026؟ لم تُعلن Netlify عن Gatsby رسميًا كنهاية للحياة، لكنه فعليًا في حالة الصيانة فقط. لم يكن هناك إصدار مهم منذ v5.13 في أواخر 2023، تشتت الفريق الأساسي، ونظام الإضافات يتدهور. للمشاريع الجديدة، إنها ليست خيارًا قابلاً للحياة. بالنسبة للمشاريع الموجودة، يجب عليك التخطيط للترجمة.

كم من الوقت يستغرق الهجرة من Gatsby إلى Next.js؟ بالنسبة لموقع تسويقي نموذجي بـ 50-200 صفحة، توقع 4-8 أسابيع من وقت التطوير. المواقع الأكبر مع علاقات بيانات معقدة، أو إضافات مخصصة، أو استخدام GraphQL ثقيل يمكن أن تستغرق 8-16 أسبوعًا. أكبر المتغيرات هي عدد إضافات Gatsby المخصصة التي تستخدمها ومدى عمق التكامل مع طبقة بيانات GraphQL في Gatsby.

هل Next.js أصعب في التعلم من Gatsby؟ هناك منحنى تعلم لـ App Router و Server Components، خاصة إذا كنت قادمًا من نموذج صفحات Gatsby. ومع ذلك، فإن النموذج العقلي في النهاية أبسط — أنت تجلب البيانات مباشرة بدلاً من الذهاب عبر طبقة GraphQL، وتكتب مكونات تعمل إما على الخادم أو العميل. يجد معظم المطورين Next.js أكثر حدسية بمجرد تجاوز مفاهيم RSC الأولية.

هل يمكنني نشر Next.js بدون Vercel؟ بالتأكيد. يمكن نشر Next.js على AWS (باستخدام SST أو Amplify)، Cloudflare Pages، DigitalOcean، Railway، Fly.io، أو على خادم Node.js مستضاف ذاتيًا. توفر Vercel التجربة الأكثر تحسينًا، لكنك لست مقيدًا. الأمر next start يشغل خادم Node.js قياسي.

ماذا عن Astro مقابل Next.js للمواقع الثابتة؟ بالنسبة للمواقع الموجهة للمحتوى بحتة (المدونات والتوثيق والصفحات التسويقية بتفاعلية قليلة)، غالبًا ما تكون Astro الخيار الأفضل. إنها لا تشحن أي JavaScript بشكل افتراضي وتدعم أطر عمل واجهة مستخدمة متعددة. إذا كنت بحاجة إلى تفاعلية React أو توجيه ديناميكي أو نقاط نهاية API أو مصادقة أو مزيج من المحتوى الثابت والديناميكي، فإن Next.js هو الخيار الأفضل. نعمل مع كلاهما — تحقق من صفحة تطوير Astro لمزيد من المعلومات حول متى نوصي به.

كم تكلفة الهجرة من Gatsby إلى Next.js؟ عادة ما تتراوح تكاليف التطوير من $15,000 لموقع تسويقي بسيط إلى $50,000+ للتطبيقات المعقدة مع خطوط أنابيب بيانات مخصصة، أو تكامل التجارة الإلكترونية، أو التدويل. تعتمد التكلفة بشكل كبير على عدد إضافات Gatsby التي تحتاج إلى استبدال وتعقيد استعلامات GraphQL وما إذا كنت تريد تحديث العمارة (إضافة ISR و Server Components) أثناء الترجمة.

هل Next.js يدعم التصدير الثابت مثل Gatsby؟ نعم. قيد التشغيل next build مع output: 'export' في next.config.js يُنتج موقعًا ثابتًا بالكامل يمكن استضافته في أي مكان — S3 و GitHub Pages وأي CDN. تفقد ISR والميزات من جانب الخادم، لكنك تحصل على نفس نموذج النشر مثل Gatsby. معظم الفريق لا يريد ثابتًا بحتًا بمجرد تجربة فوائد ISR و Server Components، على الرغم من ذلك.

ماذا حدث لـ Gatsby Cloud؟ تم إيقاف Gatsby Cloud في الربع الأول من 2024، حوالي سنة بعد استحواذ Netlify. تم نقل المستخدمين إلى استضافة Netlify القياسية. كانت هذه ضربة كبيرة لأن Gatsby Cloud وفرت عمليات بناء محسنة، عمليات بناء متدرجة، وميزة المعاينة التي كانت مترابطة بإحكام مع معمارية Gatsby. بدون Gatsby Cloud، أوقات البناء على منصات CI/CD القياسية أسوأ بشكل ملحوظ.