بينما كنت أكتب على Solid ، أتيحت لي الفرصة لتقدير عدد المحاولات لتحسين الأداء على الرسوم البيانية (المعايير).DOM هو اختناق في الواجهة الأمامية. يمكن أن تؤدي الحلول المختلفة إلى نتائج مماثلة. تظهر مكتبات جديدة كل أسبوع ، تضم أفضل من المكتبات السابقة ، لتكوين مزيج مثالي. بعد مرور بعض الوقت ، بدأت عيني تهرب من مجموعة متنوعة من الحلول.لا تسيء فهمي. أحب أن أرى أفكارًا جديدة تنبض بالحياة ، لكن جميعها تحتوي على عيوب ، وأحيانًا تؤدي إلى فقدان الراحة أو الإنتاجية. أفهم عواقب مثل هذا القرار ، لكني أريد مشاركة ملاحظاتي.ما هي أسرع طريقة للعمل مع DOM:- دوم الظاهري
- قالب الحرف الموسومة
- أرصدة دقيقة الحبيبات
مقارنة
JS Frameworks Benchmark هو أفضل مشروع مفتوح المصدر لمقارنة أداء أطر عمل JavaScript UI. من الأفضل إجراء الاختبارات محليًا بدلاً من استخدام النتائج الرسمية. قد تختلف النتائج حسب الجهاز. نظرًا لأنني أختبر على جهاز ضعيف ، سينخفض الأداء بشكل ملحوظ.سوف أتخذ أفضل الأساليب في عرض شجرة DOM لتوضيح التكرار لبعض الحلول. سأفعل ذلك باستخدام قدرة Solid لدعم خيارات العرض المختلفة من أجل فرض التكاليف مع تغير المتغيرات ومقارنتها مع نتائج مماثلة من أطر أخرى. دعونا نلقي نظرة عليها.أصناف صلبة:- Solid - نسخة من الإطار مع ES2015 proxy setter فوق وظائف تتبع التغيير المضمنة في قوالب عقدة DOM المستنسخة. يتم تحقيق ذلك عن طريق ترجمة قوالب JSX (الكود)
- الإشارات الصلبة - هذا الإصدار هو نفس الإصدار السابق ، ولكن يتم استخدام الإشارات الأولية بدلاً من البروكسيات. هذا يعقد استخدام المكتبة ، ولكن في النهاية نحصل على حزمة أصغر وأداء أفضل (كود)
- صلب مضاء - لا يستخدم هذا الإصدار الترجمة المسبقة لـ JSX في وقت التشغيل (الرمز)
- solid-h - يستخدم هذا الإصدار HyperScript لإنشاء `document.createElement` على الفور. يستخدم الباقي نفس تطبيق Solid (Code)
مكتبات أخرى:- domc — -, DOM DSL (domain specific language) HTML, index.html (Code)
- surplus — JSX `document.createElement`. Solid (Code)
- ivi — Inferno, DOM. HyperScript Helpers-esque (Code)
- lit-html — , c . Tagged Template Literals DOM- (Code)
- جحيم هو أسرع استنساخ رد فعل واحدة من أسرع مكتبات DOM الافتراضية. يستخدم توجيهات JSX الخاصة للحصول على أفضل أداء (الكود)
قد لا تكون بعض أطر العمل المفضلة لديك هنا ، ولكن هذه القائمة تعرض إصدارات محسنة من جميع التقنيات التي ستراها في الأطر الأكثر شيوعًا. يمكنك النظر إليه كمؤشر لتقييم القدرات القصوى لمكتبتك. إذا كنت مهتمًا بمقارنة أداء الأطر الشائعة ، أوصي بهذا المخطط.للمقارنة ، أود أن أضيف تجميع ويب. لسوء الحظ ، في وقت كتابة هذه السطور ، كانت سجلات WASM تنفيذًا للفانيليا بدون تجريدات عالية المستوى. (أضافوا لاحقًا wasm-bindgen إلى الإطار - مترجم تقريبًا)النتائج
HyperScript (جحيم ، ivi ، صلب- h)
يعرض HyperScript الترميز كتركيبة من الوظائف (مثل h أو React.createElement). على سبيل المثال:h('div', {id: 'my-element'}, [
h('span', 'Hello'),
h('span', 'John')
])
تمتلك أطر عمل DOM الافتراضية هذه الخاصية. حتى إذا كانوا يستخدمون JSX أو محركات قالب DSL أخرى - تحت غطاء المحرك ، لا يزالون يتم تحويلهم إلى طرق تقديم عنصر بعد عنصر. يُستخدم هذا لإنشاء شجرة DOM افتراضية لكل دورة تجسيد. ولكن ، كما هو موضح هنا ، يمكن استخدام الوظائف المقدمة لإنشاء رسم بياني تبعي تفاعلي ، كما هو الحال في Solid.
كما ترى ، المكتبات ذات DOM الافتراضي أسرع بكثير. خسائر قوية في الأداء بسبب الإنشاء المفرط للرسم البياني التفاعلي. لاحظ الفرق في المقاييس # 1 و # 2 و # 7 و # 8 و # 9.
الذاكرة أقل إقناعا. يظهر الجحيم وهذا الإصدار من Solid نفس النتيجة تقريبًا. بينما يستخدم ivi المزيد من الذاكرة., Solid, , VDOM. Solid , DOM, DOM. Solid JSX DOM . , . Solid fine grained evaluation . - .
—
تظهر أطر تتبع التحديث التفاعلية نتائج أفضل عند تحديث الصفوف. يوضح هذا الرسم البياني شعبية VDOM في السنوات الأخيرة. يكفي القول أنه إذا كنت تستخدم HyperScript مع هذا التحديث ، فمن الأفضل التبديل إلى Virtual DOM.قوالب السلاسل (domc ، lit-html ، solid-lit)
كل مكتبة هنا لديها شيء مشترك. يتم تقديمها استنادًا إلى قوالب عنصر الاستنساخ ، وتعمل في وقت التشغيل ولا تستخدم VDOM. لكن لا يزال لديهم اختلافات. يستخدم DomC و lit-html من أعلى لأسفل اختلافًا مشابهًا لـ Virtual DOM ، بينما يستخدم Solid رسمًا بيانيًا تفاعليًا. يقسم Lit-html القوالب إلى أجزاء. يقوم DomC و Solid بتجميع القالب في مسارات منفصلة في وقت التشغيل وتحديثها.
هذه الفئة لديها أكبر مجموعة من الأداء. DomC هو الأسرع ، و html المضاء هو الأبطأ. Solid Lit في المنتصف. يوضح DomC أن بساطة الكود تؤدي إلى أفضل أداء.يتراجع DomC فقط في القسم رقم 4 لأنه يحسب اختلاف العقد ، والذي يصبح أكثر تعقيدًا مع زيادة العمق. إنه سريع جدًا ، ولكنك تحتاج إلى التحقق من صحة النتائج على البيانات الضخمة.Solid Lit أكثر إنتاجية من Solid HyperScript. يزيل التجميع الفوري في وقت التشغيل عيوب إنشاء رسم بياني تفاعلي ، مما يسمح للإطار باللحاق ب ivi ، مكتبة VDOM الأسرع (انظر الجدول الكامل في نهاية المقالة).
أظهر DomC نتائج جيدة في استهلاك الذاكرة. حدث هذا بسبب استنساخ عناصر القالب. من الجدير بالذكر أن إنشاء الشفرة في وقت التشغيل يمكن أن يكون له حد أدنى من الأداء مقارنة بالتجميع في مرحلة البناء. ربما تكون هذه مقارنة غير عادلة لـ lit-html لأن إطار العمل لا يستخدم هذه التقنية. ولكن من الإنصاف أن نقول أن html المضاءة أو مكتبات مماثلة مثل hyperHTML أو lighterHTML ليست أفضل طريقة لتطبيق الكلمات المفتاحية ذات قالب. ويمكنك تحقيق نتائج جيدة حتى في وقت التشغيل بدون VDOM.JSX مسبقة التحويل (الصلبة ، الإشارات الصلبة ، الفائض)
تستخدم هذه المكتبات JSX ، الذي يتم تجميعه في DOM أو رسم بياني تفاعلي في مرحلة البناء. يمكن أن تكون القوالب أي شيء ، لكن JSX يوفر شجرة بناء نظيفة تعزز تجربة المطور.
هذه المجموعة لها نتائج متشابهة ، لكن الفرق مهم للغاية. كل ثلاثة استخدام نفس مكتبة لإدارة S.js الدولة . باستخدام مثال Solid Signals ، يمكنك أن ترى أن وظائف التتبع مع استنساخ عناصر القالب تعطي أداءً أكبر. يتم تحميل التطبيق القياسي لـ Solid بشكل زائد باستخدام ES2015 Proxies ، مما يؤدي إلى تفاقم النتيجة على جميع الرسوم البيانية. يستخدم الفائض `document.createElement` ، مما يؤدي إلى تدهور الأداء في الاختبارات حيث يتم إنشاء السطور # 1 و # 2 و # 7 و # 8.
استهلاك الذاكرة له نتائج مماثلة. في هذه الحالة ، تضيف بروكسيات أكثر تعقيدًا من عناصر قالب الاستنساخ.الاستنتاج هنا هو أن الوكلاء يتسببون في تدهور الأداء وينبغي أن تستنسخ المزيد من المكتبات النماذج. من ناحية أخرى ، يمكنك التفكير في خسارة صغيرة في الأداء بسبب الوكلاء كاستثمار. يحتوي المثال الصلب على أقل قدر من التعليمات البرمجية من بين الأمثلة الأخرى - فقط 66 سطرًا ، يحتوي على مسافة أقل بنسبة 15٪ من المسافات البيضاء من Svelte ، وهي مكتبة تفتخر بنفسها.الأفضل في فئته (دومك ، آيفي ، الإشارات الصلبة ، الفانيليا)
الآن دعنا نأخذ الفائزين في كل فئة ونقارنهم بالمثال الوحشي والفعال والمكتوب يدويًا في الفانيلا JavaScript. يمثل كل تنفيذ أحد حلول تتبع الحالة الشعبية. يمكنك رسم تشابه بين هذه المكتبات وبين الثلاثة الكبار: Solid → Vue، DomC → Angular، ivi → React. ستحصل على هذه النتيجة إذا قمت بإزالة كل شيء غير ضروري ، باستثناء العرض ، والتخلص من كود 60-200 كيلوبايت.
DomC و Solid قريبان من حيث الأداء ، و ivi متخلفان بشكل كبير ، لكن DomC ، بشكل عام ، أسرع. تعقيدها مقارنة بـ vanillaJS أقل بشكل ملحوظ ، ولكنه أقل فعالية مع التحديثات الجزئية. هذا المعيار فقط ليس دلالة. يجب على أي شخص يعتقد أن VDOM بطيء أو لديه مضاعفات غير ضرورية التحقق من ذلك من تلقاء نفسه.لن تحصل معظم المكتبات على هذا النوع من الأداء.
كما يقود DomC في الرسم البياني مع الذاكرة. تتفوق المواد الصلبة ذات الحبيبات الدقيقة على VDOM ivi من حيث استهلاك الذاكرة.من المثير للاهتمام أن هذه المكتبات ليست أسوأ بكثير من vanillaJS ، بغض النظر عن الطريقة. كلها سريعة للغاية.حجم الحزمة
أخيرًا ، أود أن أتطرق إلى حجم الحزمة. تركز العديد من الاختبارات الحقيقية فقط على هذه المقاييس. نعم ، حجم الباقة مهم وله علاقة مباشرة بالأداء ، ولكن ما الفرق؟ أظن أن تعقيد التعليمات البرمجية أكثر أهمية من الحجم.
استنتاج
كالعادة ، فإن النتائج في مثل هذه الرسوم البيانية ليست مقنعة تمامًا. العملية نفسها والاستنتاجات التي نتوصل إليها مهمة. في هذه الحالة ، نرى أن DOM نفسه يمثل اختناقًا كبيرًا عندما يتعلق الأمر بالأداء. لدرجة أنه لا توجد تقنية لا لبس فيها للتحايل عليها.
كريستوفر لامبرت مثل The Highlander
No ، الأمر ليس بهذه البساطة. لا DOM ولا VDOM بطيئة. لكن أعتقد أنها تستحق بعضها البعض. أعترف أن خطاب رد فعل الأداء VDOM قادني إلى هذه الأفكار. إن جهل الآراء حول هذا الموضوع أمر مثير للغضب.الادعاء بأن بطيء VDOM يرجع إلى ضعف الوعي. يعد عرض VDOM وحساب الفرق في الحالة من التعقيدات مقارنة بعدم القيام بذلك. ولكن هل غيابه قابل للتوسع؟ وكيفية إجراء تغييرات البيانات؟أرى أن هناك استثناء في كل قاعدة. بشكل عام ، يعد التجميع المسبق مع Fine-Grained في الأطر التفاعلية هو الحل الأسرع. لكن DomC يظهر أداء عالي بدونه. قد تكون طرق JS الأصلية ، مثل عناصر قالب الاستنساخ مع Literals Template ، أفضل حل لتنفيذ ht-html من الشركات الكبيرة (Google). لكن هذا هو أحد أبطأ الأطر في هذا الجدول ولا حتى أفضل تنفيذ لهذه التقنيات. تعتبر Svelte أسرع مكتبة في المجتمع ، لكنها لا تستطيع حتى التنافس بشكل وثيق مع الحلول المقدمة.إذا فازت البرمجة التفاعلية ، فهذا لا يعني أن جميع المكتبات التفاعلية سريعة أو أن المقاييس تعني كل شيء. على الرغم من المقارنة العميقة في هذه المقالة ، أعتقد أنه في الواقع هناك مكتبات سريعة وأخرى أبطأ. حتى لو وجدنا تقنية فائقة ، سنظل نواجه قيودها.نتائج الاختبار لجميع المكتبات في جدول واحد: