Next.js مقابل Remix: القرار يدور حول التخزين المؤقّت
كلاهما يعرض على الخادم، وكلاهما يدعم التوجيه المتداخل، وكلاهما جيّد. أما الفرق الذي يظهر فعلًا داخل قاعدة الشيفرة فهو كيف يتعامل كلٌّ منهما مع البيانات المخزّنة مؤقّتًا.
يُقارَن هذان الإطاران باستمرار، والمقارنات في الغالب جدول مزايا. وليست هذه هي الطريقة التي يسوء بها هذا القرار عمليًا.
الفرق الذي يظهر بعد ثمانية عشر شهرًا هو ما يفترضه كل إطار عن بياناتكم.
يفترض Remix أن بياناتكم طازجة
نموذج Remix هو loader لكل مسار يعمل مع كل طلب. تُجلب البيانات، وتُعرض الصفحة، وتخرج الاستجابة. أما التخزين المؤقّت فشيء تضيفونه عن قصد: ترويسات HTTP، أو شبكة توصيل أمامها، أو طبقة من عندكم.
والنتيجة أن تطبيقات Remix تميل إلى أن تكون صحيحة افتراضيًا وأبطأ افتراضيًا. لا شيء قديم لأن لا شيء مخزَّن حتى تخزّنوه. وحين يبطؤ شيء، يكون السبب مرئيًا غالبًا: loader يفعل أكثر مما ينبغي.
يفترض Next.js أن بياناتكم قابلة للتخزين
نموذج Next.js هو العكس. المسارات ثابتة ما لم يدفعها شيء إلى الديناميكية،
ولـ fetch دلالات تخزين ملتصقة به، وهناك
أربع طبقات تخزين مؤقّت متمايزة تعمل في آنٍ
واحد.
والنتيجة أن تطبيقات Next.js تميل إلى أن تكون سريعة افتراضيًا وخاطئة أحيانًا. أكثر عطل إنتاجي نجده ليس البطء، بل صفحة تقدّم بيانات من طبقة لم يتذكّر أحد وجودها.
هذه هي المقايضة، بصراحة:
| Remix | Next.js | |
|---|---|---|
| الافتراضي | طازج، وقت الطلب | مخزَّن، وقت البناء |
| العطل النموذجي | بطء لأن loader يفعل أكثر من اللازم | قِدَم لأن طبقة تخزين نُسيت |
| ما تضبطونه | إضافة تخزين | إزالة ديناميكية غير مقصودة |
| التشخيص | قراءة الـ loader | معرفة أيّ الطبقات الأربع أجابت |
لا أحدهما أفضل. يفشلان في اتجاهين مختلفين، وينبغي أن تختاروا الاتجاه الذي سيلاحظه فريقكم.
الفرق الحقيقي الثاني: أين يقع الحدّ
يُبقي Remix الفصل بين الخادم والعميل على مستوى المسار: الـ loaders والـ actions على الخادم، والمكوّنات على العميل. خطّ بسيط يسهل الاحتفاظ به في الذهن.
أما Next.js فيرسمه لكل مكوّن عبر Server Components، وهو أقوى وأدقّ. إن أُحسن
استخدامه فالحزمة لا تحوي إلا ما هو تفاعلي، وإن أُهمل فإن 'use client' واحدة
ترسل نصف الشجرة إلى المتصفّح، و
الكلفة غير مرئية حتى يقيسها أحد.
إن كان فريقكم متمرّسًا في React ومستعدًّا للحفاظ على ذلك الخطّ، فنموذج Next.js يفوز فيما ينزّله المستخدمون. وإن لم يكن كذلك، فالفصل الأبسط في Remix سينتج تطبيقًا أفضل، لأن نموذجًا يطبّقه الناس تطبيقًا صحيحًا يتفوّق على نموذج أفضل يُطبَّق بإهمال.
ما لا ينبغي أن يحسم الأمر
اختبارات الأداء. كلاهما سريع بما يكفي ليكون المهيمن قاعدةَ بياناتكم وصوركم.
أيّهما أكثر شعبية. Next.js كذلك، والشعبية لا تهمّ إلا بقدر ما تعني أشخاصًا أكثر للتوظيف وإجابات أكثر للبحث. حجّة حقيقية، لكنها ليست تقنية.
أيّهما أفضل في النشر. كلاهما يُنشر على Node في أي مكان. والارتباط بمنصّة الذي يقلق الناس قرارُ إعدادٍ لا خاصيةَ إطار عمل - الاستضافة الذاتية لـ Next.js تعمل، وأشياء بعينها تتوقّف عن العمل، وهذا صحيح في البديل أيضًا.
الخلاصة الصادقة
اختاروا Remix إن أردتم نموذجًا ذهنيًا بسيطًا يعمل وقت الطلب، وتفضّلون إضافة السرعة على إزالة القِدَم.
واختاروا Next.js إن كان محتواكم قابلًا للتخزين وأردتم ذلك بلا كلفة، وكان لديكم من يحافظ على نزاهة حدّ العميل.
وإن لم يصف أيٌّ من هذين مشروعكم، فقد لا يكون إطار العمل هو السؤال أصلًا.