عبدالله سنكر يقارن: Next.js أو Flutter Web لموقعك؟

يجيك مطوّر يقول: «بما إن تطبيقك بـ Flutter، نطلع الموقع من نفس الكود ونوفّر». ويجيك ثاني يقول: «لا، الموقع لازم Next.js». الاثنين عندهم جزء من الحق. عبدالله سنكر يشتغل بالأداتين: Flutter و Dart للتطبيقات، و Next.js و TypeScript للمواقع، وموقع azhal.io نفسه مبني بـ Next.js. هذي مقارنته بالمعايير اللي تفرق فعلاً لصاحب المشروع، مو للمبرمج.

الفرق الجوهري في سطرين

Next.js إطار مبني فوق React، يطلع صفحات HTML حقيقية، يقدر يجهّزها على الخادم قبل ما توصل للمتصفح أو يبنيها مسبقاً وقت النشر. Flutter Web يشغّل تطبيق Flutter داخل المتصفح، ويرسم الواجهة بنفسه على مساحة رسم، بدل ما يعتمد على عناصر الصفحة العادية. هذا الفرق الواحد يفسّر تقريباً كل النقاط الجاية. Next.js يتعامل مع المتصفح بلغته الأصلية، فيستفيد من كل شي بناه المتصفح عبر السنين: الروابط، وزر الرجوع، والبحث داخل الصفحة. و Flutter Web يجيب معه عالمه الخاص، ويعيد بناء كثير من هذي الأشياء بطريقته.

محركات البحث: الفيصل الأول

لو موقعك يعيش على زيارات جوجل — صفحات خدمات، أو مدونة، أو متجر، أو صفحات منتجات — فـ Next.js يتقدم بوضوح. الصفحة توصل لزاحف جوجل نصاً جاهزاً بعناوينه وروابطه، وتقدر تتحكم في عنوان كل صفحة ووصفها وبياناتها المنظّمة وخريطة الموقع. أما في Flutter Web فالمحتوى يتولّد بعد ما يتحمّل التطبيق ويشتغل، وهذا يصعّب الأرشفة ويخرّب معاينة الرابط لما ينشارك في واتساب أو إكس. فيه حلول التفافية، لكنها ترقيع لشي ما انبنى له الإطار من الأساس.

أول تحميل: الثواني اللي تقرر إذا يكمل الزائر

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

وين يكسب Flutter Web فعلاً

مو كل شي على الويب «موقع». فيه حالات يكون فيها Flutter Web اختياراً ممتازاً، وأحياناً الأذكى:

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

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

المقارنة نقطة نقطة

• الظهور في البحث: Next.js قوي جداً، و Flutter Web ضعيف.
• سرعة أول ظهور: Next.js أسرع غالباً، و Flutter Web أثقل في البداية.
• مشاركة الكود مع تطبيق الجوال: Flutter Web يشارك جزءاً كبيراً، و Next.js ما يشارك شي مع تطبيق Flutter.
• تحديد النص ونسخه وترجمة الصفحة من المتصفح: طبيعي في Next.js، وفي Flutter Web يحتاج انتباهاً من المطوّر.
• قارئات الشاشة وإمكانية الوصول: عناصر HTML الحقيقية تخدمها افتراضياً، و Flutter يبني لها طبقة دلالية منفصلة لازم تُضبط.
• الواجهات التفاعلية الكثيفة: Flutter Web مريح فيها، و Next.js يقدر لكن بجهد أكبر في بعض الحالات.

وفيه بُعد عملي ثاني: الفريق. لو عندك مطوّر Flutter يبني تطبيقك، فلوحة التحكم بـ Flutter Web ما تحتاج منه يتعلم شي جديد، والنماذج والتحقق من البيانات والاتصال بالخادم مكتوبة جاهزة. هذا توفير حقيقي، لكنه توفير في الأدوات الداخلية، مو في الواجهة اللي يشوفها عملاؤك الجدد.

القرار العملي

الصيغة اللي ينصح فيها عبدالله عبدالرحيم بن سنكر الكندي أغلب أصحاب المشاريع بسيطة: الموقع التسويقي اللي يجيب العملاء بـ Next.js، والتطبيق ولوحة التحكم بـ Flutter. صحيح إنها تقنيتين، لكن كل وحدة في مكانها، والاثنتين تقدر تتصل بنفس الخادم ونفس قاعدة البيانات، فالاختلاف في الواجهة بس. والتوفير الوهمي من «كود واحد لكل شي» يرجع لك تكلفة مضاعفة يوم تكتشف إن موقعك ما يظهر في البحث، وتضطر تعيد بناءه.

وفي منصة أزهل الرقمية السؤال اللي يسبق اختيار التقنية دايماً: مين بيزور هذي الصفحة، ومن وين جاي؟ إذا الجواب «غريب جاي من جوجل أو من إعلان»، اختر Next.js. وإذا «مستخدم مسجّل جاي يشتغل»، فـ Flutter Web خيار محترم. والخطأ الوحيد اللي يتكرر هو إنك تختار قبل ما تسأل.