React أم Laravel؟ السؤال الحقيقي هو فصل الواجهة عن الخلفية

React مكتبة جافاسكربت ترسم الواجهة داخل متصفح الزائر. Laravel إطار عمل بلغة PHP يشتغل على خادمك ويتولى قاعدة البيانات والصلاحيات ومنطق العمل. لا يحل أحدهما محل الآخر، ولوحة تحكم واحدة قد تستخدمهما معًا في المشروع نفسه. فإذا وصلك عرض سعر يخيّرك بين الاثنين، فاسأل عن شيء آخر قبل أن تختار.

ما يقصده الفريق التقني حين يطرح السؤال بهذه الصيغة هو: هل تُبنى واجهة الموقع منفصلة عن الخلفية وتتحدث معها عبر واجهة برمجية (API)، أم تُبنى داخلها فيرسل الخادم إلى المتصفح صفحات جاهزة؟ هذا قرار معماري له مقابل واضح، وأثره يظهر في فاتورة السنة الثانية أكثر مما يظهر في أسبوع التسليم.

يجيب هذا الدليل عن السؤال من موقع صاحب المشروع لا من موقع المطوّر، ويضع أمامك الجزء الذي يغيب عن أغلب المقارنات المتداولة: التواريخ الرسمية المنشورة لدورة دعم كل تقنية حتى 22 سبتمبر 2026، لأنها البند الوحيد في هذا القرار الذي يمكن التحقق منه بدل تقديره.

ما الذي يتولاه كل طرف

توثيق Laravel نفسه يعرّفه بأنه إطار خلفي، ثم يعرض مسارين لبناء الواجهة فوقه: إما بلغة PHP عبر Blade أو Livewire، وإما بإطار جافاسكربت مثل React عبر Inertia. وعلى الجانب الآخر، توثيق React لا يوصي ببناء تطبيق من المكتبة وحدها، بل بالبدء من إطار عمل مثل Next.js أو React Router، لأن المكتبة لا تتضمن توجيهًا ولا جلب بيانات ولا بناءً جاهزًا.

لهذا التفصيل أثر عملي: حين يقول لك أحدهم «سنبنيه بـ React»، فهو يعني React مع إطار فوقه ومكتبات حوله وبيئة تشغيل Node.js تحته. وكل طبقة من هذه الطبقات لها دورة ترقية خاصة بها، وكل دورة بند في عقد الصيانة.

الالتزام الذي توقّع عليه، بتواريخه

أي مشروع برمجي يُسلَّم مرة ويُصان سنوات. والفرق الحقيقي بين المسارين لا يظهر في جودة الواجهة، بل في عدد المرات التي ستدفع فيها ثمن ترقية خلال ثلاث سنوات. الجداول التالية منقولة من مواقع المشاريع نفسها، لا من مواقع مقارنات.

Laravel: 18 شهرًا لإصلاح الأخطاء، وسنتان للأمان

تنص صفحة إصدارات Laravel على أن كل إصدار يحصل على إصلاح للأخطاء مدة 18 شهرًا وعلى إصلاحات أمنية مدة سنتين، وأن الإصدار الرئيسي يصدر مرة كل سنة تقريبًا في الربع الأول.

اقرأ الجدول بتاريخ اليوم: Laravel 11 خرج من الدعم كليًا في مارس الماضي، وLaravel 12 توقّف عن تلقّي إصلاحات الأخطاء في أغسطس ولم يبقَ له سوى الترقيعات الأمنية حتى فبراير 2027. أي أن نظامًا سُلِّم إليك على Laravel 11 قبل سنتين يعمل اليوم على إصدار لا يصدر له أحد تحديثًا أمنيًا.

PHP تحت Laravel: جدول ثانٍ يجب أن يتوافق مع الأول

Laravel لا يعمل في الفراغ. تنشر PHP جدول دعمها على القاعدة نفسها لكل فرع: سنتان دعم كامل، ثم سنتان لإصلاحات الأمان الحرجة فقط.

