سيتم إطلاق Vapor Mode القادم في Vue 3.6 هذا الخريف، وهو يقوم بشيء لم يفعله الإطار من قبل: فهو يقوم بتجميع مكونات الملف الواحد (single-file components) لتتحول مباشرة إلى تحديثات للـ DOM، متجاوزاً الـ virtual DOM تماماً.

لماذا تتخلى Vue عن الـ virtual DOM

منذ إصدار Vue 2، كان الـ virtual DOM هو جوهر نموذج التفاعلية (reactivity model) الخاص بالإطار. عندما تتغير الحالة (state)، يقوم Vue ببناء شجرة خفيفة في الذاكرة، ويقارنها (diffs) بالإصدار السابق، ثم يُجري التعديلات (patches) فقط على الأجزاء المختلفة. هذا التجريد يسمح للمطورين بكتابة كود تصريحي (declarative code) دون القلق بشأن العنصر الذي يحتاج فعلياً إلى التحديث. والمقايضة هنا هي أن كل عملية رندر (render) لا تزال تتحمل تكلفة بناء ومقارنة تلك الشجرة الافتراضية.

يقوم Vapor Mode بإلغاء هذه الخطوة الوسطى. أثناء عملية البناء (build)، يقوم مترجم Vue بتحليل القالب (template) ويُصدر JavaScript يستدعي طرق الـ DOM الأصلية — مثل element.textContent = … و element.setAttribute(...) — مباشرة حيث تبرز الحاجة للتغيير. لا يتم إنشاء عقد افتراضية (virtual nodes)، ولا يتم تشغيل حلقة المقارنة (diffing loop). وينتهي الأمر بالحزمة (bundle) وهي تحتوي فقط على الكود المطلوب للتحديثات الملموسة التي كتبتها، بالإضافة إلى وقت التشغيل (runtime) اللازم للتفاعلية.

التأثير الواقعي على الحجم والسرعة

  • حجم الحزمة (Bundle size) – من خلال إزالة وقت تشغيل الـ virtual-DOM وهياكل بياناته، يتقلص الكود الناتج. في المشاريع التي تحتوي على شبكات (grids) أو لوحات (canvases) كبيرة يتم تحديثها عشرات المرات في الثانية، تتراكم هذه التوفيرات، خاصة في الاتصالات ذات النطاق الترددي المنخفض.
  • الأداء (Performance) – تتخطى استدعاءات الـ DOM المباشرة عبء عملية المقارنة (diffing overhead)، وهو أمر يصبح ملحوظاً عندما تتغير واجهة المستخدم بتردد عالٍ. في مجموعة من ألعاب المتصفح الشخصية — لعبة nonogram، ونسخة من لعبة minesweeper، ومحاكي لمكعب روبيك ثلاثي الأبعاد — قمت بكتابة منطق الرندر يدوياً، حيث قمت بتحديث الـ DOM فقط عند الضرورة.
  • سهولة الاستخدام للمطورين (Developer ergonomics) – يقوم المترجم بالعمل الشاق. لا تزال تكتب قوالب Vue العادية؛ ولست مضطراً لصياغة استدعاءات document.querySelector يدوياً. الكود الناتج يحاكي النهج المكتوب يدوياً الذي منحني أفضل أداء في تلك الألعاب.

متى يساعد Vapor Mode فعلياً

  1. التحديثات عالية التردد على الهياكل الكبيرة – الألعاب، أو لوحات البيانات كثيفة البيانات، أو أي واجهة تعيد رسم العديد من الخلايا في كل نبضة (tick) ستستفيد بشكل أكبر. يمكن أن تهيمن عملية مقارنة شبكة كبيرة في كل نبضة على ميزانية الإطارات (frame budget)؛ بينما تحافظ التحديثات المباشرة على العمل خطياً وقابلاً للتنبؤ.
  2. عمليات النشر المقيدة بحجم الحزمة – المواقع التي تعطي الأولوية للهواتف المحمولة (mobile-first) والتي يجب أن يتم تحميلها في أقل من بضع مئات من الكيلوبايتات، ستشهد انخفاضاً ملموساً عند اختفاء وقت تشغيل الـ virtual-DOM.
  3. الحالة النقية والمتوقعة (Pure, predictable state) – يفترض Vapor Mode أنك تحافظ على الحالة غير قابلة للتغيير (immutable) وتتعامل مع الـ DOM كمجرد انعكاس لتلك الحالة. إذا كان الكود الخاص بك يخلط بين الآثار الجانبية (side-effects) أو يغير الـ DOM خارج نظام تفاعلية Vue، فقد تخرج التحديثات الناتجة عن المزامنة، مما يسبب خللاً بصرياً.

أين لا يزال النهج القديم يتفوق

  • واجهات المستخدم منخفضة التردد – النماذج البسيطة، أو الصفحات الثابتة، أو لوحات الإدارة التي تعيد الرندر فقط عند إجراءات المستخدم العرضية، لا تحقق مكاسب كبيرة في الأداء. العمل الإضافي لبناء شجرة افتراضية لا يُذكر مقارنة بزمن انتقال الشبكة أو وقت معالجة الخادم.
  • التسلسلات الهرمية المعقدة للمكونات – عندما تتغير عقدة ورقية (leaf node) في شجرة عميقة، يمكن للـ virtual DOM تخطي أجزاء كبيرة تلقائياً. أما التحديثات المباشرة فتجبر المترجم على إنشاء تعديلات دقيقة لكل تغيير محتمل، مما قد يزيد من حجم الكود في الحالات الاستثنائية.
  • الأدوات والنظام البيئي (Tooling and ecosystem) – العديد من إضافات Vue، وأدوات التطوير (devtools)، وأدوات الاختبار ترتبط بطبقة الـ virtual-DOM. قد تحتاج هذه التكاملات إلى تحديثات لتعمل مع مكونات Vapor-mode حتى يلحق بها النظام البيئي.

ما يجب مراقبته لاحقاً

  • الإصدار المستقر – Vue 3.6 حالياً في حالة الإصدار المرشح (release-candidate). يخطط الفريق لإطلاق مستقر نهائي هذا الخريف. يجب على المستخدمين الأوائل انتظار هذا الإصدار قبل إرسال كود الإنتاج (production code).
  • مسار الهجرة (Migration path) – يمكن لمشاريع Vue الحالية اختيار استخدام Vapor Mode على مستوى كل مكون على حدة.
  • أدوات قياس الأداء – ستساعد اختبارات الأداء (benchmarks) التي تقارن بين إصدارات الـ virtual-DOM و Vapor-mode في التطبيقات الواقعية الفرق في اتخاذ القرار بشأن ما إذا كانت المقايضة تستحق العناء.

الخلاصة

يوفر Vapor Mode لمطوري Vue أفضل ما في العالمين: الصيغة التصريحية التي يحبونها والسرعة الخام لتحديثات DOM المصنوعة يدويًا. إنه يتألق في التطبيقات التي تُحدّث أجزاءً كبيرة من واجهة المستخدم (UI) عدة مرات في الثانية، وفي عمليات النشر التي يمثل فيها كل كيلوبايت فارقًا. أما بالنسبة للواجهات ذات حركة المرور المنخفضة، يظل الـ virtual DOM التقليدي خيارًا بسيطًا ومناسبًا تمامًا. ومع انتقال هذه الميزة من مرحلة الـ release candidate إلى الإصدار المستقر (stable)، سيحتاج مجتمع Vue إلى الموازنة بين توفير حجم الحزمة (bundle-size) وجاهزية النظام البيئي (ecosystem) وخصائص الأداء المحددة لتطبيقاتهم.