لماذا تخلت نتفليكس عن React؟ دروس هامة للمطورين

تخيل أنني أتيت إليك اليوم في عام 2025 وطلبت منك إنشاء مشروع ويب ضخم مقابل مبلغ كبير من المال، ولكن بشرط واحد: أن تنفذه باستخدام JavaScript الخام (Vanilla JavaScript) وليس بأي إطار عمل. بالطبع، قد تصفني بالجنون أو بأنني ذو عقلية قديمة تعارض التطور. لكن ما لا تعرفه هو أن شركة نتفليكس، إحدى أكبر الشركات في العالم بملايين المستخدمين، قررت الاستغناء عن React والعودة للعمل بـ Vanilla JavaScript.

هل React سيئة؟ على الإطلاق، تُعد React من أفضل مكتبات JavaScript وأكثرها استخدامًا وشعبية، وهي تسهل حياة المطورين بشكل كبير. إذًا، لماذا اتخذت نتفليكس هذا القرار وعادت إلى “العصور القديمة” للعمل بـ Vanilla JavaScript؟ هذا ما سنتعرف عليه في هذا المقال، حيث سأوضح الفرق بين العمل بـ Vanilla JavaScript وأطر عمل JavaScript، وسنستخلص الدروس المستفادة من قرار نتفليكس المفاجئ الذي أثار جدلاً واسعًا في مجتمع المطورين.

لماذا قد يستخدم المطورون Vanilla JavaScript في 2025؟

هناك عدة أسباب تجعل Vanilla JavaScript خيارًا جذابًا حتى اليوم:

1. خفة التحميل: إنها سريعة جدًا لأنها لا تتطلب تحميل مكتبات إضافية.
2. التحكم الكامل: تمنحك السيطرة الكاملة على الكود الخاص بك. لن تجد أي شيء يعمل بطريقة غير متوقعة، ولن يضيف إطار العمل أي عناصر غير مرغوب فيها. هذا يمنحك قدرة فائقة على التحكم في كل جانب من جوانب المشروع.
3. التحكم في الـ DOM: يتيح لك ذلك قدرة عالية على التحكم في DOM (Document Object Model) والتعامل معه بكفاءة.
4. لا حاجة لتعلم إضافي: لن تحتاج إلى تعلم أي شيء يتجاوز JavaScript التي تعرفها بالفعل. يمكنك تنفيذ مهام مثل طلبات AJAX باستخدام أدوات بسيطة، مما يسمح لك بإنجاز مهامك ببساطة.

ما هي عيوب Vanilla JavaScript؟

إذا كانت بهذه الروعة، فلماذا لا يستخدمها الجميع الآن؟ هناك عيوب جوهرية تجعل المطورين يتجنبونها في المشاريع الكبيرة:

1. لغة ديناميكية للغاية: JavaScript لغة تفتقر للصرامة. تخيل أنك تلعب كرة القدم على سطح منزل بلا سياج؛ أي ركلة خاطئة قد تؤدي إلى فقدان الكرة، وأي دفعة بسيطة قد تطيح بك من السطح. JavaScript لغة ديناميكية جدًا، لا تحتوي على أنواع بيانات صارمة (Types)، ويمكن لأي متغير أن يتغير نوعه في أي وقت. التحكم في هذا ضمن مشروع كبير أمر صعب للغاية. ستواجه تحديات كبيرة في تنظيم ملفاتك، وحتى لو كنت محترفًا في التنظيم، ستظل المعاناة كبيرة.
2. صعوبة إدارة الحالة (State): ستعاني بشدة في الصفحات التفاعلية والتي تتطلب إدارة الحالة (State). الحفاظ على حالة العناصر (Controls) في الصفحة باستخدام Vanilla JavaScript ليس بالأمر السهل على الإطلاق.
3. الأمان (Security): لا توفر JavaScript أدوات أمان مدمجة وثابتة. ستعتمد كليًا على نفسك وقدراتك والحلول التي تجهزها لتأمين تطبيقك، هذا إن كنت تتقن ذلك أصلاً.

قوة أطر عمل JavaScript (مثل React)

هذه التحديات هي التي دفعت المطورين إلى إنشاء أطر عمل ومكتبات مثل React، والتي تقدم حلولاً فعّالة. يمكن تشبيه إطار العمل بأنه “سياج” لسطح المنزل الذي تلعب عليه. فهو يجعل البيئة أكثر تنظيمًا ويقلل من احتمالية حدوث مشاكل كبيرة.

تقدم React الميزات التالية:

