डोम के बारे में इतना बुरा क्या है?

Question

मैं लोगों (क्रॉकफोर्ड विशेष रूप से) को यह कहते हुए सुनता रहता हूं कि DOM एक भयानक API है, लेकिन वास्तव में इस कथन को सही नहीं ठहरा रहा है। क्रॉस-ब्राउज़र असंगतताओं के अलावा, कुछ कारण हैं कि DOM को इतना बुरा क्यों माना जाता है?

Comments

Apart from cross-browser inconsistenciesक्या यह पर्याप्त नहीं है?

— यनीस

एक ही सवाल (क्रॉकफोर्ड के संदर्भ सहित) एसओ पर रचनात्मक नहीं होने के रूप में पूछा और बंद किया गया है: डोम के साथ क्या गलत है?

— कुटकी

ज्यादातर लोग जो कहते हैं कि डोम भयानक है या तो अज्ञानी हैं या कहे कि विरासत ब्राउज़र भयानक हैं

— रेयनोस

ईवेंट प्रचार मॉडल गलत है: यह कस्टम व्यवहार को जोड़ने के लिए पैरेंट नोड्स को बाल ईवेंट हैंडलर को ओवरराइड करने की अनुमति नहीं देता है। OOP में इसे वर्चुअल फ़ंक्शंस, पॉलिमॉर्फिज़्म, और डेलिगेशन (इनहेरिटन्स थ्रू कंपोज़िशन) कहा जाता है। घटनाओं को पहले ऊपर से नीचे तक कैद किया जाता है, फिर बुदबुदाया जाता है। एल्म में उन्होंने बहुत पर्याप्त कंपोजेबल मॉडल लागू किया है, जहां पहले इवेंट में "कैप्चर" किया जाता है (माता-पिता से बच्चों के लिए प्रचार)। यह घटनाओं को रद्द करने की अनुमति देता है ("एक विंडो बंद करें?"), और बच्चों के घटक के व्यवहार को ओवरराइड / सजाने।

— ब्रायन हक

Answer 1

क्रॉकफ़ोर्ड ने एक व्यापक प्रस्तुति दी है, जिसका शीर्षक है "एन इनकवेनिएंट एपीआई: द थ्योरी ऑफ़ द डोम" जहां वह कमोबेश डोम पर अपनी राय बताते हैं। यह लोंगिश (1h 18 मी) है, लेकिन क्रॉकफोर्ड की अधिकांश प्रस्तुतियों के रूप में यह काफी सुखद और शिक्षाप्रद है।

क्रॉस ब्राउज़रों की विसंगतियां उनका मुख्य चिंता का विषय है, और मैं मानता हूँ कि यह DOM के बारे में सबसे अधिक कष्टप्रद बात है। वह पहचानता है:

• मालिकाना जाल (ब्राउज़र और सर्वर जाल),
• नियम तोड़ना,
• कॉर्पोरेट युद्ध,
• अत्यधिक समय का दबाव

विभिन्न विसंगतियों के पीछे प्रमुख मुद्दों के रूप में, उस प्रस्तुति, सत्र, या अन्तरक्रियाशीलता को जोड़ना वेब की मूल दृष्टि में कभी भी प्रत्याशित नहीं था। विसंगतियों के कुछ उदाहरणों में शामिल हैं:

• document.all, एक Microsoft केवल सुविधा,
• तथ्य यह है कि nameऔर idविनिमेय हुआ करता था।
• नोड्स प्राप्त करने पर विभिन्न कार्य:
  
  • document.getElementById(id),
  • document.getElementsByName(name),
  • *node*.getElementsByTagName(tagName))

और कुछ और उदाहरणों के साथ जारी है, जो ज्यादातर DOM, मेमोरी लीक, और इवेंट ट्रिकलिंग और बबलिंग को ट्रेस करने का लक्ष्य रखते हैं। एक सारांश स्लाइड है, जिसका शीर्षक "द क्रैक ऑफ डोम" है जो संक्षेप में प्रस्तुत करता है:

• DOM बगलिस्ट में ब्राउज़र के सभी बग शामिल हैं।
• DOM बगलिस्ट में सभी समर्थित ब्राउज़रों में सभी बग शामिल हैं।
• कोई भी DOM पूरी तरह से मानकों को लागू नहीं करता है।
• DOM का अधिकांश भाग किसी भी मानक में वर्णित नहीं है।

