DOM टेम्पलेट API को अपनाने का यही सही समय है

 (justinfagnani.com)
1 पॉइंट द्वारा GN⁺ 2025-06-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • वेब प्लेटफ़ॉर्म में इस समय वह declarative template API नहीं है जिसकी डेवलपर्स को सचमुच ज़रूरत है
  • ज़्यादातर आधुनिक वेब frameworks में templating एक मुख्य तकनीक है, लेकिन standard DOM API में templates को सुरक्षित और दक्ष तरीके से बनाने व अपडेट करने का तरीका नहीं है
  • इसके कारण यूज़र्स, डेवलपर्स, frameworks, और यहाँ तक कि platform स्तर पर भी असुविधा और performance गिरावट की समस्याएँ पैदा होती हैं
  • template API को लाने का समय आ गया है, क्योंकि हाल के framework अनुभव और JavaScript capabilities अब इतने परिपक्व हो चुके हैं कि implementation और standardization अधिक व्यावहारिक हो गए हैं
  • template identity, signal-based reactivity जैसे विभिन्न मॉडलों को समेटते हुए, अगली पीढ़ी के template API की दिशा सुझाई गई है

प्रस्ताव का सार

  • यह लेख वेब प्लेटफ़ॉर्म में declarative template API जोड़ने के प्रस्ताव की पृष्ठभूमि और आवश्यकता समझाता है
  • DOM API शक्तिशाली है, लेकिन standard DOM में data के आधार पर कई nodes को सुरक्षित और दक्ष तरीके से बनाने व अपडेट करने के लिए template API मौजूद नहीं है
  • React, Vue, Angular जैसे प्रमुख frameworks में declarative templating मुख्य तत्व है, और यह developer productivity, security, performance, static analysis, server-side rendering जैसी कई खूबियाँ देता है
  • template API की अनुपस्थिति के कारण यूज़र्स, डेवलपर्स, frameworks, और platform सभी को अनावश्यक जटिलता, security risk, performance degradation, और adoption barrier जैसी समस्याओं का सामना करना पड़ता है
  • लेख का तर्क है कि अभी API लाने का सही समय है, और मौजूदा framework अनुभव तथा आधुनिक JavaScript features का उपयोग करते हुए क्रमिक standardization का प्रस्ताव रखा गया है

templates की ज़रूरत और मौजूदा समस्या

  • DOM API वेब प्लेटफ़ॉर्म की dynamic capabilities की आधारशिला है
  • लेकिन standard DOM में data से DOM tree को सुरक्षित रूप से define करने और उसे दक्षता से अपडेट करने के लिए declarative template का तरीका नहीं है
  • आधुनिक वेब frameworks (React, Vue, Angular, Svelte आदि) सभी declarative templating प्रदान करते हैं
  • declarative templating लोकप्रिय होने के कारण:
    • imperative API की तुलना में बेहतर usability और readability
    • XSS security मज़बूत होती है; template के अंदर data अपने-आप escape हो जाता है
    • तेज़ और दक्ष rendering performance
    • static analysis, type-checking, IntelliSense जैसी developer productivity में वृद्धि
    • server-side rendering का समर्थन

मौजूदा स्थिति की समस्याएँ

  • यूज़र्स: library download और rendering delay के कारण initial loading धीमी हो जाती है; client code size बढ़ने से UX खराब होता है
  • डेवलपर्स: templates इस्तेमाल करने के लिए अलग library (npm, CDN आदि) चाहिए; इससे adoption barrier और non-standard loading जैसी समस्याएँ आती हैं
  • frameworks: template engine खुद implement करनी पड़ती है; performance, features और code size के बीच भारी trade-off रहता है
  • platform: native apps के मुकाबले प्रतिस्पर्धा में नुकसान; Flutter, SwiftUI आदि built-in template system देते हैं