الجدولان يتقاطعان في موضع يستحق سؤالًا مباشرًا في اجتماع التسعير. Laravel 13 يشترط PHP 8.3 حدًا أدنى، لكن 8.3 نفسه لم يعد في الدعم النشط منذ نهاية 2025. ومعنى ذلك أن مشروعًا جديدًا يُطلق اليوم على الحد الأدنى المسموح يبدأ حياته على فرع يتلقى إصلاحات أمنية فقط. اطلب أن يُكتب في العرض أن المشروع يعمل على PHP 8.4 أو 8.5، واطلب أن يُكتب أي إصدار Laravel تحديدًا.

وانتبه إلى فرع 8.2: دعمه الأمني ينتهي في 31 ديسمبر 2026، أي بعد نحو ثلاثة أشهر من تاريخ هذا المقال. إذا كان موقعك الحالي يعمل عليه فهذا بند ترقية لهذه السنة، لا للسنة القادمة.

React: عقد من نوع مختلف

هنا يتغيّر شكل الالتزام تمامًا. سياسة إصدارات React لا تعلن تاريخ انتهاء دعم لأي إصدار. ما تعلنه بدلًا من ذلك أمران: أن الفريق يصدر إصلاحًا أمنيًا مرجَّعًا لكل الإصدارات الرئيسية المتأثرة إذا عُرفت ثغرة، وأن الإصدارات الرئيسية نادرة عمدًا: الإصدار 15 في أبريل 2016، ثم 16 في سبتمبر 2017، ثم 17 في أكتوبر 2020، ثم 18 في مارس 2022، ثم 19 في ديسمبر 2024، وأحدث إصدار اليوم هو 19.3 الصادر في 9 سبتمبر 2026.

وتضيف السياسة قاعدة عملية مفيدة: إذا لم يُظهر تطبيقك أي تحذيرات على أحدث إصدار، فهو متوافق مع الإصدار الرئيسي التالي. أي أن تكلفة الترقية هنا تُدفع على دفعات صغيرة طوال العمر بدل دفعة كبيرة كل سنة.

هذا لا يعني أن الجانب الأمامي أقل التزامًا. الالتزام انتقل إلى الطبقات التي تحيط بالمكتبة: الإطار وبيئة التشغيل. مثال موثّق من الإطار الأشهر: دليل الترقية إلى Next.js 15 يوضّح أن واجهات وقت الطلب التي كانت متزامنة، ومنها cookies وheaders وparams وsearchParams، صارت غير متزامنة. وهو تغيير كاسر يمسّ كل صفحة تقرأ بيانات الطلب.

Node.js: الجدول الذي يخص أدوات البناء

React وأدواته تعمل فوق Node.js، وهذا جدوله كما ينشره فريق إصدارات المشروع:

توصية المشروع صريحة: التطبيقات الإنتاجية تستعمل إصدارات الدعم الطويل فقط، والدعم الطويل يمتد نحو 30 شهرًا. ويذكر الموقع تغييرًا قادمًا في السياسة: ابتداءً من الإصدار 27 تصبح الدورة سنوية وينتقل كل إصدار رئيسي إلى الدعم الطويل بعد مرحلة «الحالي».

ماذا يعني هذا كله في ميزانيتك

ضع الأرقام في جملة واحدة: مشروع Laravel يُسلَّم اليوم على الإصدار 13 يبقى في دائرة إصلاح الأخطاء حتى الربع الثالث من 2027، ثم يحتاج ترقية. فرع PHP الذي تحته يتحرك بجدوله. وإذا كانت الواجهة منفصلة، فأنت تصون مسار ترقية ثالثًا لإطار الواجهة، ورابعًا لبيئة Node.

هذه ليست حجة ضد الفصل. هي البند الذي يجب أن يظهر في عقدك بصيغة مكتوبة: من يترقّي، ومتى، وبأي سعر. وإذا كنت تراجع بنود التعاقد عمومًا، ففي دليل اختيار شركة تصميم مواقع قائمة البنود التي تمنع أشهر نقاط الخلاف بعد التسليم.

