👩🏿‍🌾 🌬️ 🏠 DOM के साथ काम करने का सबसे अच्छा तरीका है 👂🏻 🚴🏻 🏂🏿

जब मैं ठोस पर लिख रहा था , मुझे ग्राफ़ (बेंचमार्क) पर प्रदर्शन को अनुकूलित करने के प्रयासों की संख्या का अनुमान लगाने का अवसर मिला।

DOM एक फ्रंट-एंड टोंटी डेवलपमेंट है। विभिन्न समाधान समान परिणामों को जन्म दे सकते हैं। हर हफ्ते नई लाइब्रेरी दिखाई देती हैं, जिसमें सबसे अच्छा संयोजन होता है, सही संयोजन बनाने के लिए। कुछ समय बाद, मेरी आँखें इस तरह के समाधानों से दूर भागने लगती हैं।

मुझे गलत मत समझो। मुझे जीवन में आने वाले नए विचारों को देखना पसंद है, लेकिन उनमें सभी दोष हैं, और कभी-कभी सुविधा या उत्पादकता में नुकसान होता है। मैं इस तरह के निर्णय के परिणामों को समझता हूं, लेकिन मैं अपनी टिप्पणियों को साझा करना चाहता हूं।

DOM के साथ काम करने का सबसे तेज़ तरीका क्या है:

वर्चुअल डोम
टैग की गईं साक्षरता साहित्य
बारीक-बारीक वेधशालाएँ

तुलना

जेएस फ्रेमवर्क बेंचमार्क जावास्क्रिप्ट यूआई फ्रेमवर्क के प्रदर्शन की तुलना करने के लिए सबसे अच्छा ओपन सोर्स प्रोजेक्ट है। आधिकारिक परिणामों का उपयोग करने के बजाय स्थानीय रूप से परीक्षण चलाना बेहतर है। मशीन द्वारा परिणाम भिन्न हो सकते हैं। चूंकि मैं एक कमजोर मशीन पर परीक्षण कर रहा हूं, इसलिए प्रदर्शन काफी कम हो जाएगा।

मैं कुछ समाधानों के अतिरेक को स्पष्ट करने के लिए DOM ट्री को प्रस्तुत करने में सर्वश्रेष्ठ दृष्टिकोण अपनाऊंगा। मैं लागतों को अलग-अलग करने के लिए सॉलिड की क्षमता का समर्थन करने के लिए सॉलिड की क्षमता का उपयोग करके ऐसा करूंगा क्योंकि चर परिवर्तन करते हैं और अन्य रूपरेखाओं से समान परिणाम के साथ इसकी तुलना करते हैं। आइए उन पर एक नज़र डालें।

ठोस की किस्में:

क्लोन-डोम नोड नोड्स में निर्मित परिवर्तन-ट्रैकिंग कार्यों के शीर्ष पर ES2015 प्रॉक्सी सेटर के साथ फ्रेमवर्क का ठोस संस्करण। यह JSX टेम्प्लेट (कोड) को प्री-कंपाइल करके हासिल किया गया
सॉलिड-सिग्नल्स - यह वर्जन भी पिछले वाले की तरह ही है, लेकिन प्रॉक्सी के बजाय कच्चे सिग्नल्स का इस्तेमाल किया जाता है। यह लाइब्रेरी के उपयोग को जटिल बनाता है, लेकिन अंत में हमें एक छोटा बंडल और बेहतर प्रदर्शन (कोड) मिलता है।
सॉलिड लिट - इस संस्करण रनटाइम (कोड) में JSX precompilation का उपयोग नहीं करता है
सॉलिड-एच - यह संस्करण मक्खी पर `document.createElement` बनाने के लिए हाइपरस्क्रिप्ट का उपयोग करता है। बाकी ठोस (कोड) के समान कार्यान्वयन का उपयोग करता है

अन्य पुस्तकालय:

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)
नरक रिएक्ट क्लोन का सबसे तेज़ और सबसे तेज़ वर्चुअल डोम लाइब्रेरी में से एक है। सर्वश्रेष्ठ प्रदर्शन के लिए विशेष JSX निर्देशों का उपयोग करता है (कोड)

आपके कुछ पसंदीदा फ्रेमवर्क यहां नहीं हो सकते हैं, लेकिन यह सूची उन सभी तकनीकों के अनुकूलित संस्करणों को प्रदर्शित करती है, जिन्हें आप सबसे लोकप्रिय फ्रेमवर्क में देखेंगे। आप इसे अपने पुस्तकालय की अधिकतम क्षमताओं का मूल्यांकन करने के लिए एक संकेतक के रूप में देख सकते हैं। यदि आप लोकप्रिय रूपरेखा के प्रदर्शन की तुलना करने में रुचि रखते हैं, तो मैं इस चार्ट की सलाह देता हूं।

