متى لا ينبغي استخدام Next.js

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

خمس حالات. في كلٍّ منها سنقول لكم ذلك بدل أن نقبل المشروع.

1. موقع محتوى لا تطبيق فيه

موقع تعريفي، أو مجموعة توثيق، أو موقع تسويقي بمدوّنة. إن لم يكن فيه شيء تفاعلي يتجاوز نموذج تواصل وقائمة تنقّل، فإن Next.js آلةٌ ضخمة لإنتاج HTML.

سينتج Astro أو Eleventy أو Hugo المخرجات نفسها بجزء يسير من الجافاسكربت، وببناءٍ تستطيعون شرحه لأي شخص. نموذج مكوّنات React يبدأ في تسديد ثمنه حين يوجد حالة تُدار وسلوك مشترك يُعاد استخدامه. أما دون ذلك الحدّ فهو عبءٌ تصونونه إلى الأبد.

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

ووراء هذا رقم لا شعور. مسار Next.js يُرسل زمن تشغيل React وApp Router سواء استعملته الصفحة أم لا - وعلى هذا الموقع، الذي لا يُرسل شيفرة عميل خاصة به على أي مسار، تبلغ تلك الأرضية نحو 186 كيلوبايت مضغوطة. أما صفحة Astro المكافئة فلا تُرسل شيئًا حتى تطلبوا شيئًا. وإن لم يكن في الصفحة تفاعل يُبرّر زمن التشغيل هذا، فأنتم تدفعونه في كل زيارة أولى مقابل نموذج مكوّنات لا تستعملونه. المقارنة الكاملة تدور حول سؤال واحد: كم نسبة صفحتكم عليها أن تفعل شيئًا بعد التحميل.

2. الفريق لا يكتب React

هذه النقطة أقلّ ما يرتاح الناس لقوله بصوت مرتفع.

إطار عمل تتقنونه يتفوّق على إطار أفضل تتعلّمونه، في أي مشروع له موعد تسليم. الفريق الذي يسلّم بـ Laravel أو Rails أو Django بثقة سينتج بها تطبيقًا أفضل من تطبيق Next.js كفؤ يُبنى أثناء قراءة التوثيق، وسيصونه سنوات دون أخصّائي.

واختيار Next.js اختيارٌ كذلك لوتيرة تغيّره. فقد تحرّك App Router و Server Components ونموذج التخزين المؤقّت تحرّكًا كبيرًا في ثلاث سنوات، و الإصدار 16 حرّك الـ middleware و Turbopack وقيم الصور الافتراضية من جديد. هذه الوتيرة محتملة مع شخص يتابعها، ومكلفة بدونه.

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

3. العمل المثير كله في الخلفية

محرّك مدفوعات، أو خطّ بيانات، أو نظام جدولة، أو واجهة برمجية لها عشرات المستهلكين. في Next.js معالِجات مسارات و Server Actions، وهي جيدة فيما وُجدت له: خدمة واجهة أمامية. وليست بديلًا عن خادم تطبيقات.

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

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

4. تحتاجون الحافة ولا تستطيعون الحصول عليها

اتّجه Next.js نحو Node في العمل الذي يجري وقت الطلب. ففي الإصدار 16 يعمل اصطلاح proxy الذي حلّ محلّ middleware على Node، و بيئة التشغيل غير قابلة للضبط.

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

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

5. أداة تفاعلية واحدة على موقع شخص آخر

حاسبة أسعار تُدرَج في صفحة ووردبريس. نموذج حجز مضمَّن في نظام محتوى لا تتحكّمون به. Next.js إطار عمل لامتلاك موقع كامل؛ فإن كنتم تملكون <div> واحدًا، سلّموا حزمة صغيرة - جافاسكربت عادي، أو Preact، أو web component - وتجاوزوا التوجيه ونموذج العرض وهدف النشر تمامًا.

كيف تعرفون في أيّ الحالات أنتم

ثلاثة أسئلة، بهذا الترتيب. والترتيب مقصود، لأن الأول يستبعد من المشاريع أكثر ممّا يستبعده الآخران معًا.

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

والسؤال الثاني هو ما تجيب عنه الفرق بسرعة زائدة، لأن التكامل يبدو نداء fetch إلى أن يُبنى. وأين تعمل قطعه فعلًا يستحق القراءة قبل الحكم بأن الواجهة الأمامية تستطيع حملها كلها.

وإن كنتم تختارون بين شيئين محدّدين بدل طرح السؤال العام، فالمقارنة المخصّصة أنفع عادةً من هذه الصفحة: مقابل Astro إن كان السؤال كم JavaScript ينبغي أن يُرسل موقع محتوى، ومقابل Remix إن كنتم قد حسمتم أمركم على إطار React، ومقابل Laravel إن كان خلف التطبيق مكتب خلفي حقيقي، ومقابل Express إن كان ما تبنونه في الحقيقة واجهة برمجية.

وأين يكون الجواب الصحيح فعلًا

للاكتمال، لأن القائمة أعلاه ليست حجّةً ضدّ إطار العمل:

• تطبيق له سطح عامّ قابل للفهرسة و سطح خلف تسجيل الدخول. عرض الاثنين عرضًا جيدًا من قاعدة شيفرة واحدة هو ما يفعله Next.js ولا تفعله البدائل غالبًا.
• التجارة الإلكترونية، حيث يجب أن يكون الكتالوج ثابتًا وسريعًا وألّا تكون السلّة كذلك.
• كل حالة تكون فيها Core Web Vitals رقمًا تجاريًا لا بطاقة تقييم، وتحتاجون فيها التحكّم بمسار العرض لتحريكه.

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

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