Remix 3 بدون React ؟! القصة الكاملة وراء أجرأ قرار في عالم الويب

هل تتخيل أن إطار عمل بُني أساساً على React، واشتهر بفضل React، وكان يُعتبر من أفضل البدائل لـ Next.js.. يقرر فجأة أن يتخلى عن React بالكامل ويعيد بناء نفسه من الصفر ؟ 🤔

هذا بالضبط ما حدث مع Remix 3.

في شهر ماي 2025، نشر فريق Remix مقالاً بعنوان “Wake up, Remix!” أو ”استيقظ يا ريمكس!” أعلنوا فيه أن النسخة الثالثة لن تكون مجرد تحديث عادي، بل إعادة بناء جذرية بفلسفة مختلفة تماماً. لا React، لا Virtual DOM بالشكل الذي نعرفه، ولا حتى مسار ترقية من النسخة السابقة. المسألة ليست Version Bump عادي.. بل ولادة جديدة تماما.

في هذا المقال سأحاول أن أشرح لكم لماذا اتخذ فريق Remix هذا القرار الجريء، ما هي الفلسفة الجديدة التي يتبناها الإطار، وماذا يعني كل هذا للمطورين المهتمين بريمكس.

ما هو Remix أصلاً ؟

لمن لا يعرف Remix، فهو إطار عمل Full-Stack لتطوير الويب أنشأه Ryan Florence و Michael Jackson، وهما نفس الشخصين اللذين طورا المكتبة الشهيرة React Router. نعم، الأمر ليس مصادفة، فالعلاقة بين Remix و React Router كانت دائماً وثيقة جداً.

بنى Remix سمعته، منذ انطلاقته كمشروع مفتوح المصدر سنة 2021، على فكرة بسيطة وقوية : استغلال معايير الويب الأصلية (Web Standards) بدل إعادة اختراع العجلة. استخدم الـ Loaders و Actions و Nested Routing لتقديم تجربة تطوير سلسة، وكان يُعتبر منافساً جدياً لـ Next.js في منظومة React.

لكن بحلول أواخر 2024، حدث شيء مثير : معظم المزايا التي جعلت Remix فريداً مثل الـ Loaders، Actions و Nested Routing تم دمجها مباشرة في الإصدار السابع من React Router.

بعد ذلك أصبح من الصعب رؤية حدود واضحة بين ما هو Remix وما هو React Router! الإثنين يشيران لنفس الشيء تقريبا، وهو ما دفع القائمين على هذين المشروعين إلى توجيه المطورين بترقية مشاريعهم المبنية على Remix 2 إلى React Router 7 الذي سيشكل الإمتداد المستقبلي لريمكس 2 وكل ما له علاقة بإطار العمل Full-Stack المبني على مكتبة React.

كثيرون ظنوا أن هذه نهاية Remix. لكن الفريق كان يخطط لشيء كبير قادم.

لماذا التخلي عن React ؟

السؤال الذي يطرح نفسه بقوة : لماذا يتخلى فريق كامل عن React وهي المكتبة الأكثر استخداماً في العالم ؟ هل هم مجانين ؟ 😅

الحقيقة أن لديهم أسبابهم، ويمكن تلخيصها في عدة نقاط :

التعقيد المتزايد لـ React

Ryan Florence و Michael Jackson كانا من أوائل المساهمين في منظومة React منذ بداياتها. لأكثر من عقد كامل، كان العمل مع React يشبه تسلق جبل 🧗‍♂️ كل فترة تظهر أنماط جديدة يجب تعلمها : Class Components ثم Hooks ثم Server Components ثم use client و use server ثم Suspense… والقائمة تطول.

وصل الفريق إلى قمة هذا الجبل، نظروا حولهم، ورأوا جبلاً آخر يبدو أفضل وأبسط. هذا التشبيه بالضبط هو ما استخدمه الفريق في مؤتمر Remix Jam 2025 لشرح قرارهم.

الإعتماد على طرف لا يتحكمون فيه