संक्षेप में, यह एक गन्दा, गन्दा एपीआई है। यह नाइटपैकिंग की तरह लग सकता है, लेकिन आपको यह ध्यान रखना होगा कि जब आप वेब के लिए विकसित कर रहे हैं, तो आप शायद ही कभी उस ब्राउज़र को चुनें जो आपके ग्राहक उपयोग करेंगे। प्रत्येक प्रमुख ब्राउज़र के कम से कम दो संस्करणों में सब कुछ परीक्षण करने के बाद बहुत जल्द ही पुराना हो जाता है। एक API संगत माना जाता है और DOM ब्राउज़र युद्धों का शिकार था , लेकिन यह बेहतर हो रहा है। यह अभी भी W3C के रूप में प्लेटफ़ॉर्म तटस्थ नहीं है (और मुझे लगता है कि हम सभी) इसे पसंद करेंगे, लेकिन ब्राउज़र विक्रेता पाँच या दस साल पहले की तुलना में सह-संचालन के लिए काफी अधिक उत्सुक लगते हैं।

Comments

क्रॉस-ब्राउज़र असंगतता का डोम से कोई लेना-देना नहीं है। इसे हम "लीगेसी ब्राउज़र" कहते हैं। विरासत ब्राउज़रों के अस्तित्व के लिए DOM को दोष न दें। यह कहने की तरह है कि "लिनक्स बेकार है क्योंकि मैं विरासत एन और एम को जानता हूं और वे चूसते हैं"।

— रेयनोस

document.allमानकों में है

— रेयनोस

@ रेयानोस हाँ और नहीं। ब्राउज़र विक्रेता बहुत लंबे समय तक वेब मानकों के विकास के पीछे प्रमुख ताकत रहे हैं, सब कुछ गड़बड़ कर रहे हैं, लिनक्स के साथ सादृश्य ज्यादा खड़ा नहीं होता है। मैं जो जोर देने की कोशिश कर रहा हूं वह यह है कि डोम स्वयं दोषपूर्ण नहीं है, यह कार्यान्वयन है जो दोषपूर्ण हैं और मानक तरीके से विकसित किया गया असंगत तरीका है। document.allउदाहरण के लिए लें , यह मानकों में है लेकिन एक विलफुल उल्लंघन के रूप में ।

— यनीस

मैं विरासत ब्राउज़रों और DOM को भ्रमित करने वाले लोगों के बारे में शेख़ी करने के लिए परेशान नहीं हो सकता। मैंने एक टिप्पणी छोड़ दी। विरासत ब्राउज़रों के लिए, उनके लिए समर्थन छोड़ना तुच्छ है, बस करो। इसे करने के लिए गोले रखें। या तो आप अपने विकास के जीवन को नियंत्रित करते हैं या IE8 इसे नियंत्रित करता है। मेरा नियंत्रण है।

— रेयनोस

बहुत बढ़िया जवाब; आपके द्वारा उल्लेखित एक और झुंझलाहट यह है कि DOM API बेहद क्रिया है - बस विशिष्ट jQuery कोड की तुलना करें, कहते हैं, एक विशेष नोड बनाम सादे-DOM संस्करण में कुछ विशेषताओं के साथ एक तत्व सम्मिलित करें जो समान करता है।

— तदमर्स

Answer 2

डोम के साथ क्या गलत है? जावा-प्रेरित सिंटैक्स (जो क्रॉकफोर्ड ने छुआ है) के अलावा, कुछ भी नहीं।

"गलत" ब्राउज़र विक्रेताओं के लिए आंशिक रूप से लागू होता है; डेवलपर्स के लिए "गलत" लागू होता है; "गलत" अज्ञान पर लागू होता है।

तो, कहाँ से शुरू करें?

खरगोश के बील में…

ब्राउज़र विक्रेता

सबसे पहले, ब्राउज़र विक्रेताओं ने "सर्वश्रेष्ठ", "सबसे तेज़", "सबसे आसान" आदि होने के लिए दशकों से प्रतिस्पर्धी रूप से लड़ाई लड़ी है, पहले दशक (199x- 2000) में, माइक्रोसॉफ्ट ने रोस्ट पर शासन किया। Internet Explorer ने नवीन विचार प्रस्तुत किए हैं:

• के रूप में innerHTMLऔर ब्राउज़र के HTML पार्सिंग इंजन को उजागर करना outerHTML;
• के साथ आसान पाठकीय हेरफेर innerTextऔर outerText;
• एक ईवेंट मॉडल ( *tachEvent) जो DOM लेवल 2 इवेंट्स ( *EventListener) के लिए खाका था ।

प्रत्येक ने आज के वेब विकास स्टैक के लिए (बेहतर और बदतर के लिए) योगदान दिया है। ओपेरा भी 7 (2003) संस्करण में सभी तीन को लागू करने के लिए चला गया।

