‏Next.js مقابل Remix: القرار يدور حول التخزين المؤقّت

يُقارَن هذان الإطاران باستمرار، والمقارنات في الغالب جدول مزايا. وليست هذه هي الطريقة التي يسوء بها هذا القرار عمليًا.

الفرق الذي يظهر بعد ثمانية عشر شهرًا هو ما يفترضه كل إطار عن بياناتكم.

يفترض Remix أن بياناتكم طازجة

نموذج Remix هو loader لكل مسار يعمل مع كل طلب. تُجلب البيانات، وتُعرض الصفحة، وتخرج الاستجابة. أما التخزين المؤقّت فشيء تضيفونه عن قصد: ترويسات HTTP، أو شبكة توصيل أمامها، أو طبقة من عندكم.

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

يفترض Next.js أن بياناتكم قابلة للتخزين

نموذج Next.js هو العكس. المسارات ثابتة ما لم يدفعها شيء إلى الديناميكية، ولـ fetch دلالات تخزين ملتصقة به، وهناك أربع طبقات تخزين مؤقّت متمايزة تعمل في آنٍ واحد.

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

هذه هي المقايضة، بصراحة:

لا أحدهما أفضل. يفشلان في اتجاهين مختلفين، وينبغي أن تختاروا الاتجاه الذي سيلاحظه فريقكم.

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

الفرق الحقيقي الثاني: أين يقع الحدّ

يُبقي Remix الفصل بين الخادم والعميل على مستوى المسار: الـ loaders والـ actions على الخادم، والمكوّنات على العميل. خطّ بسيط يسهل الاحتفاظ به في الذهن.

أما Next.js فيرسمه لكل مكوّن عبر Server Components، وهو أقوى وأدقّ. إن أُحسن استخدامه فالحزمة لا تحوي إلا ما هو تفاعلي، وإن أُهمل فإن 'use client' واحدة ترسل نصف الشجرة إلى المتصفّح، و الكلفة غير مرئية حتى يقيسها أحد.

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

التعديلات، وفيها يبدو النموذجان أشدّ اختلافًا

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

وجواب Next.js هو Server Action: دالّة مُعلَّمة لتعمل على الخادم وتُستدعى كأي دالّة أخرى. مراسم أقلّ وأجزاء متحرّكة أقلّ، مع حكاية أضعف بلا JavaScript - فالنموذج الموصول بـaction يعمل دون ترطيب في الحالات البسيطة، ويكفّ عن ذلك حالما تصير المعالجة مثيرة للاهتمام.

وكلاهما ينتهي إلى المكان نفسه في معظم التطبيقات. الفرق هو ما تحصلون عليه مجّانًا حين يسوء شيء على العميل، وهل يعنيكم ذلك.

ما لا ينبغي أن يحسم الأمر

اختبارات الأداء. كلاهما سريع بما يكفي ليكون المهيمن قاعدةَ بياناتكم وصوركم.

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

أيّهما أفضل في النشر. كلاهما يُنشر على Node في أي مكان. والارتباط بمنصّة الذي يقلق الناس قرارُ إعدادٍ لا خاصيةَ إطار عمل - الاستضافة الذاتية لـ Next.js تعمل، وأشياء بعينها تتوقّف عن العمل، وهذا صحيح في البديل أيضًا.

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

الخلاصة الصادقة

اختاروا Remix إن أردتم نموذجًا ذهنيًا بسيطًا يعمل وقت الطلب، وتفضّلون إضافة السرعة على إزالة القِدَم.

واختاروا Next.js إن كان محتواكم قابلًا للتخزين وأردتم ذلك بلا كلفة، وكان لديكم من يحافظ على نزاهة حدّ العميل.

وإن لم يصف أيٌّ من هذين مشروعكم، فقد لا يكون إطار العمل هو السؤال أصلًا.