مواجهة أداء أطر عمل JavaScript: معايير واقعية للتطبيقات الحديثة

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

في حين أن المعايير التركيبية مثل TodoMVC لها مكانها، إلا أنها غالبًا ما تفشل في التقاط تعقيدات تطبيق الويب الحديث. إنها تختبر الميزات المعزولة في فراغ، وهو سيناريو نادرًا ما يتم مواجهته في الإنتاج. تتخذ هذه المقالة نهجًا مختلفًا. نحن نتعمق في معيار تطبيق واقعي، ونقارن بين عمالقة عالم الواجهة الأمامية - React و Vue و Angular - جنبًا إلى جنب مع المتنافسين من الجيل الجديد، Svelte و SolidJS. هدفنا هو تجاوز الحجج النظرية وتقديم بيانات ملموسة لمساعدتك في اتخاذ قرار مستنير لمشروعك التالي.

لماذا المعايير الواقعية مهمة

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

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

تحاول المعايير الواقعية محاكاة هذه السيناريوهات. من خلال بناء تطبيق متطابق ومعقد باعتدال في كل إطار عمل، يمكننا قياس مقاييس الأداء التي تؤثر بشكل مباشر على تجربة المستخدم، وبالتالي، الأهداف التجارية. ترتبط هذه المقاييس ارتباطًا وثيقًا بعلامات Core Web Vitals (CWV) من Google، وهي مجموعة من العوامل التي أصبحت الآن جزءًا من خوارزمية ترتيب البحث الخاصة بها. باختصار، الأداء ليس مجرد مصدر قلق تقني؛ إنه ضرورة SEO وتجارية.

المتنافسون: نظرة عامة موجزة

لقد اخترنا خمسة من أبرز وأهم الأطر المثيرة للاهتمام في النظام البيئي اليوم. لكل منها فلسفة وهيكل مختلفان، مما يؤثر بشكل مباشر على خصائص الأداء الخاصة به.

React (v18)

تم تطوير React وصيانته بواسطة Meta، وهو الرائد بلا منازع في السوق. لقد نشر هندسة قائمة على المكونات و Virtual DOM (VDOM). يعمل VDOM كتمثيل في الذاكرة لـ DOM الحقيقي، مما يسمح لـ React بتجميع التحديثات بكفاءة. إن نظامه البيئي الضخم ومجموعة المواهب تجعله خيارًا افتراضيًا للعديد من الشركات في جميع أنحاء العالم.

Vue (v3)

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

Angular (v16)

Angular من Google هو أكثر من مجرد نظام أساسي. إنه إطار عمل شامل ومتعصب يوفر حلولاً لكل شيء بدءًا من التوجيه وحتى إدارة الحالة خارج الصندوق. تاريخيًا، اشتهرت بأحجام حزم أكبر، وقد جعلت الإصدارات الحديثة مع مترجم Ivy و tree-shaking وإدخال الإشارات والمكونات المستقلة أكثر قدرة على المنافسة في واجهة الأداء.

Svelte (v4)

يتخذ Svelte نهجًا جذريًا. إنه مترجم يعمل في وقت الإنشاء، ويحول مكونات Svelte الخاصة بك إلى كود JavaScript إلزامي ومحسن للغاية يتلاعب مباشرة بـ DOM. هذا يعني عدم وجود Virtual DOM وتقريبًا لا يوجد كود وقت تشغيل خاص بإطار العمل في حزمة الإنتاج الخاصة بك. الفلسفة هي نقل العمل من المتصفح إلى خطوة الإنشاء.

SolidJS (v1.7)

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

تطبيق المعيار: "لوحة معلومات الرؤية العالمية"

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

• المصادقة: تدفق تسجيل الدخول/الخروج الوهمي.
• الصفحة الرئيسية للوحة المعلومات: تعرض العديد من البطاقات والرسوم البيانية الموجزة مع البيانات التي تم جلبها من واجهة برمجة تطبيقات وهمية.
• صفحة جدول البيانات الكبيرة: صفحة تجلب وتعرض جدولاً يحتوي على 1000 صف و 10 أعمدة من البيانات.
• ميزات الجدول التفاعلية: الفرز والتصفية واختيار الصفوف من جانب العميل.
• عرض التفاصيل: توجيه من جانب العميل إلى صفحة تفاصيل لصف محدد في الجدول.
• الحالة العامة: حالة مشتركة للمستخدم المصادق عليه ومظهر واجهة المستخدم (الوضع الفاتح/الداكن).

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