ثلاثة مسارات، لا مساران

أغلب المقارنات تعرض خيارين متقابلين، والواقع أن هناك ثلاثة، وأوسطها هو المسار الافتراضي في حزم البدء الرسمية لـ Laravel اليوم.

المسار الأوسط هو الذي يغيب عن أغلب النقاشات. يعرضه توثيق Laravel بوصفه طريقة لكتابة واجهة React كاملة مع بقاء خريطة الروابط والبيانات التي تصل إلى كل صفحة وتسجيل الدخول داخل وحدات تحكم PHP، في مستودع واحد. ومنذ Laravel 12 صارت حزم البدء الرسمية لـ React وVue وSvelte مبنية على Inertia مع TypeScript وTailwind. عمليًا: تحصل على مكونات React ولا تكتب API ولا طبقة مصادقة منفصلة.

متى يستحق الفصل تكلفته

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

تطبيق موبايل سيستهلك البيانات نفسها

إذا كان في خطة السنة القادمة تطبيق للعملاء أو للمناديب، فأنت ستحتاج API على أي حال. بناؤه مرة واحدة ليخدم الموقع والتطبيق معًا أرخص من بنائه لاحقًا فوق نظام لم يُصمَّم له. وإذا كنت لم تحسم بعدُ إطار التطبيق، فـالمقارنة بين Flutter وReact Native تتناول الاختيار بالتواريخ نفسها.

فرق منفصلة بمسؤوليات منفصلة

عندما يكون هناك فريق واجهات وفريق خلفية يعملان بوتيرتين مختلفتين، يصبح الفصل تنظيمًا قبل أن يكون تقنية: كل فريق ينشر على حدة ويختبر على حدة. أما بمطوّرَين اثنين فالفصل يضيف تنسيقًا أكثر مما يوفّر.

واجهة تحتاج بنية نشر مختلفة

منتج يُقدَّم لعدة مستأجرين بنطاقات مخصصة، أو واجهة تُوزَّع على شبكة توصيل محتوى بينما تبقى البيانات في خادم محدد الموقع، حالتان يبرّران وجود نشرين. وهذا النمط بالذات مشروح في دليل بناء منتج SaaS متعدد المستأجرين، وله بُعد قانوني في مصر والسعودية يتعلق بمكان تخزين البيانات، تجده في دليل اختيار شركة الاستضافة.

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

ما الذي يضيفه الفصل إلى الفاتورة

هذه البنود موجودة في توثيق الأدوات نفسها، ويمكنك أن تسأل عنها بالاسم.

المصادقة

في النظام المدمج، تسجيل الدخول سطر إعداد. في النظام المفصول يصبح تصميمًا قائمًا بذاته. وSanctum هي الحزمة الرسمية لهذه الحالة في Laravel، وتوثيقها يشترط لمصادقة الواجهة المنفصلة عبر كوكيز الجلسة أن يتشارك التطبيق والـAPI نفس النطاق الأعلى، مع السماح باختلاف النطاق الفرعي. ثم يصف الدورة: طلب إلى المسار sanctum/csrf-cookie أولًا لتهيئة الحماية، ثم تسجيل الدخول، مع إرسال قيمة كوكي XSRF-TOKEN في ترويسة X-XSRF-TOKEN في كل طلب تالٍ.

ويذكر التوثيق أيضًا حالتين تكلّفان وقتًا في كل مشروع: انتهاء الجلسة يعيد استجابة 401 أو 419 وعلى الواجهة أن تعالجها وتعيد المستخدم إلى شاشة الدخول، ومشاكل المصادقة من نطاق فرعي مختلف مصدرها عادةً إعداد CORS أو نطاق كوكي الجلسة. أضف إلى ذلك أن تطبيق الموبايل يسلك مسارًا آخر بالتوكنات، وأن التوثيق ينص صراحةً على ألا تُستخدم توكنات الـAPI لمصادقة واجهتك الأولى. أي أن عندك مسارَي مصادقة لا مسارًا واحدًا.