أحد المبادئ الأساسية لـ Remix 3 هو : “Avoid Dependencies” أو تجنب الاعتمادات. فريق Remix لا يتحكم في خارطة طريق React. أي تغيير جذري في React يمكن أن يكسر Remix بالكامل. لذلك قرروا أن يملكوا الـ Stack بالكامل بدون الاعتماد على طبقات من التجريد (Abstractions) لا يتحكمون فيها.

الويب تطور كثيراً منذ ظهور React

عندما ظهرت React سنة 2013، كان الويب مختلفاً تماماً. لم تكن الـ Fetch API موجودة، ولا Web Streams، ولا View Transitions، ولا حتى ES Modules بالشكل الحالي. اليوم، المتصفحات وبيئات تشغيل الـ JavaScript أصبحت قوية جداً. الكثير مما كانت تفعله React لنا أصبح متاحاً بشكل أصلي في المنصة نفسها.

المبادئ الأربعة لـ Remix 3

الفريق حدد أربعة مبادئ توجيهية لتطوير Remix 3. ثلاثة منها منطقية ومقبولة عند الجميع تقريباً، والرابع أثار جدلاً واسعاً. لنتعرف عليها :

1. التطوير بمنطق الذكاء الاصطناعي أولاً (Model-First Development)

هذا هو المبدأ المثير للجدل 🔥

الفكرة هي أن الكود المصدري والوثائق والأدوات يجب أن تكون مُحسّنة لكي تفهمها وتكتبها الـ LLMs (النماذج اللغوية الكبيرة مثل GPT وClaude). بمعنى آخر : تصميم الـ Framework بحيث يكون “LLM-Friendly”.

الانتقادات كانت حادة. البعض رأى أن هذا مجرد ركوب لموجة الـ AI لجذب المستثمرين.

لكن إذا فكرنا في الأمر بعمق، فإن ما يسهل على الـ LLM فهمه يسهل غالباً على الإنسان فهمه أيضاً. الـ LLMs تعاني مع الكود المعقد والمتداخل، وكذلك المطورون. في عرضه الحي في Remix Jam، طلب Ryan Florence من الـ Cursor توليد كود عادي بدون أي معرفة بالـ Framework، ونجح في دمجه مباشرة في التطبيق. الفكرة إذن هي تقليل الـ Domain-Specific Language قدر الإمكان.

هذا يتناقض بشكل صارخ مع الأطر الأخرى التي اتجهت نحو إنشاء Primitives خاصة بها (مثل Signals وRunes عند Svelte وغيرها).

Remix 3 يراهن على أن البساطة والكود العادي أفضل من التجريدات الذكية.

2. البناء على واجهات الويب الأصلية (Build on Web APIs)

بدل اختراع تجريدات جديدة، يُبنى Remix 3 مباشرة على Web APIs القياسية:

Request
Response
FormData
CustomEvent
URL
AbortSignal
…

الهدف أن تتعلم الويب نفسه وليس إطار العمل فقط.

الفريق يصف هذا بأنه بناء “the web, but with a framework” وليس “a framework that happens to run on the web”.

الفرق دقيق لكنه مهم جداً.

3. بيئة التشغيل أولا (Religiously Runtime)

فريق Remix يرى أن التصميم من أجل الـ Bundlers و Compilers و Type Generators (أي كل ما يحدث قبل وقت التشغيل) يؤدي إلى تصميم APIs سيئة تنتشر كالعدوى في كل النظام.

Remix 3 يريد أن يكون Runtime-First بدون خطوة Build معقدة. يعدون بـ “Zero Build Time” وأداء فائق السرعة من خلال التنفيذ المباشر على الـ Edge.

4. تجنب الإعتماديات التي تثقل الكاهل (Avoid Dependencies)

كما ذكرنا، الهدف هو امتلاك أكبر قدر ممكن من الـ Stack. بدأوا بعمل Fork من Preact، وهي مكتبة Virtual DOM خفيفة ومستقرة تُستخدم بالفعل في Shopify و Google وغيرها… ثم بنوا فوقها نموذج Components خاص بهم.

كيف يبدو الكود في Remix 3 ؟

