Vanilla JavaScript से DOM manipulation को पूरी तरह सीखें

• यह लेख Vanilla JavaScript का उपयोग करके Document Object Model (DOM) manipulation में महारत हासिल करने पर चर्चा करता है.
• Angular, VueJS, React, Solid, Svelte जैसे आधुनिक tools के उपयोग के बावजूद, यह web development के लिए browser DOM API को समझने के महत्व पर ज़ोर देता है.
• लेखक basic browser API, आसानी से समझ आने वाले examples, real-time demos, tips और best practices, real-world use cases, तथा modern browsers और Internet Explorer के साथ compatibility सहित संसाधनों का एक संग्रह प्रदान करते हैं.
• इन संसाधनों को तीन स्तरों में बाँटा गया है: basic, intermediate, और advanced.
• basic स्तर में user's color scheme preference के अनुसार favicon को dynamically बदलना, webpage का reading time निकालना, और CSS root variables को dynamically update करना जैसे कार्य शामिल हैं.
• intermediate स्तर में Shift+Tab key combination का उपयोग करके text area में indentation हटाना, full-screen mode में जाना, और spin input बनाना जैसे कार्य शामिल हैं.
• advanced स्तर में custom cursor बनाना, HTML strings को sanitize करना, और custom scrollbar बनाना जैसे कार्य शामिल हैं.
• लेखक modal खोलते समय layout shift से बचने और text node का bounding rectangle प्राप्त करने जैसे tips भी देते हैं.
• लेख का समापन frontend technical content पर लेखक के newsletter की subscription invitation के साथ होता है.

[GN⁺]

Hacker News की राय

• उदाहरणों की सूची शानदार है, और सिर्फ कुछ उदाहरण सरसरी तौर पर देखने पर भी इसकी सावधानी और डिटेल हैरान करने वाली लगती है
  React जैसे प्लेटफॉर्म से छोटे और अधिक minimal implementation की ओर जाते समय मैं अक्सर अटक जाता हूं कि standard JS में जटिल patterns को कैसे संभालूं, लेकिन कोड देखने पर कई बार लगता है, “यह तो किसी विशाल library में ढेर सारी properties पास करने से कहीं आसान है”

  • RiotJS के 3–4 major updates झेलने के बाद मुझे भी कुछ ऐसी ही समझ आई
    minimal JS framework भी जब मासूम दिखने वाले feature requests जमा होने लगते हैं, तो आखिरकार hooks, events और side effects की patching का राक्षस बन जाना आसान है
    आजकल मैं jQuery भी नहीं इस्तेमाल करता, और ES modules जैसी चीजें code organization के लिए इस्तेमाल करता हूं, लेकिन इसके लिए खास तौर पर npm command चलाने की जरूरत नहीं होती। यह कोई ऐसी चीज नहीं है जिसे vendor के रूप में खींचकर लाना पड़े, बल्कि global browser standard है
    आजकल मैं MDN को बाइबल की तरह देखता हूं। भरोसा करके चलते रहें तो यह लगभग अंत तक ले जाता है, और frameworks किसी बिंदु के बाद उल्टा अड़चन बनने लगते हैं। 5 साल पहले तक बात इतनी आगे नहीं थी, लेकिन browser APIs तेजी से modules, flexbox, grid जैसे शक्तिशाली और consistent primitives की ओर converge हुए हैं
  • मूल लेख के उदाहरण web client frameworks से प्रतिस्पर्धा करने वाले नहीं हैं। frameworks आम तौर पर जिस समस्या को हल करते हैं, वह state management और state बदलने पर UI को update करना है
    उदाहरण के लिए, मूल लेख के ज्यादातर उदाहरण ऐसे code के करीब हैं जिन्हें React इस्तेमाल करने पर भी खुद लिखना पड़ेगा