المنهجية: كيف قمنا بقياس الأداء

الشفافية والاتساق أمران أساسيان للمقارنة العادلة. إليك إعداد الاختبار الخاص بنا:

• الأدوات: Google Lighthouse (تشغيل في نافذة التصفح المتخفي) و Chrome DevTools Performance profiler.
• البيئة: تم إنشاء جميع التطبيقات للإنتاج وتقديمها محليًا.
• شروط الاختبار: لمحاكاة مستخدم الهاتف المحمول في العالم الحقيقي، تم إجراء جميع الاختبارات مع إبطاء وحدة المعالجة المركزية 4x و اختناق شبكة 3G سريع. هذا يمنع النتائج من أن تكون منحرفة بواسطة أجهزة المطورين المتطورة.
• المقاييس الرئيسية المقاسة:
  • حجم حزمة JS الأولية (مضغوطة): مقدار JavaScript الذي يجب على المتصفح تنزيله وتحليله وتنفيذه في الزيارة الأولية.
  • First Contentful Paint (FCP): يحدد الوقت الذي يتم فيه عرض أول جزء من محتوى DOM.
  • Largest Contentful Paint (LCP): يقيس متى يتم عرض أكبر عنصر محتوى مرئي في منفذ العرض. Core Web Vital الرئيسي.
  • Time to Interactive (TTI): الوقت المستغرق حتى تصبح الصفحة تفاعلية بالكامل.
  • Total Blocking Time (TBT): يقيس إجمالي الوقت الذي تم فيه حظر سلسلة التعليمات الرئيسية، مما يمنع إدخال المستخدم. يرتبط مباشرة بـ INP (Interaction to Next Paint) Core Web Vital الجديد.
  • استخدام الذاكرة: حجم الكومة الذي تم قياسه بعد التحميل الأولي وبعد عدة تفاعلات.

النتائج: مقارنة وجهاً لوجه

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

الجولة الأولى: التحميل الأولي وحجم الحزمة

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

• Svelte: الفائز. مع حزمة JS مضغوطة بحجم 9 كيلوبايت فقط، كان Svelte هو الرائد الواضح. كانت نتائج FCP و LCP الخاصة به رائعة، حيث كان لدى المتصفح القليل جدًا من كود إطار العمل للمعالجة. ظهرت لوحة المعلومات على الفور تقريبًا.
• SolidJS: المركز الثاني القريب. كان حجم الحزمة أكبر قليلاً عند 12 كيلوبايت. كان الأداء مطابقًا تقريبًا لـ Svelte، مما يوفر تجربة تحميل أولية سريعة للغاية.
• Vue: أداء قوي. جاءت حزمة Vue بحجم محترم 35 كيلوبايت. تألقت تحسينات المترجم الخاصة به، مما يوفر LCP و TTI سريعًا كانا تنافسيين للغاية.
• React: منتصف المجموعة. أدى الجمع بين `react` و `react-dom` إلى حزمة 48 كيلوبايت. في حين أنها ليست بطيئة بأي حال من الأحوال، إلا أن TTI كان أطول بشكل ملحوظ من القادة بسبب عمل بناء VDOM وإماهة التطبيق.
• Angular: تم التحسين، ولكن لا يزال الأكبر. كانت حزمة Angular هي الأكبر عند 65 كيلوبايت. في حين أن هذا يمثل تحسنًا كبيرًا عن الإصدارات الأقدم، إلا أن تكلفة التحليل والتمهيد الأولية كانت لا تزال الأعلى، مما أدى إلى أبطأ FCP و LCP في هذا الاختبار.