• بنية قائمة على المكونات (Component-Based Architecture): تتيح لك تقسيم واجهة المستخدم الأمامية (Frontend) إلى مجموعة من المكونات القابلة لإعادة الاستخدام. يمكنك بناء المكون مرة واحدة واستخدامه عدة مرات في مشروعك، مما يوفر الجهد والوقت.
• إدارة الحالة: توفر مكتبات وأدوات تساعدك على الحفاظ على حالة الصفحة وتحديثها بسهولة تامة.
• التعامل مع الـ Virtual DOM: تسرّع وتحسّن التعامل مع الـ Virtual DOM، مما يجعل تحديث أي عنصر على صفحتك أمرًا سهلاً.
• أدوات مساعدة: توفر أدوات للأمان. وإذا كنت تستخدم إطار عمل متكامل مثل Angular أو Next.js، فستجد ميزات إضافية مثل التوجيه (Routing) وطرق موحدة لاستدعاء واجهات برمجة التطبيقات (APIs)، مما يوفر بيئة عمل متكاملة تجعل التطوير أسهل وأكثر سلاسة.

لماذا لا نستخدم أطر العمل دائمًا؟

إذا كانت أطر العمل بهذه الروعة، فلماذا لا يزال البعض يستخدم Vanilla JavaScript؟

1. التأثير على الأداء: كل هذه الأدوات الرائعة تأتي على حساب أداء وسرعة موقعك.
2. التعقيد الزائد (Overhead) في المشاريع الصغيرة: استخدام هذه الأدوات في المشاريع الصغيرة يضيف تعقيدًا كبيرًا لا داعي له، مما يجعل المشروع صعب التعديل ويستهلك موارد أكثر من اللازم.
3. متطلبات الموارد: إذا زاد هذا التعقيد بشكل كبير، ستحتاج إلى تعويضه بمواصفات أعلى في الاستضافة والخادم، وهو ما يرفضه أصحاب الأعمال عادةً. زيادة التعقيد في المشاريع الصغيرة أمر غير مرغوب فيه، وبدأ المطورون يبتعدون عنه.

قرار نتفليكس: القصة الحقيقية

وهذا بالضبط ما فعلته نتفليكس. قد تتساءل: كيف ذلك ومشروع نتفليكس ضخم ويستخدمه الملايين؟

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

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

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

دروس مستفادة للمطورين

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

1. التقنيات في خدمة العمل (Business): التقنيات وُجدت لخدمة أهداف العمل، وليس فقط لتسهيل حياتنا كمطورين. تم إنشاؤها لتحسين قابلية صيانة المشاريع وتحقيق أهداف العمل. إذا كانت تقنيتك لا تحقق هدفًا تجاريًا، فمن الطبيعي أن يتم التخلي عنها.
2. لا تتعصب لتقنية معينة: اليوم تعمل بـ React، وغدًا قد يطلب منك مديرك العمل بـ Angular أو Vue. قد تكون اليوم مطور واجهات أمامية، وغدًا قد تجبرك الظروف على العمل في الواجهات الخلفية التي لا تفضلها. كن مهندس برمجيات قادرًا على العمل في أي بيئة وحل المشكلات بمرونة.
3. قِس قبل أن تقرر: عند اتخاذ قرار باستخدام إطار عمل أو تقنية معينة، اعتمد على القياس والأرقام، وليس على التفضيلات الشخصية. المطورون يميلون إلى التقنيات الجديدة، ولكن يجب أن يكون القرار مبنيًا على قياس الأداء ومتطلبات العمل. على سبيل المثال، إذا كان العمل يتطلب تحسين محركات البحث (SEO) بشكل كبير، فيجب عليك اختيار أفضل تقنية تحقق ذلك، وليس أفضل تقنية تجيدها أنت.
4. أتقن الأساسيات قبل إطار العمل: لا تكن مجرد مقلّد يكتفي بالنسخ واللصق. هذا المقال رسالة لمطوري الواجهات الأمامية الذين يقفزون مباشرة إلى React أو Angular دون إتقان JavaScript جيدًا. قد تجد نفسك فجأة مضطرًا للعمل بـ Vanilla JavaScript، والعودة إلى كتابة الأصناف (Classes) وتنظيم الكود والتعامل مع وظائف اللغة الأساسية يدويًا. هذا يعني أنه يجب أن تكون متمكنًا من JavaScript، وتفهم البرمجة كائنية التوجه (Object-Oriented Programming) ومبادئ تنظيم الكود النظيف، وإلا ستواجه صعوبات كبيرة.
5. ليس كل مشروع يُبنى بتقنية واحدة: في سوق العمل، تُبنى المشاريع بطرق مختلفة عما تتخيل. انسَ فكرة التقنية الواحدة المسيطرة. هناك مشاريع تُبنى بالكامل من جانب الخادم (Server-side) باستخدام Laravel أو .NET أو Node.js دون أي تدخل من React. وهناك مشاريع يكون فيها الجزء الأمامي بـ React ولوحة التحكم من جانب الخادم. ومشاريع أخرى قد تكون مزيجًا من React و Vanilla JavaScript وجزء من جانب الخادم، كل ذلك حسب متطلبات العمل والمشروع. يجب أن تكون مرنًا وقادرًا على بناء تطبيقات من جانب الخادم وأخرى من جانب العميل. تذكر دائمًا أن توفير التكاليف لصاحب العمل هو أولوية، وهذا قد يتطلب استخدام تقنيات متعددة في نفس المشروع.