• side project के रूप में अभी बिना नाम वाली “web designers के लिए vim” जैसी चीज बना रहा हूं। Webflow की तरह browser में websites या components बनाता है, लेकिन सब कुछ command language से driven है
  शुरुआत में मैंने तय किया था कि framework के बिना करूंगा। 2009 से यह काम कर रहा हूं और frameworks छूने से पहले भी लंबे समय तक JS इस्तेमाल कर चुका था, इसलिए लगा कि native DOM API काफी होगा
  लेकिन data को DOM के अंदर-बाहर ले जाना इतना उबाऊ और error-prone था कि मानसिक स्वास्थ्य के लिए आखिरकार मैंने खुद एक mini framework लिखना शुरू कर दिया। तभी याद आया कि शुरुआत में frameworks इस्तेमाल करने की वजह क्या थी। आखिर किसी न किसी रूप में framework इस्तेमाल करना ही पड़ता है; फर्क सिर्फ इतना है कि वह खुद बनाया हुआ custom है या community द्वारा बनाया गया industry standard
  जिन sites में interaction कम हो, उनके लिए native DOM अच्छा है, और React इस्तेमाल करने वाली ज्यादातर sites को शायद उसकी जरूरत भी नहीं होती। लेकिन product में जरा भी nuance या complexity हो तो मैं framework इस्तेमाल करके झंझट से बचूंगा। आखिरकार Svelte पर चला गया और काफी ज्यादा संतुष्ट हूं

  • बेहद minimal projects आखिर में jquery या lodash का आधा हिस्सा फिर से implement कर देते हैं। tree shaking अच्छे से करने वाली ramda जैसी अच्छी libraries ढूंढकर उन्हें संभलकर इस्तेमाल करना कहीं आसान है
  • “अगर आप framework नहीं चुनते, तो आप खुद एक बना लेते हैं” — यह बात बिल्कुल सही है
  • यह application बनाने का मामला है, इसलिए सिर्फ description से ही अंदाजा लगाया जा सकता है कि DOM interactions को wrap करना बेहतर होगा
    अगर interaction वाली website है, तो DOM manipulation ज्यादा fundamental और universal technology इस्तेमाल करने, build process हल्का या न होने, execution तेज होने और explicit होने के कारण बेहतर विकल्प हो सकता है
    बेशक grey areas बहुत हैं, लेकिन यह case ठीक उसी category में आता है जहां framework फायदेमंद है
  • आजकल SvelteKit SSR-centric है, और Svelte में खुद default client-side router नहीं है। CSR single-page app में Svelte इस्तेमाल करने की कोशिश की थी, लेकिन छोड़ दिया

• सिर्फ value.startsWith('javascript:') से vulnerability पैदा हो सकती है। URL के पहले मनचाहा whitespace आ सकता है, इसलिए कम से कम value.trim().startsWith('javascript:') जरूरी है
  फिर भी मुझे लगता है कि blocklist से बेहतर allowlist है। सिर्फ http:, https: और जरूरत हो तो mailto:, ftp:, sftp: जैसे protocols allow करें, और / से शुरू होने वाले relative URLs को शायद allow किया जा सकता है
  हालांकि असल में URL बन सकने वाली सभी attributes को सही ढंग से handle करना होगा, इसलिए आखिरकार कुछ tags और उनकी attributes को ही allow करने का तरीका बेहतर होगा

  • अगर बहुत पुराने browsers support करने की जरूरत नहीं है [1], तो URL parsing browser पर छोड़ने वाला आसान तरीका अच्छा है। उदाहरण के लिए ['http:', 'https:', 'mailto:', 'tel:'].includes(new URL(value, location.origin).protocol) की तरह handle कर सकते हैं
    [1] https://caniuse.com/url
  • यहां शायद इस लेख के “Sanitize HTML strings” की बात हो रही है: https://phuoc.ng/collection/html-dom/sanitize-html-strings/
    इस लेख से यह impression नहीं मिलना चाहिए कि HTML sanitization इतनी आसान है। अंत में https://github.com/cure53/DOMPurify का जिक्र तो है, लेकिन मेरी राय में इसे खुद लिखने की कोशिश न करने को कहीं ज्यादा strongly कहना चाहिए और सिर्फ DOMPurify recommend करना चाहिए
    इस issue पर मैंने एक issue खोला है: https://github.com/phuocng/html-dom/issues/281

