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

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

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

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

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

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

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

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".

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

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

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

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

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

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

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

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

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