ما هو بالضبط "تطبيق الويب عالي الأداء" أو "الواجهة الأمامية"؟

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

ولكن بما أن كل لعبة ليست AAA، فيجب علينا أن نفكر بعناية في ما نعنيه بـ "الأداء العالي" عند مناقشة تطبيقات الويب. هذا التمييز أمر بالغ الأهمية للموضوع المطروح اليوم.

1. نطاق تطبيقات الويب عالية الأداء

في معظم الحالات، يشير مصطلح "تطبيق الويب عالي الأداء" إلى عميل ويب تفاعلي وديناميكي تم إنشاؤه باستخدام أطر عمل تعتمد على JavaScript مثل React أو Vue أو Angular. تتميز هذه التطبيقات عادةً بأوقات تحميل سريعة وتوجيه من جانب العميل، ويلعب DOM الافتراضي الخاص بـ React دورًا رئيسيًا في تعزيز سرعة العرض.

ومع ذلك، هناك تطبيقات ويب تستخدم الحد الأقصى لذاكرة وحدة WASM البالغة 4 جيجابايت، وقد تم تصميمها مع وضع الإدارة المنهجية للذاكرة في الاعتبار، وتهدف إلى تحقيق أداء على قدم المساواة مع البرامج الأصلية مثل Blender أو 3Ds Max. تتوافق هذه التطبيقات بشكل أكبر مع مفهوم "البرامج" التي تستغل كل مورد في علامة تبويب المتصفح، بدلاً من "صفحات الويب" التقليدية المُحسّنة لتحسين محركات البحث.

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

وبالنظر إلى أن المشكلات التي تواجهها هذه الأنواع من تطبيقات الويب تختلف عن تلك التي تواجهها التطبيقات النموذجية "عالية الأداء"، فإن الاتجاهات التي تتبعها تتباين أيضًا.

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

لهذا السبب أقترح أن نتوقف عن الإشارة إلى الأخير على أنه "تطبيق ويب عالي الأداء" أو "واجهة أمامية" وأن نستخدم المصطلحات التالية بدلاً من ذلك:

• هندسة إطار العمل عالية الأداء المستندة إلى المتصفح (BBHPFE)
• (المعتمدة على المتصفح) هندسة الأنظمة عالية الأداء (HPSE)

أعتقد أن هذه الشروط تحدد بوضوح الفرق في المتطلبات بين الواجهة الأمامية وHPSE. ليس كل عميل يعتمد على المتصفح هو واجهة أمامية؛ بعضها HPSEs. خذ بعين الاعتبار المثال التالي لفهم سبب أهمية هذا التمييز:

[المحادثة 1]

ج: "أقوم بتطوير تطبيق واجهة أمامية ولكن لا أستخدم React."
ب: "تطبيق واجهة أمامية بدون React؟ تمتلك React ما يزيد عن 60% من حصة السوق في الواجهة الأمامية! لماذا لا تستخدمه؟"

[المحادثة 2]

ج: "أعمل على تطوير تطبيق HPSE ولكن لا أستخدم React."
ب: "هذا أمر منطقي بالنسبة لـ HPSE. غالبًا ما تقوم شركات الألعاب بتخصيص محركاتها على نطاق واسع، ولكن لا يمكن تعديل وظائف React الداخلية ومسار العرض. لم يتم تصميمها أبدًا لهذا الغرض."

الآن، دعونا نناقش المكونات الأساسية التي يجب أن يمتلكها HPSE.

2-1. إدارة الذاكرة
لا يمكنك التحدث عن البرامج عالية الأداء دون معالجة الذاكرة. سواء باستخدام أداة تجميع البيانات المهملة أو تحرير الذاكرة المخصصة ديناميكيًا يدويًا، يجب دائمًا تحرير الذاكرة غير المستخدمة.

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

إذا لم يتم إصدار المراجع إلى البيانات القديمة بشكل صحيح، فسيستمر استخدام الذاكرة في النمو مع كل انتقال للخريطة. بمجرد وصوله إلى حوالي 2 غيغابايت، قد تواجه خطأ "نفاد الذاكرة"، وسيتعطل المتصفح.

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

2-2. المرونة في تلبية المتطلبات
سمعت ذات مرة أحد الأشخاص يقول: "بحلول الوقت الذي تنتقل فيه من كونك مطورًا مبتدئًا إلى مطور متوسط، يجب أن تكون قادرًا على بناء أي شيء يطلب منك."

تعد JavaScript بالفعل لغة مثيرة للإعجاب مع بعض القيود المتأصلة (بصرف النظر عن حدود الذاكرة). إذا كنت ترغب في بناء شيء ما، فمن المحتمل أن يتم ذلك.

السؤال الحقيقي هو ما إذا كان مشروعك الحالي يمكنه حقًا استيعاب مجموعة واسعة من المتطلبات.

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

على سبيل المثال، هل سمعت يومًا أن Lost Ark تم بناؤه على Unreal Engine 3؟ تم إطلاق Unreal Engine 5 الآن، ومع ذلك ما زالوا يستخدمون Unreal Engine 3، الذي تم إنشاؤه في عام 2004. للحفاظ على المشروع حتى الآن، لا بد أنهم أجروا تعديلات واسعة النطاق على المحرك - وهو إصلاح شامل عمليًا. نظرًا لخصائص اللعبة، كان عليهم أن يخصصوا باستمرار مسار العرض والحلقة باستخدام تقنيات مثل العرض المؤجل، والتركيب، والتصفية، وانعكاس مساحة الشاشة لتلبية متطلبات الأداء والجمالية.

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

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

2-3. النهج الحتمي الموجه للكائنات
عند التعامل مع البرامج واسعة النطاق، يصبح هناك شيء واحد لا مفر منه: البرمجة الشيئية (OOP).

جافا سكريبت هي لغة متعددة النماذج، وتستخدم البرمجة الوظيفية (FP) على نطاق واسع. ومع ذلك، FP، على الرغم من أنه مناسب لعملاء الويب، إلا أنه نادرًا ما يستخدم في البرامج واسعة النطاق حيث تتفاعل كائنات متعددة بطرق معقدة لأن المثيلات في FP تفتقر إلى الحالات الداخلية.

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

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

من المحتمل أن يكون المطورون الذين شاركوا في مشاريع واسعة النطاق على دراية بـ OOP. وهذا يجعل التطوير القائم على OOP ملائمًا للتعاون.

ومع ذلك، ليست هناك حاجة لتجاهل نقاط قوة JavaScript. نظرًا لأن JavaScript تدعم الوظائف وإعلانات const، فيمكن تعريف وظائف الوحدة البسيطة التي لا تتطلب مثيلات على أنها كائنات حرفية باستخدام const أو function. يمكن أن يؤدي ذلك إلى تحسين الإنتاجية والاستفادة من تنوع JavaScript.

في الختام، أعتقد أن اتباع نهج متعدد النماذج، يتضمن مبادئ موجهة للكائنات، سيكون مثاليًا لـ HPSE.