رفع الملفات

في النظام المدمج يصل الملف مع النموذج إلى الخادم مباشرة. في النظام المفصول يحتاج الأمر إما تمرير الملف عبر الـAPI بإعداد CORS وحدود حجم متوافقة على الطرفين، وإما رفعًا مباشرًا إلى تخزين سحابي برابط مؤقت. Laravel يوفّر الثاني عبر temporaryUploadUrl برابط له مدة صلاحية، لكن التوثيق ينبّه إلى أنه مدعوم على مشغّلي s3 وlocal فقط. اسأل: أين تُخزَّن المرفقات، ومن يتحقق من نوع الملف وحجمه، وماذا يحدث إذا انقطع الرفع في المنتصف.

الحالة ومصدر الحقيقة

عندما ترسم الواجهة نفسها، تصبح نسخة من البيانات موجودة في المتصفح. ومن هنا تأتي فئة كاملة من الأعطال التي لا يعرفها النظام المدمج: مستخدم يرى سعرًا قديمًا بعد تعديله من لوحة التحكم، أو رصيد مخزون لم يُحدَّث بعد بيع في التبويب الآخر. حلّها ليس صعبًا، لكنه بند عمل: قواعد لإعادة الجلب، وتعامل صريح مع فشل الشبكة، وتحديد ما يُحسم على الخادم دائمًا.

النشر والمراقبة في مكانين

بيئتا بناء ونشر بدل واحدة، ومتغيرات بيئة في مكانين، وشهادة وإعداد نطاق لكل طرف، وسجلّان عند التحقيق في عطل. لا شيء من هذا مستحيل، لكنه يظهر في سعر الإعداد الأول وفي عقد الصيانة الشهري، فاطلب أن يُسعَّر البندان منفصلين.

البحث والتحميل الأول: ما يقوله توثيق Google

إذا كان جزء من عملائك يصل إليك من البحث، فهذا البند يسبق كل ما سبق. يشرح توثيق Google للمطوّرين أن معالجة الصفحات المعتمدة على JavaScript تمرّ بثلاث مراحل: الزحف، ثم العرض، ثم الفهرسة. وفي المواقع المعروضة من الخادم يكفي تحليل استجابة HTML لأنها تتضمن المحتوى كاملًا. أما في نموذج «هيكل التطبيق» الذي لا يحمل فيه HTML الأولي محتوى فعليًا، فيحتاج محرك البحث إلى تنفيذ JavaScript أولًا، وتوضع الصفحة في طابور عرض تبقى فيه «لبضع ثوانٍ، لكن قد تستغرق وقتًا أطول من ذلك» بحسب نص التوثيق.

ويذكر التوثيق نقاطًا تصبح مسؤولية فريقك عند الفصل: تجنّب أخطاء soft 404 في تطبيقات الصفحة الواحدة، واستخدام History API بدل الأجزاء بعد الرمز #، والحرص على أن تكون الروابط عناصر <a> تحمل خاصية href ليكتشفها Googlebot. ويشير إلى أن العرض من جهة الخادم أو العرض المسبق طريقتان فعّالتان لأنهما يسرّعان الموقع للمستخدمين وبرامج الزحف معًا.

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

ما الذي يتغيّر لأن الموقع عربي

اتجاه الصفحة يترتب عليه عمل حقيقي، ويختلف موضع هذا العمل بين المسارين.

في المسار المدمج تُحسم اللغة والاتجاه على الخادم قبل أن تصل الصفحة إلى المتصفح: قيمة dir في وسم html تُكتب مرة واحدة في القالب، والزائر لا يرى وميض تبديل اتجاه. وفي المسار المفصول تكون الواجهة هي من يقرر، فإذا تأخر القرار إلى ما بعد أول رسم ظهرت الصفحة لحظةً من اليسار إلى اليمين ثم انقلبت. إصلاح هذا ممكن بالعرض من الخادم أو بحسم اللغة من الرابط، لكنه بند اختبار لا يُكتشف إلا بالتجربة على شبكة بطيئة.