हालाँकि, नेटस्केप का अपना DOM ईवेंट मॉडल ( *EventListener) था। 2000 में, यह DOM लेवल 2 इवेंट्स स्पेसिफिकेशन बन गया। सफारी 1 (2003) ने इस मॉडल को लागू किया; ओपेरा 7 (2003) ने भी इस मॉडल को लागू किया। नेटस्केप के खंडहर के रूप में मोज़िला बन गया, फ़ायरफ़ॉक्स 1 (2004) को मॉडल विरासत में मिला।

दूसरे दशक (2000-2004) के पहले खंड के लिए, Microsoft ने सर्वोच्च शासन किया। इंटरनेट एक्सप्लोरर 6 (2001) उस समय का सबसे अच्छा ब्राउज़र था। इसके प्रतियोगियों में से एक, ओपेरा 6 (2001), ने अभी तक DOM स्तर 1 कोर ( createElementएट अल।) को लागू करने के लिए किया था, Microsoft ने विनिर्देशन (1998) बनने से पहले ही इसे इंटरनेट एक्सप्लोरर 4 (1997) में लागू कर दिया था।

हालाँकि, दूसरे दशक का दूसरा खंड (2004–2010) Microsoft के लिए विनाशकारी साबित होगा। 2003 में, Apple ने Safari 1.0 जारी किया; 2004 में, मोज़िला ने फ़ायरफ़ॉक्स 1.0 पूरा किया। Microsoft ब्राउज़र पर्वत पर अपने सिंहासन पर सो रहा था। Internet Explorer 7 को 2006 तक रिलीज़ नहीं किया गया था: Internet Explorer 6 की रिलीज़ की तारीख में वापस पाँच साल का अंतर। 6 के माध्यम से इंटरनेट एक्सप्लोरर 4 संस्करणों के विपरीत, 7 संस्करण थोड़ा नया; डोम परिवर्तन मिनट थे। लगभग ढाई साल बाद, इंटरनेट एक्सप्लोरर 8 जारी किया गया था। Microsoft अपनी नींद से जागा था और देखा कि अन्य वेब विक्रेताओं ने कई वेब मानकों के साथ सह-निर्माण किया था। दुर्भाग्य से, माइक्रोसॉफ्ट के अंतिम वास्तविक नवाचार के बाद से बहुत अधिक समय बीत चुका था। ब्राउज़र विक्रेताओं के बीच एक आंदोलन बनाया गया था। W3C के लिए विनिर्देशन रूप में नई DOM सुविधाएँ जोड़ी जानी थीं; Microsoft के विचारों को अतीत में छोड़ दिया गया था। Microsoft का इवेंट मॉडल (*tachEvent) DOM लेवल 2 इवेंट्स मॉडल के लिए बच गया था। Internet Explorer ने संस्करण 9 (2011) तक पूर्ववर्ती मॉडल को लागू नहीं किया, जो DOM स्तर 3 इवेंट मॉडल बन गया।

Microsoft के (DOM) फ़ॉलिज़ को निम्नलिखित बिंदुओं द्वारा अभिव्यक्त किया जा सकता है:

• विंडोज की एक मुख्य विशेषता के रूप में उपस्थिति, और परिणामस्वरूप ओएस-स्तरीय सुरक्षा आवश्यकताओं;

• क्लाइंट-साइड कोड के लिए ActiveX पर निर्भरता;

• नवाचार जो संस्करण 6 (2001) के बाद उत्सुकता से बंद हो गया।

---

(वेब) डेवलपर्स

दूसरे, डेवलपर्स दोष की एक निश्चित राशि वहन करते हैं। जैसा कि वेब ने बंद करना जारी रखा है, अधिक से अधिक लोग वेब विकास में "दबंग" हैं। इससे प्रतिभा और काम नैतिकता में कमजोर पड़ गया था। हालाँकि, समस्या मुख्य रूप से दृष्टिकोण के साथ है। "इसे जल्दी करो" "इसे सही तरीके से पूरा करने पर पूर्वता ले ली है।" नतीजतन, असंख्य वेब पेज विभिन्न ब्राउज़रों के साथ असंगत हैं। इस असंगतता के प्रमुख कारणों में से एक "उपयोगकर्ता एजेंट सूँघने" नामक एक अभ्यास है। हालाँकि यह प्रथा आज भी प्रयोग में है, लेकिन यह गलत और हानिकारक दोनों ही साबित हुई है। ओपेरा यहां तक ​​कि संस्करण 10 (2009) और इसके बाद के संस्करण में "9.80" पर उपयोगकर्ता एजेंट संस्करण को "फ्रीज" करने के लिए चला गया। यह गलत स्क्रिप्ट को तोड़ने से रोकने का इरादा था। एक बेहतर अभ्यास जिसे "कहा जाता है"