رؤية: بالنسبة للمشاريع التي يكون فيها وقت التحميل الأولي أمرًا بالغ الأهمية (على سبيل المثال، صفحات الهبوط للتجارة الإلكترونية، والمواقع التسويقية)، فإن الأطر القائمة على المترجم مثل Svelte و Solid تتمتع بميزة واضحة وقابلة للقياس نظرًا لبصمة وقت التشغيل الصغيرة.

الجولة الثانية: وقت التشغيل وأداء التفاعل

بمجرد تحميل التطبيق، كيف يبدو استخدامه؟ لقد اختبرنا ذلك من خلال إجراء عمليات مكثفة على جدول البيانات الذي يحتوي على 1000 صف: الفرز حسب عمود وتطبيق مرشح نصي يبحث في جميع الخلايا.

• SolidJS: الفائز. كان أداء Solid هنا رائعًا. كان الفرز والتصفية فوريًا. كان تفاعله الدقيق يعني أنه تم لمس عقد DOM التي تحتاج إلى التغيير فقط. كان TBT منخفضًا بشكل لا يصدق، مما يشير إلى واجهة مستخدم غير مانعة حتى أثناء الحسابات الثقيلة.
• Svelte: أداء ممتاز. كان Svelte مباشرة خلف Solid. أثبتت عمليات معالجة DOM المباشرة والمجمعة أنها فعالة للغاية. كانت تجربة المستخدم سلسة وسريعة الاستجابة، مع TBT قليل جدًا.
• Vue: أداء جيد جدًا. تعامل نظام تفاعل Vue مع التحديثات بكفاءة. كان هناك تأخير طفيف جدًا وغير محسوس تقريبًا في التصفية مقارنة بـ Solid و Svelte، ولكن التجربة الشاملة كانت ممتازة وسترضي الغالبية العظمى من حالات الاستخدام.
• React: جيد، ولكنه يتطلب التحسين. خارج الصندوق، أظهر تطبيق React تأخيرًا ملحوظًا عند تصفية الجدول الكبير. تم حظر سلسلة التعليمات الرئيسية لفترة قصيرة، حيث كانت إعادة عرض مكون 1000 صف مكلفة. كان هذا قابلاً للحل عن طريق تطبيق التحسينات يدويًا مثل `React.memo` على مكونات الصف و `useMemo` لمنطق التصفية. مع التحسين، أصبح الأداء جيدًا، لكنه تطلب جهدًا إضافيًا من المطور.
• Angular: جيد، مع الفروق الدقيقة. كافحت آلية الكشف عن التغييرات الافتراضية في Angular أيضًا قليلاً مع مهمة التصفية، على غرار React. ومع ذلك، فإن نقل مكون الجدول لاستخدام استراتيجية الكشف عن التغييرات `OnPush` حسّن الأداء بشكل كبير، مما جعله سريع الاستجابة للغاية. من المحتمل أن تجعله ميزة الإشارات الجديدة في Angular على قدم المساواة مع القادة.

رؤية: بالنسبة للتطبيقات التفاعلية للغاية والتي تعتمد على البيانات بشكل مكثف، توفر Architectures Solid و Svelte أداءً الأفضل في فئته خارج الصندوق. مكتبات VDOM مثل React و Vue قادرة تمامًا، ولكنها قد تتطلب من المطورين أن يكونوا أكثر وعيًا بتقنيات تحسين الأداء مع نمو التعقيد.

الجولة الثالثة: استخدام الذاكرة

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

• Svelte & SolidJS: تعادلا في الصدارة بأقل بصمة للذاكرة. مع عدم وجود VDOM في الذاكرة ووقت تشغيل صغير، كانا بسيطين وفعالين.
• Vue: تستهلك ذاكرة أكثر قليلاً من القادة، وهو ما يُعزى إلى VDOM ونظام التفاعل الخاص بها، لكنها ظلت فعالة للغاية.
• React: كان لديها بصمة ذاكرة أعلى بسبب VDOM والنفقات العامة لهندسة الألياف.
• Angular: سجل أعلى استخدام للذاكرة، نتيجة لبنية إطار العمل الشاملة و Zone.js للكشف عن التغييرات.