لنقارن مكون Counter بسيط بين React و Remix 3 :

في React :

import { useState } from "react";
 
function Counter() {
  const [count, setCount] = useState(0);
 
  return (
    <div>
      <div>{count}</div>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

في Remix 3 :

function Counter(this: Remix.Handle) {
  let count = 0;
 
  return () => (
    <div>
      <div>{count}</div>
      <button
        onClick={() => {
          count++;
          this.update();
        }}
      >
        Increment
      </button>
    </div>
  );
}

لاحظوا الفروقات 👀

أولاً، لا يوجد useState. المتغير count هو مجرد Closure Variable عادي. ثانياً، التحديث يتم بشكل صريح (Explicit) عبر استدعاء this.update() بدل أن يتم بشكل ضمني كما في React.

هذا هو الفرق الفلسفي الجوهري : React تتبع نموذجاً Declarative حيث تصف الحالة المطلوبة والمكتبة تتولى التحديث. أما Remix 3 فيتبع نموذجاً أقرب إلى Imperative حيث أنت من يقرر متى وكيف يتم التحديث.

أجل، أعلم أن هذه النقطة بالذات خلافية وتحتمل الأخذ والرد، ولكن هذا قرار مايكل جاكسون ورايان فلورنس 🙂 تحكم أكبر والثمن هو عمل يدوي أكثر ومسؤولية أكبر.

التواصل بين المكونات : CustomEvent بدل Props

في React، التواصل بين المكونات يتم عبر الـ Props حيث تمرر البيانات من الأب إلى الابن. في Remix 3، الأسلوب مختلف تماماً : يُستخدم نظام CustomEvent الأصلي في المتصفح.

المكون الابن يُرسل Event، والمكون الأب يستمع إليه. هذا يشبه كثيراً طريقة عمل الـ DOM نفسه، وهو ما يجعل الكود أقرب إلى معايير الويب. وإذا كنت استخدمت من قبل إطار عمل مثل Vue.js فستبدو لك هذه الفكرة مألوفة.

التواصل مع السيرفر : HTML Over The Wire

بالنسبة للتواصل بين الـ Client و Server، اتخذ Remix 3 مقاربة تشبه HTMX أكثر مما تشبه React Server Components. بدل إرسال ما يشبه JSON أو JavaScript، يُرسل HTML كصيغة للتبادل بين الطرفين.

هناك أيضاً مكون مثير يُسمى <Frame> يعمل كبديل ذكي لعنصر <iframe> لتحميل أجزاء من الصفحة بشكل مستقل. وربما يكون هذا المكون هو الأكثر إثارة للاهتمام في Remix 3.

شيئ شبيه لِ <Suspense> في React، لكن يعتمد على الـ URL تماماً مثل <iframe> :

{
  books.map(book => (
    <Frame
      key={book.slug}
      fallback={<div>Loading...</div>}
      src={routes.fragments.bookCard.href({ slug: book.slug })}
    />
  ));
}

ما الذي يحدث هنا؟ مكون <Frame> يعرض أولاً المحتوى الإحتياطي (fallback)، في الوقت الذي يتم فيه طلب الـ URL الموجود في الخاصية src. السيرفر يقوم بعمل Render لذلك الجزء من الـ Route كصفحة HTML ويرسله عبر Streaming. بعدها يستبدل المكون المحتوى الاحتياطي بالمحتوى الحقيقي.

هذا هو مبدأ Progressive Enhancement على طريقة HTMX و Turbo Frames. بدل جلب JSON وعمل Render على جهة الـ Client، تحصل على HTML جاهز ومُعالج مسبقاً من السيرفر. النتيجة : كود JavaScript أقل يحتاج المتصفح لتحليله وتنفيذه، وقت أسرع للتفاعل (Time to Interactive)، يعمل حتى لو فشل تحميل كود الجافاسكريبت 🤯

الفلسفة واضحة : استغل ما يقدمه الويب بدل إعادة الإختراع.

Remix 3 مقابل النهج الحالي : أين يقف كل طرف ؟

لنكن صريحين ومتوازنين. هناك نقاط قوة ونقاط ضعف في كلا الجانبين :

نقاط قوة Remix 3 : البساطة، الأداء المحتمل (Bundle Size أصغر بكثير)، القرب من معايير الويب، وعدم الارتباط بمكتبة لا يتحكمون فيها.

المخاوف والتحديات : النظام البيئي (Ecosystem) شبه معدوم حالياً مقارنة بـ React. لا يوجد مسار ترقية من Remix 2. النموذج الـ Imperative قد يبدو غريباً لمطوري React الذين اعتادوا على النموذج الـ Declarative لسنوات. ومسألة this.update() اليدوية قد تسبب أخطاء كثيرة في التطبيقات المعقدة.

هناك أيضاً ما يسميه البعض “Churn Fatigue” أو التعب من التغييرات المستمرة. فريق React Router (نفس فريق Remix) معروف تاريخياً بالتغييرات الجذرية غير المتوافقة مع الإصدارات السابقة. أحد المستخدمين على Hacker News كتب : “لم أرَ في مسيرتي المهنية بالكامل مكتبة تغيرت بهذا العدد من المرات مثل React Router.”

التشابه مع قصة Angular

الوضع يذكرنا بشكل لافت بما حدث مع AngularJS سنة 2016. في ذلك الوقت، أعلنت Google عن Angular 2 كإعادة كتابة كاملة غير متوافقة مع AngularJS. المطورون غضبوا، كتبوا “رسائل وداع” للإطار، وحتى التسمية (AngularJS مقابل Angular) سببت فوضى عارمة.

لكن في النهاية، Angular نجح وأصبح أقوى بعد هذه القطيعة. الفرق أن Angular كان مدعوماً من Google بمواردها الضخمة. Remix مدعوم من Shopify وهي شركة كبيرة أيضاً، لكن هل هذا كافٍ؟ الأيام القادمة ستجيب.

ماذا يجب أن تفعل الآن ؟

إذا كنت تستخدم Remix 2 حالياً في مشروع إنتاجي: React Router v7 هو مسار الترقية الطبيعي. يحتفظ بـ React ويتوافق مع مشاريعك الحالية.

إذا كنت تبدأ مشروعاً جديداً من الصفر وتريد تجربة فلسفة Web Standards مع أقل قدر من الاعتماديات: Remix 3 هو تجربة جديدة وفريدة تستحق المتابعة وإن بحذر شديد.

لا يوجد حل وسط بين الاثنين. هذه نقطة مهمة : لا يمكنك الترقية تدريجياً من Remix 2 إلى Remix 3. هما مساران مختلفان تماماً.

في الختام

Remix 3 ليس مجرد تحديث لإطار عمل، بل هو سؤال فلسفي يُطرح على مجتمع تطوير الويب بالكامل: هل نحتاج فعلاً لكل هذه التجريدات والتعقيدات التي تراكمت على مر السنين؟ أم أن الويب نفسه أصبح قوياً بما يكفي لنبني عليه مباشرة ؟

بالنسبة لي أرى بأن الفكرة جريئة ومثيرة للإعجاب، لكنها تحمل مخاطر كبيرة. التخلي عن React يعني التخلي عن أكبر منظومة بيئية في عالم الـ Frontend. والرهان على مبدأ “LLM-Friendly” كعامل تصميم أساسي هو رهان مبكر جداً في رأيي المتواضع.

لكن ما يثير اهتمامي فعلاً هو أن Remix 3 ليس وحيداً في هذا التوجه. مكتبات مثل HTMX و Astro و حتى فلسفة Web Components كلها تصب في نفس الاتجاه: العودة إلى أساسيات الويب.

هل سينجح Remix 3 ؟ لا أحد يعرف. لكن حتى لو لم ينجح تجارياً، فإن الأسئلة التي يطرحها تستحق التأمل.

أود أن أسمع آراءكم: هل أنتم مستعدون للتخلي عن React في مشاريعكم ؟ أم أن المنظومة البيئية الضخمة لـ React تجعل الأمر مستحيلاً عملياً ؟

شاركوني آراءكم 🙂