• जानने लायक उपयोगी सूची लगती है, और मैंने सब नहीं देखा है, लेकिन अब तक ठीक लग रही है
  पहला उदाहरण खोलकर देखा तो window.matchMedia('(prefers-color-scheme: dark)') को बेवजह दो बार चला रहा है
  अगर setFavicon को event listener callback के रूप में इस्तेमाल करना है, तो callback में पास होने वाले event parameter के event.matches का इस्तेमाल किया जा सकता है
  व्यक्तिगत रूप से मुझे इसे HTML में handle करना बेहतर लगता है, क्योंकि इससे JS बंद रखने वाले users भी support हो जाते हैं
  https://phuoc.ng/collection/html-dom/change-the-favicon-dyna...

  • HTML में handle करने से दूसरे theme content के थोड़ी देर flash होने की समस्या भी रोकी जा सकती है। यही तरीका theme-color meta पर भी apply किया जा सकता है, जो details पर ध्यान देने वाले PWA developers के लिए कम इस्तेमाल होने वाला लेकिन शानदार feature है

• “textarea auto-expand” तकनीक नए CSS property form-sizing की वजह से पुरानी पड़ती जा रही है
  https://chriscoyier.net/2023/09/29/css-solves-auto-expanding...
  इस नए CSS property का इस्तेमाल न भी करें, तो भी element की height को adjust करने वाला तरीका ideal नहीं है और अटक सकता है
  बेहतर तरीका hidden mirror element का इस्तेमाल करना है
  https://css-tricks.com/the-cleanest-trick-for-autogrowing-te...

• यहां दी गई चीज़ों में से काफ़ी कई, बेहतर native API मौजूद होने के बावजूद पुराने और awkward API इस्तेमाल कर रही हैं
  मसलन “element replace” में ele.parentNode.replaceChild(newEle, ele); दिया है, लेकिन अगर आप Chrome 54 से नीचे, Firefox 49 से नीचे, Safari 10 से नीचे को target नहीं कर रहे हैं, तो बस ele.replaceWith(newEle) इस्तेमाल करें
  replaceWith किसी एक node को कई nodes या text से बदलना भी संभव बनाता है
  इसी तरह “NodeList iteration” में array spread के बाद forEach इस्तेमाल करने को कहा गया है, लेकिन बस for (let ele of nodelist) ... काफी है

  • यह याद रखना चाहिए कि NodeList live object हो सकता है। iteration के दौरान उस list को modify करने पर अनपेक्षित नतीजे आ सकते हैं