رؤية: بالنسبة للتطبيقات التي تستهدف الأجهزة ذات الموارد المحدودة أو المخصصة لتبقى مفتوحة لفترات طويلة جدًا، يمكن أن يكون العبء الزائد الأقل للذاكرة في Svelte و Solid ميزة كبيرة.

ما وراء الأرقام: العوامل النوعية

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

تجربة المطور (DX) ومنحنى التعلم

• غالبًا ما يتم الإشادة بـ Vue و Svelte لامتلاكهما أكثر DX ممتعة وألطف منحنيات التعلم. بناء الجملة الخاص بهم بديهي والوثائق من الدرجة الأولى.
• React's JSX ونموذج قائم على الخطاف قويان ولكن يمكن أن يكون لهما منحنى تعليمي أكثر حدة، خاصة حول مفاهيم مثل الحفظ والتبعيات المؤثرة.
• SolidJS سهل على مطوري React التقاطه نحويًا، لكنه يتطلب تغييرًا في النموذج الذهني لفهم تفاعله الدقيق.
• Angular's طبيعة متعصبة واعتمادها على TypeScript ومفاهيم مثل حقن التبعية يمثلان منحنى التعلم الأكثر حدة، ولكن هذا الهيكل يمكن أن يفرض الاتساق في الفرق الكبيرة.

النظام البيئي ودعم المجتمع

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

الخلاصة: أي إطار عمل مناسب لك؟

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

فيما يلي توصيتنا النهائية بناءً على سيناريوهات مختلفة:

• لأعلى أداء ذروة وبنيات بسيطة: اختر Svelte أو SolidJS. إذا كان هدفك الأساسي هو أسرع أوقات تحميل ممكنة، وواجهة المستخدم الأكثر استجابة، وأصغر حجم حزمة ممكن (على سبيل المثال، مواقع التجارة الإلكترونية، وتطبيقات الويب التي تركز على الهاتف المحمول، والتصورات التفاعلية)، فإن هذه الأطر في فئة خاصة بها. يحصل SolidJS على ميزة لمعالجة البيانات التفاعلية المعقدة، بينما يقدم Svelte تجربة مطور أبسط وأكثر سحرية.
• لنظام بيئي ضخم ومجموعة توظيف: اختر React. إذا كان مشروعك بحاجة إلى الوصول إلى أوسع نطاق ممكن من المكتبات والأدوات والمطورين، فإن React هو الخيار الأكثر أمانًا والأكثر واقعية. أدائها جيد جدًا، وهيمنتها في سوق العمل تجعل من السهل توسيع نطاق فريق التطوير الخاص بك في أي مكان في العالم.
• لتحقيق التوازن بين الأداء وإمكانية الوصول: اختر Vue. تحقق Vue نقطة التقاء رائعة. إنه يوفر أداءً ممتازًا يتنافس مع React، ولكن مع تجربة مطور يجدها الكثيرون أكثر سهولة وأسهل في التعلم. إنه متعدد الاستخدامات رائع للتطبيقات الصغيرة والكبيرة.
• لتطبيقات المؤسسات الكبيرة: اختر Angular. إذا كنت تقوم ببناء تطبيق معقد وطويل الأمد مع فريق كبير من المطورين، فإن طبيعة Angular المنظمة والمتعصبة يمكن أن تكون رصيدًا هائلاً. إنه يفرض الاتساق ويوفر نظامًا أساسيًا قويًا وشاملاً يمكنه التعامل مع تعقيد مستوى المؤسسة، ويتحسن أدائه باستمرار.

يتطور عالم أطر عمل JavaScript أسرع من أي وقت مضى. إن صعود المترجمين والابتعاد عن Virtual DOM من قبل المتنافسين مثل Svelte و SolidJS يدفع النظام البيئي بأكمله إلى الأمام. في النهاية، تعد "حروب إطار العمل" شيئًا جيدًا - فهي تؤدي إلى الابتكار وأداء أفضل وأدوات أكثر قوة للمطورين لبناء الجيل التالي من تجارب الويب. اختر الأداة التي تناسب قيود وأهداف مشروعك الفريدة على أفضل وجه، وستكون في طريقك إلى النجاح.