يعتقد الكثيرون أن الـ Virtual DOM أسرع بطبيعته من الـ Real DOM، مما يجعل تطبيقات الويب سريعة. لكن هذا سوء فهم شائع؛ فالتحديثات المباشرة للـ Real DOM يمكن أن تكون أسرع إذا كنت تعرف بالضبط ما تحتاج لتغييره.
ربما سمعت هذا من قبل: «React سريع لأنه يستخدم Virtual DOM». إنه تصريح شائع ويبدو منطقيًا للوهلة الأولى. غالبًا ما نسمع أن الـ Real DOM الخاص بالمتصفح «مكلف» للتعامل معه، وبما أن الأطر الشائعة مثل React تستخدم Virtual DOM، فمن السهل أن نستنتج أن الـ Virtual DOM هو ببساطة نسخة أسرع من الـ DOM. ولكن هذه هي الحقيقة: الـ Virtual DOM ليس أسرع بطبيعته من الـ Real DOM.
ما يعنيه هذا لك، سواء كنت مطورًا أو مهتمًا فقط بكيفية عمل مواقع الويب، هو أننا بحاجة إلى تعديل فهمنا. إذا كنت تعرف بالضبط أي جزء من صفحة الويب الخاصة بك يحتاج إلى التغيير، فإن تحديث هذا الجزء المحدد من الـ Real DOM مباشرة يمكن أن يكون أسرع غالبًا من العملية التي تستخدمها الأطر مع Virtual DOM. فكر في الأمر بهذه الطريقة: إذا كنت تعرف بالضبط مكان مسمار واحد، فإن طرقه مباشرة أسرع من بناء جدار جديد بالكامل فقط لوضع المسمار فيه.
إذًا، إذا لم يكن الـ Virtual DOM مجرد «DOM أسرع»، فما هو غرضه الحقيقي؟ الـ Real DOM، أو نموذج كائن المستند، هو الهيكل الشبيه بالشجرة الذي يبنيه متصفحك فعليًا من HTML لعرض صفحة الويب الخاصة بك. عندما تقوم لغة JavaScript بتغيير هذا الهيكل مباشرة، مثل تغيير نص عنوان، يكون ذلك فعالًا للتحديثات البسيطة والمستهدفة. ففكرة أن «الـ Real DOM بطيء» تبسيط مبالغ فيه. الـ DOM نفسه ليس المشكلة؛ بل هو مقدار العمل الإضافي الذي يتعين على المتصفح القيام به *بعد* التغيير – مثل إعادة حساب الأنماط، وتخطيط العناصر، ورسم البكسلات.
تكمن قوة الـ Virtual DOM ليس في السرعة الخام، بل في حل تحدٍ مختلف: إدارة التحديثات المعقدة والمتكررة في تطبيقات الويب الحديثة. عندما يتغير العديد من الأشياء في الصفحة، فإن تحديد الطريقة الأكثر كفاءة لتحديث الـ Real DOM مباشرة يمكن أن يصبح معقدًا للغاية وعرضة للأخطاء بالنسبة للمطورين. يقوم الـ Virtual DOM بإنشاء نسخة خفيفة الوزن من الـ Real DOM. عندما تتغير حالة تطبيقك، فإنه يقوم أولًا بتحديث هذه النسخة الافتراضية. ثم يقارن النسخة الافتراضية الجديدة مع النسخة السابقة، ويكتشف الفروق الضرورية فقط. أخيرًا، يقوم بإجراء مجموعة من أقل التغييرات الممكنة على الـ Real DOM. تبسط عملية المصالحة هذه عملية التطوير بشكل كبير، مما يسهل بناء تطبيقات عالية الأداء دون تحسين كل تحديث للـ DOM يدويًا. الأمر يتعلق بالإدارة الذكية، وليس السرعة الغاشمة.
ما يعنيه هذا لك، سواء كنت مطورًا أو مهتمًا فقط بكيفية عمل مواقع الويب، هو أننا بحاجة إلى تعديل فهمنا. إذا كنت تعرف بالضبط أي جزء من صفحة الويب الخاصة بك يحتاج إلى التغيير، فإن تحديث هذا الجزء المحدد من الـ Real DOM مباشرة يمكن أن يكون أسرع غالبًا من العملية التي تستخدمها الأطر مع Virtual DOM. فكر في الأمر بهذه الطريقة: إذا كنت تعرف بالضبط مكان مسمار واحد، فإن طرقه مباشرة أسرع من بناء جدار جديد بالكامل فقط لوضع المسمار فيه.
إذًا، إذا لم يكن الـ Virtual DOM مجرد «DOM أسرع»، فما هو غرضه الحقيقي؟ الـ Real DOM، أو نموذج كائن المستند، هو الهيكل الشبيه بالشجرة الذي يبنيه متصفحك فعليًا من HTML لعرض صفحة الويب الخاصة بك. عندما تقوم لغة JavaScript بتغيير هذا الهيكل مباشرة، مثل تغيير نص عنوان، يكون ذلك فعالًا للتحديثات البسيطة والمستهدفة. ففكرة أن «الـ Real DOM بطيء» تبسيط مبالغ فيه. الـ DOM نفسه ليس المشكلة؛ بل هو مقدار العمل الإضافي الذي يتعين على المتصفح القيام به *بعد* التغيير – مثل إعادة حساب الأنماط، وتخطيط العناصر، ورسم البكسلات.
تكمن قوة الـ Virtual DOM ليس في السرعة الخام، بل في حل تحدٍ مختلف: إدارة التحديثات المعقدة والمتكررة في تطبيقات الويب الحديثة. عندما يتغير العديد من الأشياء في الصفحة، فإن تحديد الطريقة الأكثر كفاءة لتحديث الـ Real DOM مباشرة يمكن أن يصبح معقدًا للغاية وعرضة للأخطاء بالنسبة للمطورين. يقوم الـ Virtual DOM بإنشاء نسخة خفيفة الوزن من الـ Real DOM. عندما تتغير حالة تطبيقك، فإنه يقوم أولًا بتحديث هذه النسخة الافتراضية. ثم يقارن النسخة الافتراضية الجديدة مع النسخة السابقة، ويكتشف الفروق الضرورية فقط. أخيرًا، يقوم بإجراء مجموعة من أقل التغييرات الممكنة على الـ Real DOM. تبسط عملية المصالحة هذه عملية التطوير بشكل كبير، مما يسهل بناء تطبيقات عالية الأداء دون تحسين كل تحديث للـ DOM يدويًا. الأمر يتعلق بالإدارة الذكية، وليس السرعة الغاشمة.