• अच्छा है। bookmark कर लिया। इसी तरह का एक अच्छा resource https://youmightnotneedjquery.com/ भी है
  मैं web work अक्सर नहीं करता, लेकिन जब भी करता हूं, वहां का framework overload पूरी तरह demotivate कर देता है। नया React project सैकड़ों dependencies के साथ शुरू होता है—यह control से बाहर है, और उस complexity का बोझ हैरान करने वाला है
  दूसरी तरफ built-in cross-platform browser technologies पहले से कहीं ज्यादा powerful हैं, और common tasks करने के लिए code की मात्रा भी इतनी ज्यादा नहीं होती
  frontend developers, सब ठीक है?

  • मुझे React या npm बिल्कुल पसंद नहीं हैं, लेकिन कुछ frameworks ऐसी useful चीज़ें देते हैं जो pure DOM API नहीं देता, इसलिए मुझे लगता है उनकी अभी भी जगह है
    उदाहरण के लिए application state management और routing ऐसी बड़ी चीज़ें हैं जिन्हें pure DOM API से खुद implement करना पड़ेगा
    app की complexity के हिसाब से यह बड़ी बात न भी हो, लेकिन basic app से आगे जाते ही इन extra features की value तेजी से बढ़ती है। हालांकि अगर आप ऐसा कुछ इस्तेमाल कर रहे हैं जिसके लिए NPM चाहिए, तो सिरदर्द शुरू हो जाता है
  • इसी तरह का एक और बेहतरीन resource शानदार https://javascript.info/ है
    basic platform और उसकी capabilities को पसंद करने वाले frontend developer के तौर पर, nested CSS, container queries, और ES6 के बाद overall बेहतर हुए JS experience जैसी अच्छी चीज़ें आते देखना अच्छा लगता है
    साथ ही यह देखकर हैरानी भी होती है कि button या bold text जैसी छोटी-छोटी चीज़ों के लिए भी बहुत लोग component इस्तेमाल करते हैं
    frameworks खुद मुझे पसंद हैं, लेकिन कई frameworks और libraries की marketing इस भरोसे पर टिकी है कि CSS और pure DOM manipulation पागलपन की हद तक मुश्किल हैं, और NPM से कोई भी package खींच लाना न सिर्फ तेज़ और आसान है बल्कि professional काम भी है
  • इस बात से सहमत हूं कि यह control से बाहर है। लेकिन पिछले 1 साल में platform team में जाने के बाद पहली बार DevOps tools से काम करना शुरू किया, और उसकी complexity भी frontend से कम नहीं है
    सिर्फ Kubernetes, Helm, Terraform, CircleCI जैसी चीज़ों को ही देखें, तो परत-दर-परत जमा terminology की मात्रा बेतुकी है
  • जानना चाहूंगा कि क्या आपने “powerful cross-platform technologies” से कोई non-trivial काम किया है। और React ही इकलौता विकल्प नहीं है

• जब पता चला कि कई DOM functions अपने-आप update होने वाली live HTMLCollection लौटाते हैं, तो मैं सचमुच हैरान रह गया
  framework craze से पहले, या फिर framework के बिना development की ओर थोड़ा रुझान दोबारा popular होने के आसपास, यह feature actual production code में कितना actively इस्तेमाल हुआ होगा—यह जानने की उत्सुकता है

• पुरानी चीज़ फिर नई बन जाती है। मेरी पहली frontend role 1999 में web application बनाने की थी
  treeview drag-and-drop, click-to-edit, और practically single-page app जैसी cool features तक सब कुछ “Vanilla” JS में बनाया था
  सबसे मुश्किल हिस्सा Netscape और Internet Explorer के differences को reconcile करना था

  • curious हूं कि state और उसके changes को कैसे manage किया था
    क्यों अब ऐसा लगता है कि हमें वह करना आता ही नहीं ;]

• इन दिनों मेरी पसंदीदा pure JavaScript feature Element.insertAdjacentHTML है, जो Chrome 1.0 और IE के दौर से मौजूद है
  खासकर backticks वाली multi-line strings के साथ यह कितना उपयोगी है, कहना भी कम पड़ेगा। यकीन नहीं होता कि यह इतने पहले से मौजूद था और मुझे करीब 1 साल पहले ही पता चला
  insertAdjacentHTML(position, text) दिए गए text को HTML या XML के रूप में parse करता है, और बने हुए nodes को DOM tree में दी गई position पर insert करता है
  मूल DOM से यह करने के लिए li element बनाना, a element बनाना, उसे child के रूप में जोड़ना, href attribute set करना, text value डालना और फिर ul में insert करना पड़ता था। या फिर बड़ी string बनाकर innerHTML में डालना पड़ता था, और existing list को modify करना और भी painful और verbose था

  1. https://developer.mozilla.org/en-US/docs/Web/API/Element/ins...