तुलना के लिए, मैं वेब असेंबली जोड़ना चाहूंगा। दुर्भाग्य से, इस लेखन के समय, WASM रिकॉर्ड उच्च-स्तरीय अमूर्तता के बिना एक वैनिला कार्यान्वयन था। (बाद में उन्होंने फ्रेमवर्क के लिए wasm-bindgen जोड़ा - लगभग। अनुवादक)

परिणाम

हाइपरस्क्रिप्ट (नरक, ivi, ठोस-एच)

हाइपरस्क्रिप्ट, मार्कअप को फ़ंक्शंस की संरचना के रूप में प्रदर्शित करता है (जैसे h या React.createElement)। उदाहरण के लिए:

h('div', {id: 'my-element'}, [
  h('span', 'Hello'),
  h('span', 'John')
])

वर्चुअल डोम फ्रेमवर्क में यह संपत्ति है। भले ही वे JSX या अन्य DSL टेम्पलेट इंजन का उपयोग करते हों - हुड के तहत वे अभी भी तत्व-दर-तत्व रेंडर तरीकों में परिवर्तित हो जाते हैं। इसका उपयोग प्रत्येक रेंडर चक्र के लिए एक वर्चुअल DOM ट्री बनाने के लिए किया जाता है। लेकिन, जैसा कि यहां दिखाया गया है, रेंडर किए गए कार्यों का उपयोग प्रतिक्रियात्मक निर्भरता ग्राफ बनाने के लिए किया जा सकता है, जैसे कि सॉलिड के मामले में।

जैसा कि आप देख सकते हैं, एक आभासी डोम के साथ पुस्तकालय बहुत तेज हैं। प्रतिक्रियाशील ग्राफ के अत्यधिक निर्माण के कारण प्रदर्शन में ठोस कमी आती है। बेंचमार्क # 1, # 2, # 7, # 8, # 9 में अंतर देखें।

याददाश्त कम पक्की है। इन्फर्नो और सॉलिड का यह संस्करण लगभग एक ही परिणाम दिखाता है। जबकि ivi अधिक मेमोरी का उपयोग करता है।

, Solid, , VDOM. Solid , DOM, DOM. Solid JSX DOM . , . Solid fine grained evaluation . - .
—

रिएक्टिव अपडेट ट्रैकिंग फ्रेमवर्क, पंक्तियों को अपडेट करते समय बेहतर परिणाम दिखाते हैं। यह ग्राफ हाल के वर्षों में VDOM की लोकप्रियता की व्याख्या करेगा। यह कहने के लिए पर्याप्त है कि यदि आप इस अद्यतन के साथ हाइपरस्क्रिप्ट का उपयोग करते हैं, तो आप वर्चुअल डोम पर बेहतर स्विच करते हैं।

स्ट्रिंग टेम्पलेट्स (डोम, लिट-html, सॉलिड-लिट)

यहाँ प्रत्येक पुस्तकालय में कुछ न कुछ सामान्य है। वे क्लोनिंग तत्व टेम्पलेट्स के आधार पर प्रदान किए जाते हैं, रनटाइम में चलते हैं और वीडीओएम का उपयोग नहीं करते हैं। लेकिन उनमें अभी भी अंतर है। DOMC और लिट-html, वर्चुअल डोम के समान ही टॉप-डाउन का उपयोग करते हैं, जबकि सॉलिड एक प्रतिक्रियाशील ग्राफ का उपयोग करता है। लिट-एचटीएमएल भागों में टेम्पलेट्स को विभाजित करता है। DOMC और सॉलिड, रनटाइम में टेम्पलेट को अलग-अलग रास्तों में संकलित करते हैं और उन्हें अपडेट करते हैं।

इस श्रेणी में प्रदर्शन की व्यापक रेंज है। DOMC सबसे तेज़ है, और lit-html सबसे धीमा है। सॉलिड लिट बीच में है। DOMC दर्शाता है कि कोड की सादगी सर्वश्रेष्ठ प्रदर्शन की ओर ले जाती है।

DOMC केवल सेक्शन # 4 में ही बैठता है क्योंकि यह नोड्स के अंतर की गणना करता है, जो गहराई बढ़ने पर अधिक जटिल हो जाता है। यह बहुत तेज़ है, लेकिन आपको बड़े डेटा पर परिणामों को मान्य करने की आवश्यकता है।