وفي الحالتين يوفّر عليك الأسلوب الصحيح في CSS عملًا مكررًا. تشرح MDN أن الخصائص المنطقية تعرّف الاتجاه نسبةً إلى اتجاه الكتابة لا إلى اليمين واليسار الفيزيائيين، فتكتب التنسيق مرة واحدة ويعمل في النسختين العربية والإنجليزية دون ملف تنسيق ثانٍ.

أما صياغة النصوص فتختلف أدواتها بين الطرفين. في Laravel تُكتب صيغ الجمع يدويًا بنطاقات مثل {0} و[2,*] وتُقرأ عبر trans_choice، كما يوضح توثيق الترجمة، والتوثيق نفسه يذكر أن مُصرِّف الجمع المدمج يدعم الفرنسية والنرويجية والبرتغالية والإسبانية والتركية، والعربية ليست بينها. وفي المتصفح توجد واجهة Intl.PluralRules التي تعطي فئة الجمع حسب قواعد اللغة. فإذا كان نظامك يرسل رسائل من الخادم ويعرض نصوصًا في الواجهة، احسم مبكرًا أين تعيش ملفات الترجمة، وإلا انتهيت بنسختين تتباعدان مع كل تحديث.

الأداء: ما الذي يحدده فعلًا

لن تجد هنا رقمًا يقول إن مسارًا أسرع من آخر بنسبة معينة، لأن لا Laravel ولا React ينشران مقارنة أداء بين معمارية وأخرى، والأرقام المتداولة في المقارنات تعود غالبًا إلى اختبار واحد على جهاز واحد بتطبيق واحد.

ما يمكن قوله بدقة هو أين يذهب الوقت فعليًا في مشاريع كهذه: عدد استعلامات قاعدة البيانات في الصفحة الواحدة ووجود فهارس عليها، وحجم الصور غير المضغوطة، وعدد الطلبات الشبكية التي تحتاجها الواجهة قبل أن تعرض شيئًا مفيدًا، وحجم ملفات جافاسكربت التي يجب تنزيلها وتنفيذها قبل أول رسم، والمسافة بين خادمك وزائرك. أربعة من هذه الخمسة لا علاقة لها بالاختيار بين المسارين. والخامس، أي حجم جافاسكربت وعدد الطلبات قبل أول رسم، هو البند الوحيد الذي يتأثر بالفصل، وهو قابل للقياس والعلاج، وتفاصيله في دليل تحسين سرعة الموقع.

أسئلة تطرحها على أي عرض سعر

• أي إصدار Laravel وأي فرع PHP سيُبنى عليه المشروع، ومن يتولى الترقية بعد انتهاء نافذة إصلاح الأخطاء؟
• هل ستُبنى الواجهة داخل التطبيق أم منفصلة عنه؟ وإن كانت منفصلة، فما الذي يبرر الفصل في حالتي تحديدًا؟
• إذا كان هناك تطبيق موبايل في الخطة، هل سيستخدم نفس الـAPI؟ ومن يوثّقه؟
• كيف ستصل محتويات الصفحات إلى محركات البحث: من الخادم، أم بتوليد مسبق، أم بجافاسكربت بعد التحميل؟
• من يملك المستودعات والحسابات والنطاق ومفاتيح التخزين بعد التسليم؟
• ما سعر الصيانة السنوية، وهل تشمل ترقيات الإصدارات الرئيسية أم تُحتسب على حدة؟