---

अज्ञान

तीसरी बात, दोष के लिए मेरा पसंदीदा बिंदु अज्ञानता है; इस तथ्य में अज्ञानता कि ब्राउज़र विक्रेता एकीकृत विनिर्देशों को बनाने के लिए लगभग पर्याप्त रूप से एक साथ काम नहीं करते थे; इस तथ्य में अज्ञानता है कि माइक्रोसॉफ्ट ने अन्य ब्राउज़रों के उपयोगकर्ताओं को हिला दिया; इस तथ्य में अज्ञानता कि डेवलपर्स या तो बहुत आलसी या बहुत अधिक मैओपिक हैं, जो शोध करने वाले ब्राउज़रों को परेशान करने के लिए (विशेष रूप से वे जो प्रचलित नहीं हैं ।) एपीआई और कार्यान्वयन में कई अंतर हैं। अधिकांश को शोध और परीक्षण दोनों की प्रचुर मात्रा के साथ एक सरलीकृत अभी तक रक्षात्मक दृष्टिकोण (DOM 0 पर निर्भरता) से बचा जा सकता है। अज्ञानता ने इस धारणा को जन्म दिया है कि इंटरनेट एक्सप्लोरर 6 पृथ्वी पर एक धब्बा है (पूर्व में सिंहासन पर मौजूद ब्राउज़र पर इसका स्थान याद रखें।)

---

प्रतिबिंब

अफसोस की बात है, डोम सिर्फ एक गलत समझा एपीआई है। पत्थर फेंकने की बहुत सी इच्छाएँ (FUD के माध्यम से), लेकिन अपनी पेचीदगियों को सीखने की बहुत कम इच्छा। इस अज्ञानता का एक परिणाम डोम "चयनकर्ताओं" की शुरूआत है। DOM एट हार्ट, डॉक्युमेंट ट्री (हे) में हेरफेर करने के लिए एक एपीआई है। ट्री ट्रैवर्सल का उपयोग एक जटिल दस्तावेज के रूप में दी गई जटिल समस्याओं के लिए किया जाना चाहिए। DOM सेलेक्टर्स API की शुरुआत के साथ, एक डेवलपर अब ब्राउज़र के CSS ट्रैवर्सल इंजन का लाभ उठा सकता है। यह काफी सुविधाजनक है, लेकिन यह एक दस्तावेज़ पेड़ के असली रूप को छुपाता है। "चयनकर्ताओं" के साथ, तत्व नोड पुनर्प्राप्ति प्राथमिक है। हालाँकि, DOM में ग्यारह अन्य नोड प्रकार निर्दिष्ट हैं। क्या पाठ नोड्स? टिप्पणी करें? दस्तावेज़ नोड्स? ये भी नोड्स हैं जो अक्सर डोम के साथ बातचीत करते समय वांछित होते हैं।

---

निष्कर्ष

संक्षेप में, अपना समय ले लो और विभिन्न डोम विनिर्देशों को पढ़ें। अधिक से अधिक ब्राउज़र में टेस्ट कोड। यदि इंटरनेट एक्सप्लोरर को अजीब व्यवहार करना माना जाता है, तो MSDN से परामर्श करें। सबसे अधिक बार, व्यवहार का दस्तावेजीकरण किया जाता है।

(ऐतिहासिक उपाख्यान त्रुटिपूर्ण हो सकते हैं और हो सकते हैं; कोई भी गलतियाँ उठाए जाने का स्वागत है।)

-मैट

Comments

ओपेरा यहां तक ​​कि "फ्रीज" तक चला गया - मुझे इस तरह के दृष्टिकोण से नफरत है क्योंकि यह काफी शॉर्टसाइटेड है (कुछ डेवलपर्स कोड नहीं कर सकते हैं, इसलिए एपीआई को उनकी मदद करने के लिए स्क्रू करते हैं)। आपको आमतौर पर ब्राउज़र प्रकार और संस्करण प्राप्त करने की आवश्यकता होती है जब उस ब्राउज़र में एक विशिष्ट बग होता है जिसे आपके ग्राहक फिक्सिंग पर जोर देते हैं। विशिष्ट ब्राउज़र के लिए फिक्सिंग कुछ "बग डिटेक्शन" को लागू करने की तुलना में बहुत आसान है (यानी "फीचर डिटेक्शन का उल्टा")।

— पावेल होरल