सॉलिड हाइपरस्क्रिप्ट की तुलना में सॉलिड लिट अधिक उत्पादक है। रनटाइम में त्वरित संकलन प्रतिक्रियाशील ग्राफ बनाने की कमियों को दूर करता है, जिससे फ्रेम को आईवीआई, सबसे तेज़ VDOM लाइब्रेरी (लेख के अंत में पूर्ण तालिका देखें) के साथ पकड़ने की अनुमति मिलती है।

DOMC ने मेमोरी खपत में अच्छे परिणाम दिखाए। यह टेम्पलेट तत्वों के क्लोनिंग के कारण हुआ। यह उल्लेखनीय है कि रनटाइम में कोड जनरेशन का निर्माण मंच पर संकलन की तुलना में न्यूनतम प्रदर्शन ओवरहेड हो सकता है। शायद यह lit-html के लिए एक अनुचित तुलना है क्योंकि फ्रेमवर्क इस तकनीक का उपयोग नहीं करता है। लेकिन यह कहना उचित है कि हाइपर HTML या लाइटर HTML जैसी लिट-html या समान लाइब्रेरी टैगेड टेम्प्लेट साहित्य को लागू करने का सबसे अच्छा तरीका नहीं है। और आप VDOM के बिना रनटाइम में भी अच्छे परिणाम प्राप्त कर सकते हैं।

Precompiled JSX (ठोस, ठोस-संकेत, अधिशेष)

ये लाइब्रेरी JSX का उपयोग करती हैं, जो बिल्ड स्टेज पर DOM या रिएक्टिव ग्राफ में संकलित होती है। टेम्प्लेट कुछ भी हो सकते हैं, लेकिन JSX एक साफ सिंटैक्स ट्री प्रदान करता है जो डेवलपर अनुभव को बढ़ाता है।

इस समूह के समान परिणाम हैं, लेकिन अंतर बहुत महत्वपूर्ण है। तीनों एसजेएस राज्य का प्रबंधन करने के लिए एक ही पुस्तकालय का उपयोग करते हैं । सॉलिड सिग्नल उदाहरण का उपयोग करके, आप देख सकते हैं कि टेम्प्लेट तत्वों के क्लोनिंग के साथ ट्रैकिंग फ़ंक्शन अधिक प्रदर्शन देते हैं। सॉलिड का मानक कार्यान्वयन ES2015 प्रॉक्सी का उपयोग करके अतिभारित है, जो सभी ग्राफ़ पर परिणाम को खराब करता है। अधिशेष `document.createElement` का उपयोग करता है, जो उन परीक्षणों पर प्रदर्शन को नीचा दिखाता है जहां # 1, # 2, # 7, # 8 बनाई जाती हैं।

मेमोरी खपत के समान परिणाम हैं। इस मामले में, समरूपता क्लोनिंग टेम्पलेट तत्वों की तुलना में अधिक जटिलता जोड़ती है।

यहां निष्कर्ष यह है कि परदे के पीछे प्रदर्शन में गिरावट आती है और अधिक पुस्तकालयों को क्लोन करना चाहिए। दूसरी ओर, आप एक निवेश के रूप में परदे के पीछे के प्रदर्शन में एक छोटे से नुकसान पर विचार कर सकते हैं। अन्य उदाहरणों के बीच ठोस उदाहरण में सबसे छोटी मात्रा है - केवल 66 पंक्तियाँ, इसमें Svelte की तुलना में 13% कम गैर-व्हाट्सएप है - एक पुस्तकालय जो अपने अतिसूक्ष्मवाद पर गर्व करता है।

कक्षा में सर्वश्रेष्ठ (डोम, आइवी, सॉलिड-सिग्नल्स, वैनिलज)

अब हम प्रत्येक श्रेणी में विजेताओं को लेते हैं और उनकी तुलना वैनिला जावास्क्रिप्ट में क्रूर, प्रभावी, हाथ से लिखे उदाहरण से करते हैं। प्रत्येक कार्यान्वयन लोकप्रिय राज्य ट्रैकिंग समाधानों में से एक का प्रतिनिधित्व करता है। तुम भी इन पुस्तकालयों और बिग थ्री के बीच एक सादृश्य आकर्षित कर सकते हैं: ठोस → Vue, DOMC → कोणीय, ivi → प्रतिक्रिया। आपको यह परिणाम मिलेगा यदि आप रेंडर को छोड़कर, सब कुछ शानदार हटा देते हैं और 60-200kb कोड से छुटकारा पा लेते हैं।

