أي حزمة تقنية لأي مشروع

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

وهذا ما يحسمه فعلاً.

أين يجب أن يعمل

هذا هو القيد الذي لا يتوقّعه أحد، وهو الذي يستبعد الخيارات أسرع من غيره.

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

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

من سيصونه بعد رحيلنا

السؤال الثاني، وهو أهم من أي قياس أداء.

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

في الحالتين الجواب عن الناس لا عن الأداء.

ما يجب أن يفعله فعلاً

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

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

ما نلجأ إليه، ومتى

عملنا على الويب يسير في مسارين، والانقسام يتبع سؤال الاستضافة أعلاه.

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

ويذهب Next.js مع React حيث تكون الواجهة هي المنتج. أي شيء تفاعلي بدرجة عالية، أي شيء له حالة حقيقية تُدار في المتصفّح، أي شيء تهمّ فيه سرعة الصفحة وظهورها في البحث معاً. هذا الموقع يعمل عليه، وكذلك نموذج لوحة التحكّم لدينا، لأن مخطّطاً بمؤشّر تقاطعي وتنقّل بلوحة المفاتيح هو تحديداً ما وُجدت هذه الحزمة من أجله وتحديداً ما يصبح مؤلماً بدونها.

نكتب TypeScript بدل JavaScript المجرّدة في كل ما نتوقّع أننا سنظلّ نحرّره العام المقبل. القيمة ليست أخطاء أقل في اليوم الأول. القيمة أن تعديلاً بعد ستة أشهر يخبرك فوراً بما كسره للتوّ.

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

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

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

ويظهر C++ حيث يكون العمل برمجية سطح مكتب أو يحمل متطلبات أداء لا تستطيع حزمة ويب تلبيتها. إنه جواب متخصّص لسؤال متخصّص، ولا ينبغي أن يكون جواباً لسؤال اعتيادي أبداً.

ويظهر Docker حين يكون للمشروع أكثر من جزء متحرّك، أو حين يبدأ الفارق بين جهازنا والخادم بتكليف وقت حقيقي.

السؤال الأجدر بالطرح

بدل أي تقنية، اسأل ماذا يحدث بعد ثلاث سنوات.

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

وأي استوديو يجيب عن سؤال "أي حزمة" بالكلمة نفسها في كل مرة، مهما وصفت، إنما يخبرك عن طاقمه هو لا عن مشروعك أنت.