القرار الذي يستحق وقتك هو حجم الالتزام الذي تقبله مقابل ما تحصل عليه، لا اسم التقنية. المسار المدمج يعطيك أقل عدد من قطع الصيانة، والمسار المفصول يعطيك مرونة تستحق ثمنها عندما يكون لها سبب مكتوب. وإذا كان القرار الأسبق لديك ما زال بين نظام جاهز ونظام يُبنى لك، فابدأ من المقارنة بين الجاهز والمخصص قبل هذا كله.

اعرض متطلبات مشروعك على فريق سنابل قبل أن تلتزم بمعمارية. نقرأ الحالة ونرد خلال 24 ساعة بترشيح مسبَّب لأحد المسارات الثلاثة وتقدير أوّلي للمدة والتكلفة، بلا مقابل وبلا التزام. أو تصفّح خدمة تطوير الويب وتطبيقاته لترى ما يشمله التنفيذ.

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

هل أستطيع البدء بواجهة مدمجة ثم فصلها لاحقًا؟

نعم، وهذا هو المسار الأقل مخاطرة في أغلب المشاريع. ابدأ بواجهة مدمجة واشترط من اليوم الأول أن يكون منطق العمل في طبقة خدمات مستقلة لا داخل القوالب، وأن يكون لكل عملية مهمة نقطة دخول واحدة. حينها يصبح إخراج API لاحقًا إضافةً فوق ما هو قائم بدل إعادة كتابة. أما إذا كُتب المنطق داخل صفحات العرض فالفصل يتحول إلى مشروع ثانٍ بحجم الأول.

ماذا لو اقترح الفريق بناء المشروع كاملًا بـ Next.js دون Laravel؟

خيار قائم لا يُرفض من حيث المبدأ؛ فتوثيق React يوضّح أن الأطر الموصى بها تتيح إضافة العرض من الخادم لكل مسار على حدة، وهو ما يغطي احتياج أغلب المواقع. السؤال الذي يحسم الأمر تشغيلي: أي بيئة يستطيع فريقك صيانتها بعد سنتين، وأين ستعيش منطق الأعمال والتقارير والصلاحيات، ومن يتولى ترقية بيئة Node.js في كل دورة. اطلب أن تُكتب الإجابة في العرض قبل التوقيع.

هل الترقية بين إصدارات Laravel الرئيسية مشروع كبير؟

بحسب توثيق Laravel، يسعى الفريق إلى أن تتم الترقية إلى إصدار رئيسي جديد في يوم أو أقل، ويذكر أن أغلب التطبيقات تنتقل إلى الإصدار 13 دون تغيير كبير في شيفرة التطبيق. لكن هذا يخص الإطار نفسه؛ أما الحزم الخارجية التي أضافها فريقك فلكل منها جدولها، وهي عادةً سبب طول الترقية. اطلب قائمة الحزم الخارجية ضمن وثائق التسليم.

كيف أعرف إصدار Laravel وPHP اللذين يعمل عليهما موقعي الحالي؟

اطلب من الفريق التقني أمرين: قيمة laravel/framework في ملف composer.json الخاص بالمشروع، ونتيجة الأمر php -v على الخادم. رقمان في رسالة واحدة، ثم قارنهما بالجدولين في هذا المقال. وإذا وجدت الإصدارين خارج نافذة الدعم فابدأ حديث الترقية قبل أن يفرضه عليك عطل أمني.

المصادر

جميع الصفحات أدناه روجعت في 22 سبتمبر 2026.

• توثيق Laravel: بيان الإصدارات وسياسة الدعم والواجهة الأمامية وحزم البدء وSanctum وتخزين الملفات والترجمة والتعريب.
• الإصدارات المدعومة من PHP، من مجموعة PHP.
• Node.js: جدول الإصدارات من فريق الإصدارات وصفحة الإصدارات السابقة.
• توثيق React: سياسة الإصدارات وقائمة الإصدارات وإنشاء تطبيق React.
• Vercel: دليل الترقية إلى Next.js 15.
• Google Search Central: أساسيات تحسين محركات البحث المستندة إلى JavaScript.
• MDN: خصائص CSS المنطقية وقيمها والكائن Intl.PluralRules.