Laravel مقابل Rails: المقارنة تغيّرت

بدأ Laravel بأخذ ما أثبته Rails: أن الإطار يجوز أن تكون له آراء، وأن العرف يغلب الإعداد لأغلب الفرق، وأن تجربة المطوّر هدف هندسي مشروع لا رفاهية.

كان ذلك قبل خمسة عشر عامًا. ومقارنتهما اليوم بتلك المصطلحات تُفوّت ما يفصلهما فعلًا.

فيمَ يتفقان حتى الآن

كلاهما كامل المنظومة وذو آراء. وكلاهما يستخدم السجل النشط. ولكليهما هجرات وسطر أوامر قوي وثقافة اختبار ناضجة وبنية مجلدات يمكن توقعها قبل فتح المستودع.

ومن يتقن أحدهما يقرأ شيفرة الآخر بارتياح خلال أسبوع. وذلك غير معتاد بين أنظمة بيئية ويستحق الذكر قبل الفروق.

العمل الخلفي أكبر فجوة عملية

نظام طوابير Laravel جزء من الإطار: مشغّلات، وإعادات محاولة بتباعد، وتجميع، ومهام فريدة، وحدود معدل، وجدول للمهام الفاشلة، ولوحة - كلها موثَّقة معًا ومُصدَّرة معًا.

ولدى Rails الـ Active Job كتجريد وتحته محوّل، غالبًا Sidekiq، وهو ممتاز ومنتج منفصل بطبقاته المدفوعة للميزات التي قد تريدها.

كلا الترتيبين يعمل. والفرق كم قرارًا وكم نظامًا تملك، ولفريق صغير يهم ذلك أكثر من مصفوفة الميزات.

الأنواع والأدوات

نمَا نظام الأنواع في PHP باطّراد وشيفرة Laravel الحديثة مكتوبة بأنواع من طرف إلى طرف. والتحليل الساكن على شيفرة Laravel ناضج وجزء روتيني من التكامل المستمر.

وقصة الأنواع في Ruby أحدث وأقل استقرارًا عمليًا. وإن كنت تقدّر مدقق أنواع يتعاون معه أغلب النظام البيئي، فـ PHP متقدم حاليًا - وهي جملة ما كان أحد ليكتبها قبل عقد.

اقتصاد الاستضافة

PHP يُنشر على أي شيء. خادم متواضع واحد يشغّل تطبيق Laravel مع عمّال طوابيره ومجدوله، والمنصات المُدارة المبنية له تحديدًا رخيصة.

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

التوظيف، وهي الحجة التي تفوز عادةً

مجتمع PHP وLaravel أكبر بكثير، عالميًا وعبر مستويات خبرة أكثر. ومجتمع Rails أصغر ويميل إلى الأقدم خبرةً - فالناس ممتازون غالبًا وهم أقل عددًا وأعلى سعرًا.

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

أين يتقدّم Rails فعلًا

عمق الأعراف. يستقر Rails على أعرافه منذ مدة أطول، وجواب "أين يذهب هذا" متفق عليه أكثر. ويمنحك Laravel حرية أكبر، على الفرق الكبيرة تحويلها بنفسها إلى قواعد مكتوبة.

قصة الواجهة الأمامية. Hotwire وTurbo جواب متماسك وناضج لبناء تطبيقات تفاعلية بلا منظومة واجهة منفصلة. وبدائل Laravel المكافئة جيدة وهي عدة، أي قرار يملك Rails فيه افتراضًا.

نضج مسار الترقية. تاريخ إصدارات Rails الطويل يعني أن أعراف ترقيته مطروقة جدًا. وإيقاع Laravel السنوي متوقَّع وأقل تسامحًا مع التأخر.

الاختيار بينهما اليوم

إن كان لديك فريق في أحدهما، فذلك هو الجواب، والهامش ليس متقاربًا.

وإن كنت تبدأ من الصفر بلا تفضيل: Laravel إن كنت تتوقع التوظيف والنمو، أو إن كان العمل الخلفي محوريًا، أو إن كانت كلفة الاستضافة في الحجم الصغير تهم. وRails إن كنت تريد أكثر الأعراف استقرارًا المتاحة وجوابًا من الطرف الأول للواجهات التفاعلية.

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

داخل PHP يدور الجدل نفسه حول العرف والرأي في مواجهة Symfony، وهي المقارنة الأقرب بعد حسم اللغة. وإن كان الشك الحقيقي في شكل إطار العمل لا في أيّها، فثمة صفحة لذلك.