فلاتر أم ريأكت نيتيف

أين يقع الفرق الحقيقي بينهما؟

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

إذن طريقان مختلفان إلى الصورة نفسها. فلاتر يتصرف كمحرك ألعاب: يأخذ لوحته ويرسم كل شيء عليها. ووثائق فلاتر نفسها تعقد هذه المقارنة حين تشرح أن كود دارت على iOS يُترجم مسبقاً إلى مكتبة ARM أصلية تجلس داخل مشروع runner. أما ريأكت نيتيف فيتصرف كسائق: لا يرسم شيئاً بنفسه ويقول لعروض المنصة ماذا تفعل.

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

أيهما أفضل؟ لا أحد. فهما جوابان لسؤالين مختلفين، وبقية هذا الدرس عن أي السؤالين سؤالك أنت.

دارت أم جافاسكريبت: أيهما أرخص لفريقك؟

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

وريأكت نيتيف مكتوب بجافاسكريبت مع ريأكت. وتقول وثائقه إنك تستعمل جافاسكريبت للوصول إلى واجهات المنصة ولوصف مظهر واجهتك وسلوكها بمكوّنات ريأكت في آن.

والآن السؤال العملي: أيهما أرخص لك؟ الجواب دائماً تقريباً هو ما يعرفه فريقك. فإن كان لديك مطورو ويب يكتبون ريأكت فإن ريأكت نيتيف يعمل من اليوم الأول تقريباً وينتقل جزء كبير من العادات والأدوات. وإن لم يكن لفريقك خلفية ويب وكان يبدأ من الصفر فدارت لغة صغيرة وتعلّمها ليس أصعب من جافاسكريبت؛ وفي تلك الحالة ليس هذا المحور هو القرار.

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

كيف نحكم على المنظومة دون الاتكاء على رقم بلا مصدر؟

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

فاكتب قائمتك أنت. بوابة دفع وخرائط وإشعارات وكاميرا ومسح باركود وتسجيل دخول بحساب، أياً كان. ثم ابحث عن كل واحدة في سجل الحزم لتلك المنظومة: pub.dev لدارت وفلاتر، وnpm لجافاسكريبت.

وانظر في كل حزمة إلى ثلاثة أشياء لا يجدها عدّ النجوم. الأول تاريخ آخر إصدار؛ فالحزمة التي لم يُنشر لها شيء منذ سنة تصير مشكلتك في نسخة النظام التالية. والثاني هل تغلّف الحزمة SDK أصلياً أم تعيد تنفيذه؛ فالتي تغلّف الـSDK الرسمي تجاري تحديثه عادةً. والثالث هل المسائل المفتوحة تخص المنصة التي تهمك فعلاً.

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

فأيهما أختار؟

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

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

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