Answer 3

DOM एक भयानक API है

वह गलत है । DOM एक भयानक API नहीं है।

• सबसे पहले, याद रखें कि DOM भाषा अज्ञेय है। सभी प्रमुख भाषाओं ने एपीआई को लागू किया है। ऐसा इसलिए है क्योंकि आप इसे ब्राउज़र में उपयोग नहीं करते हैं, लेकिन हर जगह आपको XML से निपटने की आवश्यकता होती है।

• दूसरा, ध्यान दें कि DOM कक्षाओं को नहीं बल्कि इंटरफेस को परिभाषित करता है। इसका एक बहुत महत्वपूर्ण निहितार्थ है: भाषाएं इसे अपने निर्माण और दर्शन के अनुरूप लागू कर सकती हैं। यह सभी भाषाओं को दूसरों के साथ कार्यान्वयन में सुसंगत होने से मुक्त करता है।

• तीसरा, DOM, XML (SAX होने के नाते) को पार्स करने के दो प्रमुख तरीकों में से एक है, और आपके संदर्भ के आधार पर, DOM बहुत कुशल हो सकता है।

क्या आप ब्राउज़र डोम का उल्लेख कर रहे हैं। और, मैं मानता हूं कि DOM "ब्राउज़र में" बुरा महसूस करता है। इसका कारण ब्राउज़र असंगतताएं हैं। लेकिन, मैं असहमत हूं कि वे ब्राउज़र में DOM की खराब प्रतिष्ठा का एकमात्र कारण हैं।

• सबसे पहले, यदि आप इसके बारे में सोचते हैं, तो DOM उन क्षेत्रों में से एक है जहाँ इन असंगतताओं को दूर करना अपेक्षाकृत आसान है। तुलना में, घटनाओं, उदाहरण के लिए बहुत मुश्किल और सामान्य करने के लिए कष्टप्रद हैं।

• दूसरा, DOM फीचर्स के लिए फीचर डिटेक्शन अन्य क्षेत्रों की तुलना में सरल है।

• तीसरा, DOM 3 बेहतर है - और आज सभी ब्राउज़र इसका सबसे अधिक समर्थन करते हैं।

निश्चित रूप से, असंगतताएं कष्टप्रद हैं, लेकिन जब आप उनके लिए नीचे आते हैं, तो डोम बहुत कम परेशान होता है।

मैं प्रोप्रायटरी ट्रैप, कॉरपोरेट वारफेयर आदि कारणों से भी असहमत हूं।

• मुझे लगता है कि यह जावास्क्रिप्ट के एक हल्के भाषा होने के दर्शन के बीच का डिस्कनेक्ट है, और डोम के कार्यान्वयन को जावा से प्रेरित किया जा रहा है - जिसने हताशा में बहुत योगदान दिया है।

• दूसरे, DOM को XML के लिए डिज़ाइन किया गया है, और इसे HTML के लिए अनुकूलित किया गया है। इसलिए ब्राउज़र में, हमारे पास दो डोम हैं - HTML DOM और XML DOM - और वे असंगत हैं।

• तीसरा, ब्राउज़र में DOM ट्रैवर्सल अच्छा नहीं है। हमारे पास HTML DOM के लिए XPath नहीं है, इसलिए CSS चयनकर्ता इंजन से पहले, ट्रैवर्सल्स करना वास्तव में थकाऊ था।

अंत में, मुझे लगता है कि आज , आधुनिक ब्राउज़रों के साथ, (और पुराने ब्राउज़रों के साथ धीरे-धीरे लुप्त होती) कोई कारण नहीं है कि डोम को बुरा कहा जाना चाहिए। यह निश्चित रूप से ब्राउज़र में बेहतर होने वाला है - एपीआई और कार्यान्वयन दोनों।

Comments

घटनाओं को सामान्य करने के लिए तुच्छ के रूप में कर रहे हैं: \

— Raynos

इसके बारे में सोचें - अगर आपको currentTargetइवेंट ऑब्जेक्ट के लिए संपत्ति का समर्थन करना था - तो क्या यह तुच्छ होगा?

— ट्रेकरोड

ईवेंट को बुदबुदाते हुए कोड की 100 लाइनों की तरह है: \

— रेयनोस

currentTargetक्या केवल घटना बुदबुदाती नहीं है - और क्या वास्तव में अपने स्वयं के घटना बुदबुदाहट को लागू करना बुद्धिमानी होगी?

— ट्रेकरोड

और dataManagerबाहर बैठने के साथ , आप कहते हैं कि कोड तुच्छ है? :)

— ट्रेक्रोडर