DOMC और सॉलिड प्रदर्शन के लिहाज से करीब हैं, ivi काफी पीछे है, लेकिन समग्र रूप से, DOMC तेज है। वेनिलाजेएस की तुलना में इसकी जटिलता काफी कम है, लेकिन यह आंशिक अपडेट के साथ कम प्रभावी है। केवल यह मानदंड सांकेतिक नहीं है। जो कोई भी सोचता है कि वीडीओएम धीमा है या अनावश्यक जटिलताएं हैं, उन्हें अपनी जांच करनी चाहिए।

अधिकांश पुस्तकालयों में इस तरह का प्रदर्शन कभी नहीं होगा।

DOMC मेमोरी के साथ ग्राफ में भी अग्रणी है। मेमोरी खपत के संदर्भ में फाइन-ग्रेन्ड सॉलिड आउटपरफॉर्म VDOM ivi।

दिलचस्प है, इन पुस्तकालयों वेनिलाजेएस की तुलना में बहुत खराब नहीं हैं, भले ही विधि की परवाह किए बिना। वे सभी बहुत तेज हैं।

बंडल आकार

अंत में, मैं बंडल के आकार पर स्पर्श करना चाहूंगा। कई वास्तविक परीक्षण केवल इन मैट्रिक्स पर ध्यान केंद्रित करते हैं। हां, बंडल का आकार महत्वपूर्ण है और प्रदर्शन के साथ सीधा संबंध है, लेकिन क्या अंतर है? मुझे संदेह है कि कोड जटिलता आकार से अधिक महत्वपूर्ण है।

निष्कर्ष

हमेशा की तरह, ऐसे ग्राफ़ में परिणाम कभी भी पूरी तरह से आश्वस्त नहीं होते हैं। प्रक्रिया स्वयं और हमारे द्वारा किए गए निष्कर्ष महत्वपूर्ण हैं। इस मामले में, हम देखते हैं कि जब प्रदर्शन की बात आती है तो DOM स्वयं एक बड़ी अड़चन है। इतना तो है कि इसे दरकिनार करने की कोई नायाब तकनीक नहीं है।

क्रिस्टोफर लैम्बर्ट द हाइलैंडर

नहीं के रूप में, यह इतना आसान नहीं है। न तो DOM और न ही VDOM धीमा है। लेकिन मेरा मानना है कि वे एक दूसरे के लायक हैं। मैं मानता हूं कि वीडीओएम प्रदर्शन प्रतिक्रिया के बयान ने मुझे इन विचारों के लिए प्रेरित किया। इस विषय पर विचारों का अज्ञान भयावह है।

कमजोर जागरूकता के कारण VDOM धीमा होने का दावा किया जाता है। वीडीओएम का प्रतिपादन और राज्य में अंतर की गणना न करने की तुलना में एक जटिलता है। लेकिन क्या इसकी अनुपस्थिति मापनीय है? और डेटा परिवर्तन कैसे करें?

मैं देखता हूं कि हर नियम में एक अपवाद है। सामान्य तौर पर, प्रतिक्रियाशील चौखटे में ललित-दाने के साथ संयुक्त precompilation सबसे तेज़ समाधान है। लेकिन DOMC इसके बिना उच्च प्रदर्शन दिखाता है। Native JS तरीके, जैसे कि टेम्प्लेट टेम्प्लेट लिटरल्स के साथ टेम्पलेट तत्वों को क्लोन करना, बड़े निगमों (Google) से लिट-html को लागू करने के लिए सबसे अच्छा समाधान हो सकता है। लेकिन यह इस तालिका में सबसे धीमी रूपरेखाओं में से एक है और इन प्रौद्योगिकियों का सबसे अच्छा कार्यान्वयन भी नहीं है। Svelte को समुदाय का सबसे तेज़ पुस्तकालय माना जाता है, लेकिन यह प्रस्तुत समाधानों के साथ भी प्रतिस्पर्धा नहीं कर सकता है।

यदि प्रतिक्रियाशील प्रोग्रामिंग जीत जाती है, तो इसका मतलब यह नहीं है कि सभी प्रतिक्रियाशील पुस्तकालय तेज हैं या मैट्रिक्स का मतलब सब कुछ है। इस लेख में गहरी तुलना के बावजूद, मुझे लगता है कि वास्तव में तेज पुस्तकालय और धीमे हैं। अगर हम सुपर तकनीक पाते हैं, तब भी हम इसकी सीमाओं का सामना करेंगे।

एक तालिका में सभी पुस्तकालयों के परीक्षा परिणाम:

DOM के साथ काम करने का सबसे अच्छा तरीका है