अभी सही समय क्यों है

  • पहले के template-संबंधी प्रयास (E4X, E4H, html template literal आदि) असफल रहे, लेकिन उस समय DOM updates उनकी कमज़ोरी थी
  • हाल के frameworks और community में template API best practices पर्याप्त रूप से इकट्ठी हो चुकी हैं
  • JavaScript-based API का प्रस्ताव अब संभव है; मौजूदा standard JS में tagged template literals पहले से मौजूद हैं
  • vanilla JS developers और web components community में भी सुविधाजनक DOM manipulation की माँग लगातार बढ़ रही है
  • DOM Parts जैसे low-level primitive proposals साथ-साथ चल रहे हैं, लेकिन high-level declarative API कहीं अधिक उपयोगी और भविष्यदर्शी दिशा दे सकता है

अच्छे template syntax के उदाहरणों का विश्लेषण

  • मुख्यधारा के template systems (React-JSX, Vue, Svelte, Angular आदि) अंततः बहुत मिलते-जुलते markup + binding syntax पर आधारित हैं
  • JS API आधारित templates में आम संरचना यह होती है कि template expression, DOM description लौटाता है, और अलग render function उसे असली DOM में लागू करता है
  • E4X जैसे पुराने प्रयास DOM itself लौटाते थे, इसलिए उनका update model कमज़ोर था

JavaScript-आधारित template API की संभावना

  • tagged template literals के ज़रिए, बिना नए JS features लाए भी template API डिज़ाइन किया जा सकता है
  • JSX-to-Lit जैसे कई practical proof पहले से मौजूद हैं

JSX integration पर चर्चा

  • JSX को standardize करना जटिल semantic definition और runtime semantics की माँग करता है; JSX अपने-आप में सिर्फ syntax है
  • मौजूदा non-standard JSX शुद्ध syntax transform है, इसलिए भविष्य में standard template API आने पर उसे JSX->template literal transform compiler से जोड़ा जा सकता है
  • आगे चलकर यदि असली JSX standardization होती है, तो template API के अनुरूप data types स्वीकार करने वाली संरचना में जाना आसान होगा

HTML-आधारित template API से संबंध

  • कई डेवलपर्स और communities HTML template system की माँग करते हैं
  • लेकिन HTML-based system में binding, expression language, control statements आदि के लिए नई syntax और expressions डिज़ाइन करनी पड़ेंगी, इसलिए यह कहीं बड़ा काम है
  • हाल के frameworks (Lit आदि) के HTML templates से JS API की ओर जाने के पीछे भी यही कारण है
  • इसलिए JS-based template API को पहले लाना और बाद में HTML API तक चरणबद्ध विस्तार करना अधिक संभावित है

reactivity implementation अनुभव की परिपक्वता

  • VDOM diffing (React), template identity (Lit), signals (fine-grained signals, Solid/Svelte/Vue आदि) जैसे विभिन्न reactivity models अब अच्छी तरह परखे जा चुके हैं
  • VDOM-आधारित तरीका धीमा है, जबकि template identity + signal model का संयोजन तेज़, दक्ष और अधिक समझने योग्य है
  • signal-based model में हर data को signal में wrap करना पड़ सकता है, लेकिन सामान्य data के साथ मिश्रित उपयोग भी संभव है

विकास-पथ और अपेक्षित प्रभाव

  • प्रस्तावित declarative JS template API vanilla JS, web components, और नए frameworks सभी को सीधे लाभ देगा
  • मौजूदा frameworks में भी इसे compile target, runtime backend, या direct support API के रूप में इस्तेमाल किया जा सकता है
  • यह "re-rendering" तरीके और signal-based reactivity, दोनों को support कर सकता है
  • आगे HTML-based declarative templates और declarative custom elements तक विस्तार की नींव रखी जा सकती है
    • API का दायरा सीमित और स्पष्ट है, और मौजूदा APIs (जैसे DOM Parts) के साथ integration भी आसान है
  • हालाँकि ऊपर से API और syntax सरल दिखते हैं, लेकिन नीचे DOM Parts और scheduler जैसी implementation surface काफ़ी बड़ी है, और standardization, testing जैसी collaborative मेहनत की ज़रूरत होगी

