مرّتين خلال العام الماضي، جاءنا مؤسسان يحملان تطبيق Flutter نصف مكتمل، ومعهما القصة نفسها: أحبّت الوكالة الأصلية لغة Flutter، وأطلقت بسرعة، ثم اختفت. والآن لم يعد أحد في سوق التوظيف في مدينتيهما قادرًا على صيانته. كانت الشيفرة سليمة. لكن القرار هو الخلل.
الاعتقاد الشائع
عرض Flutter جذّاب فعلًا: شيفرة واحدة، وعرض بصري جميل، وإعادة تحميل فورية تجعل العروض التوضيحية تتألق. وبالنسبة إلى وكالة تسعى لتحسين سرعتها الخاصة، فهو خيار منطقي. الإطار ليس سيئًا — وليست هذه حجّتنا.
اختر المنصة التي يتقنها موظفوك الثلاثة المقبلون بالفعل، لا تلك التي تستمتع بها وكالتك.
حجّتنا
نختار المنصات بناءً على الفريق الذي ستملكه بعد ثلاث سنوات، لا على العرض التوضيحي للشهر المقبل. في دول الخليج وغالبية الأسواق الغربية، تتعمّق كفاءات سوق التوظيف في JavaScript: استخدام React على الويب يعني أن React Native على الجوال يتيح لفريق واحد — ونموذج ذهني واحد — تغطية المنصتين معًا. أما Dart فتظل مهارة أحادية الغرض توظّف من أجلها خصيصًا.
ثانيًا، الويب أهم مما يعترف به المتعصبون لتعدد المنصات. يحتاج معظم عملائنا إلى تطبيق + موقع ويب + موقع تسويقي يتشاركون المنطق ورموز التصميم. يحقق دمج React Native مع Next.js مشاركة فعّالة؛ بينما يظل Flutter Web أضعف واجهة في الإطار.
وحين يتطلّب التطبيق فعلًا أمانة كاملة للمنصة — حركات معقّدة، وعناصر واجهة، وتطبيقات للساعات الذكية، وأحدث واجهات برمجة نظام التشغيل في يوم الإطلاق — نلجأ إلى التطوير الأصلي بالكامل بلغتي Swift/Kotlin بدلًا من الاعتماد على أي طبقة لتعدد المنصات إطلاقًا. تعدد المنصات قرار يتعلق بالتكلفة؛ والتطوير الأصلي قرار يتعلق بالجودة؛ أما Flutter فيجلس بشكل محرج بين الاثنين.
متى يظل Flutter هو الخيار الصحيح
فريق Dart قائم بالفعل. هدف واجهة عتاد/أنظمة مدمجة. سوق تتوفر فيه كفاءات Flutter بوفرة حقيقية. إن كان هذا حالك، فإن Flutter إجابة جيدة — وسنقول ذلك في جلسة تحديد النطاق، حتى وإن لم نكن نحن من سيتولّى تطويره.
- اختيار المنصة قرار توظيف يرتدي زيًّا تقنيًا.
- أحصِ الواجهات: إذا كان الويب مهمًّا، فإن المشاركة عبر منصة JS تكسب.
- اعتمد التطوير الأصلي بالكامل حين تكون الأمانة هي الغاية — وتجاوز الحلول الوسطى.