निष्कर्ष

  • लेखक इस प्रस्ताव पर GitHub issue में चर्चा कर रहे हैं और platform engineers सहित community से भागीदारी की अपील कर रहे हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-06-28
Hacker News की राय

  • "हम अच्छी template syntax को जानते हैं" जैसी बात सुनकर हँसी इसलिए आती है, क्योंकि वास्तव में उस मानक पर कभी ठीक से सहमति बनी ही नहीं। मेरा मानना है कि templates में symbolic नज़रिए से ज़्यादा visual अनुभव महत्वपूर्ण है। पुराने Dreamweaver जैसे tools इतने सफल भी इसी वजह से थे। कई designers का Photoshop जैसे tools से सीखना शुरू करना भी इसी संदर्भ में समझा जा सकता है। अफ़सोस यह है कि यह कोशिश फिर से XSLT बनाने जैसी लगती है। templating की असली समस्या यह है कि ठीक से न बने हुए structures को अच्छी तरह बने output में कैसे जोड़ा जाए। इससे आगे, 'label' और 'for' जैसी entities को व्यक्त करने की समस्या भी है, जो जुड़ी हुई तो हैं, लेकिन एक ही tree का हिस्सा नहीं हैं। अगर मेरे पास जादू करने की शक्ति होती, तो मैं यही चाहता कि सब कुछ standard document layout में अजीब ढंग से फिट करने की ज़िद न की जाए। absolute positioning का सही इस्तेमाल करके कई UI समस्याएँ काफ़ी कुशलता से हल की जा सकती हैं, तो फिर बार-बार हर गणितीय calculation भी मशीन पर ज़बरदस्ती क्यों डाली जाती है, यह समझ नहीं आता

    • XSLT को फिर से बनाने वाली बात से सहमत हूँ। XML मुझे ख़ास पसंद नहीं था, लेकिन XSLT वाकई बहुत शक्तिशाली था। यह आज भी browsers में काफ़ी व्यापक रूप से supported है। XML में Configuration या IPC जैसी चीज़ों में कमियाँ थीं, लेकिन एक बेहतरीन markup language के साथ XSLT की transformation power जुड़ने वाले हिस्से का उल्टा ठीक से इस्तेमाल ही नहीं हो पाया, यह अफ़सोस की बात है। XSLT लोकप्रिय नहीं हो पाया क्योंकि वह सचमुच declarative और functional DSL था। बहुत लोग DSL की तारीफ़ करते हैं, लेकिन व्यवहार में वह अक्सर किसी लोकप्रिय भाषा के procedural semantics पर एक पतली परत भर होता है। एक अच्छे DSL से जटिल काम सरल किए जा सकते हैं, लेकिन लोगों में उसे सीखने की कोशिश कम दिखती है

    • आप कहते हैं कि सही template syntax में visuality मुख्य चीज़ है, तो मैं जानना चाहूँगा कि आप इस निष्कर्ष तक कैसे पहुँचे। मुझे तो यह HTML+CSS, यानी generation के तरीके, से असंतोष जैसा लगता है। आपने absolute positioning का ज़िक्र क्यों किया, यह भी जानना चाहूँगा। absolute positioning अपनी जगह पर उपयोगी है, लेकिन पूरे layout के लिए इस्तेमाल करने पर उसे संभालना मुश्किल हो जाता है और screen size या content की मात्रा के हिसाब से वह आसानी से टूट सकता है। newspaper layout भी वास्तव में text और typography की बारीकियों से भरा होता है, इसलिए उसे सिर्फ absolute positioning से हल नहीं किया जा सकता। CSS के साथ गहराई से काम करते हुए मैंने कई बार देखा है कि absolute positioning से शुरू हुए layout को बाद में flex या flow में बदल देना ज़्यादा तेज़ और आसान समाधान साबित हुआ। calc() और viewport units का अच्छा उपयोग किया जाए तो कुछ अर्थ निकल सकता है, लेकिन जब तक content या viewport पूरी तरह fixed न हो, absolute positioning उपयुक्त नहीं है

    • मैंने यह बात देखी है कि लोग जिन चीज़ों को absolute positioning से आसानी और तेज़ी से बना सकते हैं, उन्हें बहुत घुमा-फिराकर अंत में वही असर पैदा करने की कोशिश करते हैं। लेकिन web में यह शर्त होती है कि document हर device size, orientation और performance पर अच्छा दिखना चाहिए। सामान्य apps (जैसे Windows apps) को यह समस्या नहीं होती, और mobile apps को भी अक्सर सिर्फ standardized screen sizes का ही ध्यान रखना होता है। सिर्फ web में ही यह सब संभालना पड़ता है

    • "अच्छी template syntax" पर तंज़ कसना, मेरी नज़र में, प्रगति की बात करने वालों के प्रति बहुत शिष्ट रवैया नहीं है। और मुझे लगता है कि आज अच्छी template syntax मौजूद है, उसका प्रमुख उदाहरण jsx है। मैं React का fan नहीं हूँ, लेकिन मेरा मानना है कि jsx ने web development में क्रांति ला दी, और ज़्यादातर js template systems लगभग इसी दिशा में converge हो गए हैं: "expression के रूप में template", "nesting के ज़रिए composition", और control flow को JavaScript से संभालना

    • React और Svelte ऊपर-ऊपर ही मिलते-जुलते दिखते हैं; असल में उनका काम करने का तरीका काफ़ी अलग है। React का मूल विचार यह है कि (लगभग) साधारण JavaScript functions JSX रूप में lazy markup लौटाते हैं। loops या conditional rendering के लिए template की अपनी अलग syntax नहीं होती; सब कुछ सामान्य JavaScript से संभाला जाता है, यही बड़ा अंतर है

  • मैं बार-बार यह सीखता हूँ कि API और ABI (application binary interface) कभी भी अंतिम नहीं होते। apps की ज़रूरतें स्थिर नहीं रहतीं, वे समय के साथ बदलती रहती हैं, इसलिए ऐसा कोई परिपूर्ण API नहीं हो सकता जो हमेशा के लिए चले। यह प्रस्ताव उसका अच्छा उदाहरण है। पहले समस्या को user libraries (जैसे React) हल करती हैं, फिर अंततः वही चीज़ standard तक उतरती है। Polyfill भी अक्सर इसी पैटर्न का हिस्सा होते हैं। अगर ऐसे proposals सफल भी हो जाएँ, तब भी वे अंत में legacy technology बन जाते हैं, और लोग उन्हें bypass करने के लिए नए तरीके बना लेते हैं। DOM API, ECMA, पुराने browsers—सबका भाग्य यही है। इससे यह सोचने का मन करता है कि क्या technical entropy, extensibility और backward compatibility को ही standard use case के रूप में देखना चाहिए

    • web standards में नए features जोड़ने का मतलब अंततः maintenance के लिए भारी code burden है, और standards को follow करने वाले browser बनाते समय implement करने वाला code भी लगातार बढ़ता जाता है। Servo जैसे projects जब थोड़ा भी catch up करने की कोशिश करते हैं, तब भी उन्हें हमेशा सिर्फ expansions का पीछा ही करना पड़ता है। मैं चाहता हूँ कि web platform में native environment की हर वह क्षमता हो सके जो privacy और sandbox की सीमाओं के भीतर संभव है। मैं यह भी चाहता हूँ कि developers का experience बेहतर हो। लेकिन इस सपने को पूरा करने के लिए complexity बढ़ने की कीमत पर भी विचार करना होगा। अभी जो native templating की चर्चा चल रही है, उससे सच में developer experience कितना बेहतर होगा, इस पर मुझे संदेह है

    • अगर backward compatibility बनाए रखी जाए और interface बदला न जाए, तो क्या versioning उसी काम के लिए नहीं होती—यह सवाल है

    • यह कहा जा रहा है कि पुरानी चीज़ें अंत में workaround या patch की ओर ले जाती हैं, लेकिन इस प्रक्रिया का एक सकारात्मक असर यह भी है कि underlying capabilities एक स्तर ऊपर उठ जाती हैं। incremental updates तब भी काफ़ी मूल्यवान हैं, चाहे user demands लगातार नई gaps और use cases सामने लाती रहें

    • मैं इस बात से सहमत नहीं हूँ कि "API और ABI कभी स्थायी रूप से stable नहीं होते"। उदाहरण के लिए getElementById 25 साल से ज़्यादा समय से स्थिर बना हुआ है। यह कहना कि अपरिवर्तनीय API असंभव हैं, मुझे एक तरह का निजी निराशावाद लगता है, जबकि दुनिया में इसके बहुत से अपवाद हैं। माँग तो असीमित है, इसलिए नए API जोड़िए; जो API काम कर रहे हैं उन्हें तोड़ने की कोई ज़रूरत नहीं है

    • web पर एक बार public हुआ API अगर जारी हो जाए, तो कोई न कोई उपयोगकर्ता जीवन भर उसके उसी exact shape पर निर्भर रहेगा। इसलिए 20 साल पहले लिए गए फ़ैसलों की गूँज आज तक बनी रहती है। इसे "smooshgate" जैसे मामलों में देखा जा सकता है

  • reactive programming के चलन का ज़िक्र करते हुए कहा गया कि user-level systems ने इस क्षेत्र को काफ़ी हद तक explore कर लिया है, और अब अलग-अलग approaches की खूबियों को जोड़कर एक असली standard system बनाया जा सकता है। लेकिन Ryan Carniato/Solid JS जैसे लोग अभी भी signals का उपयोग करके नई संभावनाएँ खोज रहे हैं, इसलिए मुझे नहीं लगता कि यह exploration अभी समाप्त हुई है। आगे बढ़ने की काफ़ी गुंजाइश है

  • web को native templating, reactivity और data binding की सच में ज़रूरत है। दुनिया भर के अरबों users द्वारा React जैसे भारी frameworks को download, parse और execute करने में जितना CPU और bandwidth बर्बाद होता है, वह कल्पना से परे है

    • LLM और cryptographic computation में होने वाली भारी resource waste के सामने यह बर्बादी छोटी लगने लगती है

    • TC39 में signals से जुड़ा proposal आ रहा है, और उसकी वजह से हम एक कदम आगे बढ़ रहे हैं

    • वास्तविक development के लिए तो two-way data binding और jsx clone जैसा कुछ ही काफ़ी होगा

    • React कोई templating system नहीं है

  • web standards में high-level templating system लाने की चर्चा को देखते हुए, मुझे लगता है कि पहले browser-built-in low-level API दिए जाने चाहिए। किसी standard templating system पर सबकी सहमति बनना लगभग असंभव है। लेकिन browser अगर DOM पर diff apply करने के लिए low-level API दे दे, तो वह काफ़ी उपयोगी होगा। उदाहरण के लिए, यह method native रूप में हो तो अच्छा होगा: element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' })। इस तरह diff apply करने से current element का focus, input value, audio/video state आदि को बचाए रखते हुए non-destructive updates किए जा सकते हैं। Idiomorph जैसी js libraries मौजूद हैं, लेकिन native solution के बहुत तेज़ होने की संभावना है

    • लेख में DOM parts proposal का link है। यह प्रस्ताव low-level API के रूप में काफ़ी उपयोगी है। VDOM-आधारित frameworks के लिए यह शायद बहुत उपयुक्त न हो, लेकिन बाकी frameworks में implementation सरल हो सकती है और optimization की गुंजाइश भी बढ़ती है। अगर signals proposal भी साथ आ जाए, तो frameworks के बिना भी इसकी उपयोगिता काफ़ी बढ़ जाएगी

  • इस लेख के लेखक को इस क्षेत्र के सबसे अनुभवी लोगों में से एक बताया गया है। उन्होंने Lit, Polymer, Google के web components, और कई प्रमुख DOM specs में बड़ा योगदान दिया है

    • लेकिन यह आलोचना भी है कि उन्होंने जिन कई specs को आगे बढ़ाया, उन्होंने समस्याएँ ज़्यादा पैदा कीं। पूरी तरह निखरे बिना सतही समाधान देने के लिए 20 से ज़्यादा web specs की ज़रूरत बना दी गई, और जो चीज़ें पहले से userland में संभव थीं, उन्हें बहुत जटिल तरीके से standardize किया गया—ऐसी राय भी है। साथ ही यह भी कहा गया कि 15 साल पहले से Safari declarative approach की ज़रूरत पर ज़ोर देता रहा, लेकिन उसे नज़रअंदाज़ किया गया

  • JSX शैली के बजाय, मैं ऐसी syntax approach चाहता हूँ जैसी Kotlin ने receiver और builder का उपयोग करके DSL को generalize करने में दिखाई है। यह तरीका सिर्फ साधारण HTML templates तक सीमित नहीं रहेगा, बल्कि अलग-अलग component hierarchies, config, और कई तरह की स्थितियों में बहुत उपयोगी हो सकता है। templating और data binding का वास्तविक अर्थ अंततः ऐसे syntactic features का उपयोग करने वाले standard functions के set से ही है, और यह Jetpack Compose से मिलता-जुलता है

    • वास्तव में ज़रूरी features बहुत कम हैं: loop, attribute conditional, node conditional वगैरह। सच कहें तो ऐसी संरचनाएँ हों, तो उन्हें languages के पार भी इस्तेमाल किया जा सकता है

  • मुझे हमेशा यक़ीन नहीं होता कि declarative templating, jQuery से बेहतर ही है। मैं लगभग 10 साल से React का इस्तेमाल कर रहा हूँ, लेकिन जैसे-जैसे मेरी SPA जटिल होती जाती है, मुझे DOM का imperative control ज़्यादा याद आने लगता है। DOM abstraction leak होने लगती है, और अंत में साधारण "last-write-wins" जैसे patterns ही ज़्यादा स्पष्ट लगते हैं। कहा जाता है कि declarative templates इन समस्याओं का समाधान करते हैं, लेकिन जैसे ही components के बीच mutable state साझा करना शुरू होता है, उनकी सीमाएँ बहुत जल्दी सामने आ जाती हैं

    • यह एहसास कुछ हद तक React ecosystem के developers द्वारा DOM API को सीधे call करने को पाप जैसा मानने से भी पैदा होता है। ref का सक्रिय रूप से इस्तेमाल करना, या id से component को सीधे ढूँढ़कर manipulate करना भी ठीक है। वास्तव में तेज़ और कम rerender वाले form libraries वगैरह अक्सर ऐसे ही काम करते हैं

    • मुझे React पसंद नहीं है, लेकिन मेरा मानना है कि declarative DOM से बाहर जाकर innerHTML, ref वगैरह इस्तेमाल करने में कोई बाधा नहीं है। imperative control से चीज़ें संभव हैं, लेकिन व्यावहारिक रूप से ऐसा बहुत कम है जो declarative तरीके से न किया जा सके। attachShadow() या showModal() जैसी चीज़ें भी लगभग 10 lines जोड़कर आसानी से declarative रूप में wrap की जा सकती हैं

  • अगर Records और Tuples proposal आगे बढ़ गया होता, तो JSX उन structures का उपयोग करके नई semantics ले सकता था, लेकिन वास्तव में वह proposal सिर्फ रुका नहीं बल्कि पूरी तरह वापस ले लिया गया (issue देखें)। उसकी जगह composites proposal आया है

  • मुझे लगता है कि ऐसे high-level features को standardize करने की चर्चा रोक देनी चाहिए। इसके बजाय lower-level characteristics को विस्तार देना चाहिए, ताकि upper-layer libraries के implementation के लिए ज़्यादा मूल्य पैदा हो। अगर किसी standard proposal का libraries की तुलना में स्पष्ट लाभ नहीं है, तो उसका कोई अर्थ नहीं। मेरी राय में, किसी चीज़ को standardize करने की चर्चा तभी शुरू होनी चाहिए जब वह कम से कम 5–10 साल तक library के रूप में व्यापक रूप से परखी जा चुकी हो