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

 (justinfagnani.com)
1 पॉइंट द्वारा GN⁺ 2025-06-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • वेब प्लेटफॉर्म डायनेमिक application runtime के रूप में स्थापित हो चुका है, लेकिन standard DOM में ऐसा declarative template API नहीं है जो data, events, properties, XSS defense और efficient updates को एक साथ संभाले
  • React, Vue, Angular, Lit, Svelte, SolidJS जैसे modern frameworks markup और data को जोड़ने वाले template system को core मानते हैं, और यह readability, security, performance, static analysis और server-side rendering को प्रभावित करता है
  • पुराने E4X, E4H और built-in html template literal tag DOM creation में मददगार थे, लेकिन DOM updates की समस्या हल नहीं कर पाए; अब tagged template literals और framework experience standardization की बुनियाद देते हैं
  • JavaScript-based API का scope JSX standardization या HTML-based templates से छोटा है, और यह JSX transforms का compile target बनकर आगे HTML templates और declarative custom elements तक ले जा सकता है
  • प्रस्तावित रास्ता DOM Parts, template identity, Signals, DOM scheduler जैसे lower-level mechanisms से जुड़ता है और vanilla developers, web component users और framework implementers को shared foundation दे सकता है

Standard DOM में missing declarative template layer

  • वेब प्लेटफॉर्म इतिहास का सबसे सफल application runtime है, और DOM API static document viewer को dynamic और expressive runtime में बदलने की बुनियाद है
  • Photoshop जैसे complex apps भी web app के रूप में उपलब्ध हैं, और पूरा UI Web Components से बनाया जा सकता है—इतना powerful API है DOM
  • हालांकि मौजूदा standard DOM API में नीचे दिए गए कामों को एक साथ संभालने का सुविधाजनक तरीका नहीं है
    • data से DOM node fragments बनाना
    • event listeners जोड़ना
    • element properties सेट करना
    • XSS attacks से safety सुनिश्चित करना
    • नए data के साथ उस DOM fragment को efficiently update करना

Frameworks ने templates की value पहले ही साबित कर दी है

  • Modern web frameworks और rendering libraries markup और data को declaratively combine करने वाले templates को core feature की तरह इस्तेमाल करते हैं
    • React, Vue, Angular, Preact, Lit, Svelte, SolidJS, Stencil, Quik, Ember, FAST, Polymer, Marko आदि शामिल हैं
  • Declarative templates, imperative DOM API की तुलना में लिखने और पढ़ने में बेहतर होते हैं
    • interpolation, event listeners और property settings template के पास ही होते हैं, इसलिए locality of behavior बनाए रखना आसान होता है
  • Template systems interpolation values को automatically escape कर सकते हैं, इसलिए XSS defense में लाभ मिलता है
  • अच्छा template system केवल उसी DOM को update करता है जिसमें बदलाव चाहिए, इसलिए यह ज्यादातर hand-written code से तेज हो सकता है
  • कई template systems type checking और autocomplete जैसी static analysis को support करते हैं
  • Declarative template definitions को पूरे browser environment के बाहर भी interpret किया जा सकता है, जिससे efficient server-side rendering संभव होती है

Template की कमी से बनने वाली लागत

  • Platform अभी भी लगभग सभी web applications की core requirement को सीधे पूरा नहीं करता
    • internationalization APIs, Temporal, Scheduler, Sanitizer की तरह templates को भी standard platform feature माना जा सकता है
  • users पर app download time, rendering overhead और कमजोर security वाले apps का असर पड़ता है
    • template library code सबसे अच्छे case में कुछ kB और सबसे खराब case में 100kB से अधिक हो सकता है
    • कुछ kB भी initial interactive rendering budget में बड़ा हिस्सा हो सकते हैं
  • developers को basic कामों के लिए भी libraries, npm और CDN पर depend करना पड़ता है
    • simple static files और DevTools की usefulness घटती है
    • अलग-अलग stacks में portable basic template knowledge नहीं होता
    • innerHTML जैसे native DOM creation APIs default रूप से safe नहीं हैं
  • Frameworks और template libraries को authoring experience, rendering speed, update speed, security और code size के बीच कठिन trade-offs करने पड़ते हैं
  • Web platform Flutter, SwiftUI, Jetpack Compose जैसे native platforms से compete करता है
    • ये platforms template-जैसे systems built-in रखते हैं, app installation और compiled languages का उपयोग करते हैं, और कुछ kB bundle size के प्रति कम sensitive होते हैं

अभी फिर से कोशिश क्यों की जा सकती है

  • अतीत में भी templates के करीब platform proposals आए थे
    • E4X वास्तव में Firefox और Flash में शामिल था
    • E4H Ian Hixie द्वारा simplify किया गया idea था
    • 2012 के आसपास built-in html template literal tag prototype भी था
  • पुराने प्रयास DOM creation में मददगार थे, लेकिन updates हल नहीं कर पाए, इसलिए वे पर्याप्त solution बनना मुश्किल था
  • अब frameworks ने पर्याप्त use cases बना दिए हैं, और userland template solutions समय के साथ और ज्यादा मिलते-जुलते हो रहे हैं
  • Frameworks न इस्तेमाल करने वाले developers और web components community में भी convenient DOM manipulation और reactivity APIs की demand है
  • DOM Parts जैसे low-level DOM update primitives के proposals चल रहे हैं
    • Higher-level declarative template API framework implementation burden घटा सकता है और low-level API proposals को validate और complement कर सकता है

Syntax और semantics का common denominator

  • Popular client-side template systems ज्यादातर markup और bindings को जोड़ने वाली structure share करते हैं
    • expression delimiters, control flow और binding type indicators थोड़े-थोड़े अलग हैं, लेकिन commonalities ज्यादा हैं
    • HTML-based Vue, Angular, Svelte और JavaScript-based React, Lit, Solid के बीच भी similarities हैं
  • JavaScript-based APIs में template आमतौर पर expression होता है, composition nested template expressions या references से होती है, और control flow JavaScript संभालता है
  • कई JavaScript API-based systems template expression से DOM description return करते हैं, फिर अलग render function call से apply करते हैं
    • ज्यादातर उसी render call से DOM update करते हैं
    • कुछ fine-grained reactivity से इस तरीके से बचते हैं
  • E4X और E4H ने JSX की तरह JavaScript में markup डालने वाली नई syntax जोड़ी, लेकिन DOM description नहीं बल्कि DOM fragment खुद return किया
    • initial DOM creation के लिए अच्छा था, लेकिन updates फिर भी imperative ही रहे

आज के JavaScript से express हो सकने वाला API

  • JavaScript में HTML जैसी embedded DSL के लिए tagged template literals पहले से मौजूद हैं
  • नया JavaScript syntax जोड़े बिना भी DOM API में templates express किए जा सकते हैं
  • Popular libraries दिखाती हैं कि यह approach अच्छे से काम करता है
  • बिना नई syntax के proposal आगे बढ़ा पाना standardization की practicality के लिए महत्वपूर्ण है

JSX और native template API का संबंध

  • tagged template literals ES2015 की powerful feature हैं, लेकिन userland component systems में JSX की तुलना में syntax overhead ज्यादा है
  • JSX लोकप्रिय है, लेकिन इसमें सिर्फ syntax है, runtime semantics नहीं
    • standardize करने के लिए सिर्फ नई syntax जोड़ने से आगे बढ़कर semantics define करनी होंगी
    • आसपास defined createElement() call की तरह treat करने वाला तरीका बाहर रखा जाता है
    • object tree बनाने वाला तरीका static और dynamic parts को मिला देता है, जिससे अधिक efficient update patterns रुक सकते हैं
  • अगर Records and Tuples proposal आगे बढ़ रहा होता, तो JSX boxed Records बना सकता था, लेकिन वह proposal खासकर record identity और box वाले हिस्से पर अटका हुआ है
  • JSX जैसी syntax और semantics पूरी DOM templating के लिए suitable हैं या नहीं, यह verify करने के लिए target template system चाहिए
    • React का template DOM elements की properties और events से explicitly bind करने या elements पर directives apply करने का तरीका नहीं देता
  • मौजूदा non-standard JSX runtime semantics के बिना pure syntax है, इसलिए JSX को tagged template literal में transform करने वाला compiler बनाया जा सकता है
    • JSX-to-Lit जैसे examples पहले से हैं
    • Native template API developers को अपनी पसंद की syntax चुनने देने वाला compile target बन सकता है

HTML-based templates से पहले JavaScript API को देखने की वजह

  • कई web developers fully featured HTML-based template system चाहते हैं
    • web component users, framework users और vanilla developer community में demand है
    • कुछ developers को उम्मीद थी कि <template> element, declarative shadow DOM और Web Components ऐसी functionality देंगे
  • HTML-based templates, JavaScript-based API की तुलना में कहीं बड़ा काम हैं
    • binding syntax
    • expression language
    • control flow syntax
    • template update mechanism
  • HTML-based template definitions को natively load करने का तरीका भी नहीं है
    • Web Components v0 के HTML Imports खत्म हो गए, और HTML Modules अभी नहीं हैं
    • अगर HTML templates को JavaScript module के अंदर रखना ही पड़े, तो data के same lexical scope में JavaScript expressions इस्तेमाल करना बेहतर माना जाता है
  • Polymer 3 ने Polymer 2 के HTML templates को JavaScript में shift किया, और यह सीधे Lit तक पहुंचा
    • JavaScript को script जैसे काम संभालने देना कम code वाला और बेहतर experience था
  • JavaScript API, HTML-based API का subset और stepping stone हो सकता है
    • JavaScript API आने और validate होने के बाद HTML API के लिए binding, expression, control flow और module system define करना बाकी रहेगा

Reactivity model के विकल्प

  • शुरुआती DOM template proposals में updates शामिल नहीं थे, लेकिन userland systems ने reactivity models और implementation approaches को काफी explore कर लिया है
  • प्रमुख reactivity approaches को तीन categories में रखा जा सकता है
    • React का VDOM और diffing
    • Lit की template identity
    • Solid, Svelte, Vue, Angular आदि में इस्तेमाल होने वाली Signals और fine-grained reactivity
  • diffing समझने में आसान है और किसी भी data पर काम करता है, लेकिन दूसरे approaches से slow है
    • diffing algorithm का अंतर observable हो सकता है
    • एक diffing algorithm standardize करना और platform engineers से overhead accept करवाना मुश्किल है
  • template identity का तरीका है: अगर DOM अभी current template से render हुआ है तो update करें, नहीं तो replace करें
    • तेज है और कई use cases में diffing जैसा ही result देता है
    • tagged template literals, JSX transforms और HTML-based templates के साथ अच्छी तरह fit बैठता है
    • semantics simple हैं, इसलिए specification लिखना आसान है
  • Signals नए reactive DOM API और template API में शामिल किए जाने लायक model हैं
    • JavaScript Signals proposal है, लेकिन यह अभी platform की native feature नहीं है और adoption guaranteed नहीं है
    • Signals-based systems तब सबसे अच्छा काम करते हैं जब सारे data को signal में wrap किया जाए
    • बहुत सा non-signal data और platform APIs भी हैं जो signals नहीं बनाते, इसलिए re-rendering ऐसे changes reflect करने का आसान तरीका है
  • template identity और Signals साथ रह सकते हैं
    • bindings में सिर्फ signal pass करने वाले templates बिना re-rendering के केवल signal से update हो सकते हैं
    • non-signal data reference कर सकने वाले templates को re-rendering चाहिए
    • आमतौर पर re-rendering reactive component properties जैसी component या framework layer अपने-आप करती है

Standardization discussion और बचे हुए काम

  • Native declarative JavaScript template API पर चर्चा WICG webcomponents#1069 में शुरू हुई
  • यह API DOM creation APIs का logical next step हो सकता है
    • vanilla web developers के लिए authoring-friendly और safe DOM creation primitive बनता है
    • Lit, FAST, HyperElement जैसी existing web component libraries के लिए तुरंत useful है
    • raw Web Components API users के लिए useful है और अधिक complete reactive component definition API की ओर stepping stone बनता है
    • नए frameworks इस API के आधार पर बनाए जा सकते हैं
    • existing frameworks इसे compile target, runtime backend या direct support target के रूप में इस्तेमाल कर सकते हैं
    • re-rendering techniques और Signals दोनों के लिए useful है
    • declarative HTML templates और declarative custom elements की ओर stepping stone बनता है
    • जिस API surface पर consensus और specification चाहिए, वह relatively छोटा है
    • template semantics define करने में मदद करता है
  • यह काम DOM Parts proposal के completion से जुड़ा है
    • DOM Parts को define करने और usefulness साबित करने में भी योगदान देता है
  • Surface API और syntax बड़े नहीं हैं, लेकिन behavior space और lower-level DOM Parts API बड़े हैं
  • fine-grained reactivity के लिए किसी न किसी तरह का DOM scheduler भी चाहिए
  • तय करने, सहमति बनाने, specify करने और test करने के लिए बहुत कुछ है, इसलिए collaboration जरूरी है
  • interested developers webcomponents#1069 पर comment छोड़ सकते हैं या Bluesky से contact कर सकते हैं

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

1 टिप्पणियां

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

  • “हमें पता है कि templates के लिए अच्छी syntax कैसी होती है” कहना हंसी लाने वाली बात है। मुझे लगता है कि हमें अभी बिल्कुल नहीं पता। अच्छे templates symbolic syntax से ज़्यादा लगभग निश्चित रूप से visual tools जैसे होंगे; पुराने Dreamweaver जैसे tools इसलिए सफल हुए थे और designers Photoshop जैसे tools से इसलिए सीखते हैं
    साथ ही यह XSLT को फिर से बनाने की कोशिश जैसा दिखता है, जो अफसोसजनक है। आखिरकार कोई न कोई ऐसे fragments को templatize करना चाहेगा जो अपने-आप में well-formed नहीं हैं, लेकिन मिलाने पर well-formed बन जाते हैं। यही बात page के अंदर आपस में जुड़े, लेकिन एक ही tree में न होने वाले entities पर भी लागू होती है। साधारण markup में label और for इसका आसान उदाहरण हैं
    अगर संभव हो, तो markup के standard document layout नाम के Rube Goldberg device में हर template को जबरन फिट करने की कोशिश कम होनी चाहिए। लोग ऐसी चीज़ को दोहराने के लिए हद से ज़्यादा जटिल रास्ते अपनाते हैं, जो absolute positioning को सावधानी से इस्तेमाल करने पर काफी अच्छी तरह हो जाती है। फिट करने के लिए calculation की ज़रूरत हो सकती है, लेकिन समझ नहीं आता कि उसी data पर machine को बार-बार वही calculation करने के लिए क्यों मजबूर किया जाए

    • मुझे XML कभी पसंद नहीं रहा, लेकिन XSLT उस ecosystem को बचा सकने वाला killer feature था और आज भी है। यह अभी भी browsers में व्यापक रूप से supported है
      XML configuration, inter-process communication जैसी अनुपयुक्त जगहों पर लोकप्रिय हुआ, लेकिन यह अफसोस की बात है कि markup language के रूप में, जहाँ वह XSLT जैसी शानदार transformation capability के साथ चमक सकता था, वहाँ वह फीका पड़ गया
      मुझे लगता है XSLT जहाँ टूटा, वह यह था कि वह सचमुच एक DSL था—वह भी declarative, pure, functional DSL। लोग DSL की बातों में बहुत तारीफ करते हैं, लेकिन व्यवहार में वे अक्सर लोकप्रिय host language की procedural semantics को abstract न कर पाने वाले साधारण syntax खेल भर रह जाते हैं। जब कोई अच्छी तरह design किया गया DSL मिलता है जो कठिन कामों को मामूली बना देता है, तो लोग उसे सीखना नहीं चाहते
    • समझ नहीं आता कि आप उस निष्कर्ष तक कैसे पहुँचे। आप जो कह रहे हैं वह template generation के तरीके के बजाय HTML+CSS कुल मिलाकर उससे असंतोष जैसा दिखता है
      और यह भी सवाल है कि absolute positioning यहाँ क्यों आ रही है। HN पर ऐसी बातें बार-बार दिखती हैं; बेशक absolute positioning की अपनी जगह है और कई मामलों में ज़रूरी भी होती है
      लेकिन page या app layout में इसका इस्तेमाल करने पर, मेरे अनुभव में अक्सर content या screen size थोड़ा भी बदलते ही यह टूट जाने वाला nightmare साबित हुआ है। print newspaper layout तक में typography जुड़ी होती है, इसलिए वहाँ भी ऐसा नहीं किया जा सकता
      जब मैं CSS पर ज्यादा काम करता था, अगर किसी ने absolute positioning से “लगभग पूरा” layout बना रखा हो और मुझे आगे काम संभालना पड़े, तो उसे ठीक करने में बहुत समय लगता था; flex या normal flow जैसे तरीकों से दोबारा बनाना हमेशा तेज़ होता था। absolute positioning को मुख्य layout tool के रूप में इस्तेमाल करने पर समस्या व्यावहारिक रूप से ठीक न की जा सकने वाली हो जाती थी
      calc() और viewport units से कुछ समझ में आने वाली techniques हो सकती हैं, लेकिन मेरे अनुभव में पूरी तरह static content और viewport size न हो तो absolute positioning layout के लिए उपयुक्त नहीं है
    • web में यह मांग होती है कि document किसी भी device size, ratio, orientation और capability पर अच्छा दिखे। सामान्य apps, जैसे Windows apps, में ऐसी मांग नहीं होती, और mobile apps में कुछ standardized sizes होते हैं। सिर्फ web में दोनों हैं
    • मुझे लगता है React और Svelte के बीच सिर्फ सतही समानता है। दोनों HTML पर काफी आधारित syntax इस्तेमाल करते हैं, लेकिन उनके काम करने के तरीके बहुत अलग हैं
      React मोटे तौर पर एकमात्र बड़ा framework है जो सामान्य JavaScript functions द्वारा JSX के रूप में markup का delayed representation return करने के तरीके से काम करता है। React में template-level looping या conditional rendering की अवधारणा नहीं है; वह सामान्य JavaScript से किया जाता है
    • web platform की प्रगति की वकालत करने वाले व्यक्ति के सामने हँसना बहुत अच्छा रवैया नहीं है। उस प्रगति से सभी को फायदा होता है
      और अब मुझे लगता है कि हमें पता है कि अच्छी template syntax क्या है। मूलतः वह JSX है। React को खास पसंद न करने के बावजूद मैं ऐसा कह सकता हूँ। JSX ने पूरे web में जगह बना ली है और कई frameworks के हिसाब से बदला गया है; और यह नकारना मुश्किल है कि JavaScript template systems कुछ साझा विशेषताओं पर converge हुए हैं: templates को expressions की तरह treat करना, nesting से compose करना, और किसी खास template syntax के बजाय JavaScript खुद से control flow संभालना

  • बार-बार सीखा गया बुनियादी सबक यह है कि API/ABI कोई अंतिम अवस्था नहीं है। applications की ज़रूरतें किसी एक stable API से हमेशा के लिए पूरी नहीं होतीं, और भविष्य की हर समस्या को app-level समस्या कहकर टाला भी नहीं जा सकता।
    यह प्रस्ताव अच्छी तरह दिखाता है कि platform की common problems पहले React जैसी higher layers में हल होती हैं, और फिर जब उन्हें सचमुच समस्या माना जाता है तो वे नीचे platform में उतरती हैं। polyfill भी इसी का उदाहरण हैं।
    ऐसे प्रस्ताव सफल होने पर कुछ समय तक ध्यान पाते हैं, लेकिन अपनी उपयोगी उम्र के अधिकांश हिस्से में वे ऐसे पुराने हिस्से बन जाते हैं जिनसे लोग बचने की कोशिश करते हैं। DOM API, ECMA versions, पुराने browsers, और system का हिस्सा होने के कारण छुए न जा सकने वाली हर उपयोगी technology के साथ यही हुआ।
    क्या हम entropy, extension, backward compatibility को मुख्य use cases मानकर सोच नहीं सकते?

    • web standards की हर capability अतिरिक्त code है जिसे सावधानी से maintain करना पड़ता है, और जिसे standards-compliant browser बनाने की कोशिश करने वाले हर किसी को implement भी करना पड़ता है। मैं चाहता हूं कि https://servo.org/ जैसे projects को समय के साथ बराबरी पकड़ने का मौका मिले, न कि वे लगातार बढ़ते scope के पीछे ही भागते रहें।
      मैं चाहता हूं कि web platform में native platforms की हर संभव capability हो। बेशक privacy protection और sandboxing constraints का पालन होना चाहिए। और web developers का development experience भी शानदार होना चाहिए।
      लेकिन इसे बढ़ती complexity के परिणामों के साथ संतुलित करना होगा। इस मामले में मुझे यकीन नहीं है कि native templates सच में development experience को बेहतर बनाते हैं। लाभ लागत से अधिक दिखता नहीं।
    • getElementById करीब 25 साल से stable नहीं रहा है क्या? “stable API जैसी कोई चीज़ नहीं होती” ऐसी बात वे लोग कहते हैं जो लंबे समय तक चलने वाले interfaces बनाने में सक्षम नहीं हैं या बनाना नहीं चाहते। यह ब्रह्मांड का नियम नहीं, बल्कि निजी हताशा जैसा है। इसके उलट उदाहरण बहुत हैं।
      application requirements बाकी requirements की तरह अनंत होती हैं। उन्हें काम कर रहे API को तोड़कर नहीं, बल्कि नए API जोड़कर पूरा किया जाता है।
    • web में API/ABI सच में अंतिम अवस्था होता है। एक बार web पर expose हो गया, तो कोई न कोई उसके ठीक उसी रूप पर हमेशा के लिए निर्भर हो जाएगा।
      इसलिए 20 साल पहले के फैसलों की वजह से आज भी smooshgate जैसी स्थितियों में फंसने वाले API हैं: https://developer.chrome.com/blog/smooshgate
    • उस प्रक्रिया में basic functionality एक और स्तर ऊपर चढ़ जाती है। सिर्फ इसलिए कि userland की मांगें हमेशा नए gaps, use cases और blind spots खोज लेंगी, incremental updates बेकार नहीं हो जाते।
    • इसलिए तो versions रखे जाते हैं, पुराने versions के साथ backward compatibility बनाए रखते हुए “पुराने” interfaces को बदला नहीं जाता, है ना?

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

    • अब LLM और cryptocurrency हैं, तो ऐसी बर्बादी बहुत छोटी लगती है।
    • TC39 Signals proposal से इसका कुछ हिस्सा आगे बढ़ रहा है।
    • two-way data binding और JSX की एक नकल भर असल में ज्यादातर लोगों के लिए पर्याप्त होगी।
    • React को template कहना मुश्किल नहीं है क्या?

  • Signals वाला हिस्सा बहुत कुछ बताता है, और अच्छी तरह दिखाता है कि idea शानदार है लेकिन व्यावहारिक रूप से कठिन है।
    लेखक Signals क्यों पसंद करता है, यह समझ आता है। हर पर्याप्त बड़े project में आधा-अधूरा DAG computation tree होता है, और language द्वारा किसी एक को standardize करना समझ में आता है।
    लेकिन ऐसी abstraction की cognitive cost और implementation cost बड़ी होती है।
    अधिकांश engineering की तरह समस्या trade-off की है। React model global state को update करता है और सब कुछ फिर से render करता है, इसलिए धीमा है लेकिन दिमाग के लिए आसान है। Signals model तेज है, लेकिन बहुत ज्यादा मेहनत मांगता है।
    ज्यादातर apps को पागलों जैसी तेज़ी की जरूरत नहीं होती, और लोग सरल React चुनेंगे।
    लेकिन Signals का templates से खास संबंध नहीं है, है ना। तो फिर इसे क्यों चुनना चाहिए। क्या templates और Signals अलग-अलग नहीं हो सकते?
    templates के बारे में सोचते हुए जरूरत पड़ती है कि DOM में template nodes कहां insert किए जाएं, और बदलाव होने पर उन्हें कैसे update किया जाए, यह बताने का कोई तरीका हो। ठीक इसी बिंदु पर ऐसे proposals fail हो जाते हैं।
    API को यहां एक पक्ष चुनना होगा। तकनीकी रूप से दोनों की अनुमति दी जा सकती है, लेकिन वह भयानक होगा। developers कभी सहमत नहीं होंगे कि कौन सा तरीका होना चाहिए।
    UI की बड़ी समस्या हमेशा यह नहीं रही कि उसे कैसे define किया जाए, बल्कि यह रही कि उसे कैसे update किया जाए। Microsoft ने MVC, MVP, MVVM जैसे कई models define करने की कोशिश की और असफल रहा, और वे सभी दर्दनाक थे। फिर imgui ने कहा, “अगर UI में state हो ही नहीं तो?” और वह काफी अच्छा है, लेकिन CPU पर भारी पड़ता है।
    शायद web apps की सफलता का एक सबसे बड़ा कारण यह था कि DOM ने data को view से बांधने का कोई तरीका force नहीं किया। इसलिए शायद हम framework hell से आसानी से बाहर नहीं निकल पाएंगे।

    • अब कई frameworks हैं जो Signals, proxies या दूसरे reactive primitives पर निर्भर हुए बिना भी fine-grained diffing अच्छी तरह करते हैं। मूल रूप से यह ऊपर से नीचे जाने वाला React model है, लेकिन कहीं ज्यादा तेज, और hooks या manual/wasteful dependency arrays जैसी अजीब अवधारणाएं भी नहीं हैं।
      मेरी निजी पसंद ivi-js है: https://github.com/localvoid/ivi
      benchmarks जीतने की सोच से आखिर में जिस सबसे तेज, सबसे बदसूरत, imperative और unmaintainable vanilla JavaScript तक पहुंचा जा सकता है, उससे यह सिर्फ 8% धीमा है।
      https://krausest.github.io/js-framework-benchmark/2025/table...
    • Microsoft ने अलग-अलग समय पर उन models का इस्तेमाल जरूर किया था, लेकिन सीधे define सिर्फ MVVM को किया। MVC Xerox PARC से आया, MVP Taligent से।
    • developer के नजरिए से भी, developer के दिमाग पर थोड़ा ज्यादा बोझ पड़े तो भी मैं वह रास्ता खुशी से चुनूंगा जो hardware, bandwidth और पृथ्वी के लिए आसान हो।
      “ज्यादातर apps को पागलों जैसी तेज़ी की जरूरत नहीं होती” कहने से ज्यादा, मैं चाहता हूं कि यह माना जाए कि apps को हल्का होना चाहिए।
      मैं मानता हूं कि लोग React को इसलिए चुनते हैं क्योंकि यह सरल है, लेकिन ठीक इसी वजह से मुझे React पसंद नहीं है।

  • JSX अपनाने के बजाय, बेहतर होगा कि यह Kotlin के receiver और builder के जरिए DSL के लिए सामान्यीकृत syntax देने के तरीके के ज्यादा करीब हो, और वही syntax component hierarchy को व्यक्त करने में भी अच्छी तरह फिट बैठे
    यह सिर्फ HTML template के लिए नहीं, बल्कि configuration और कई तरह की structures को व्यक्त करने में भी व्यापक रूप से उपयोगी होगा
    template और data binding की वास्तविक semantics को, Jetpack Compose में दिखने की तरह, ऐसे syntax feature इस्तेमाल करने वाले standard functions के set के रूप में रखा जा सकता है

    • बहुत ज्यादा चीजों की जरूरत भी नहीं है। repetition, attributes पर conditionals, और nodes पर conditionals काफी हैं। असल में इतना तो भाषाओं के बीच common feature के रूप में भी संभव है

  • यह भी महत्वपूर्ण है कि यह लेख इस क्षेत्र के सबसे अनुभवी लोगों में से एक ने लिखा है। वे Lit / Polymer के मुख्य authors में से हैं, और Google में Web Components पर काम करते हुए web platform का हिस्सा बन चुकी core DOM specifications में योगदान दे चुके हैं

    • बल्कि मैं उन्हें उन लोगों में से एक मानता हूं जिन्होंने आधी-अधूरी specification को लापरवाही से आगे बढ़ाकर जितनी समस्याएं हल कीं, उससे कहीं ज्यादा समस्याएं पैदा कीं। userland पहले से जो काम कर रहा था, उसे बस मुश्किल से दोहराने के लिए 20 से ज्यादा नई web specifications मांगने वाला “solution” उन्होंने push किया, और जो लोग 100% सहमत नहीं थे उन्हें ignore किया या gaslight किया
      Safari 15 साल पहले से कह रहा था कि यहां declarative तरीका होना चाहिए

  • क्या किसी और को भी लगता है कि declarative templates असल में jQuery से भी खराब हैं? मैं लगभग 10 साल से React इस्तेमाल कर रहा हूं, लेकिन SPA जितना complex होता जाता है, उतना ही DOM को imperative तरीके से सीधे control करने का मन होता है
    वजह यह है कि DOM एक leaky abstraction है, और किसी स्तर पर last write wins वाला तरीका बेहतर महसूस होता है
    मुझे पता है कि declarative templates इसे handle करने की कोशिश करते हैं, लेकिन जैसे ही आप components के बीच mutable state share करना शुरू करते हैं, यह तरीका बहुत जल्दी टूटने लगता है

    • React वाले लोग DOM API को सीधे call करने को जैसे कोई बड़ा पाप मानते हैं। कभी-कभी ref पकड़ना, और यह कहने की हिम्मत करूं तो id से component ढूंढकर उसे सीधे handle करना भी ठीक है। असल में “fast” और कम re-rendering वाली libraries, जैसे form libraries, ऐसा ही करती हैं
    • मुझे React पसंद नहीं है, लेकिन इस feeling से सहमत नहीं हूं। पहले तो आप पहले ही declarative DOM से बाहर निकलकर innerHTML और ref से मनचाहा कर सकते हैं
      दूसरा, मुझे समझ नहीं आता कि DOM को imperative तरीके से control करने पर declarative की तुलना में कौन सा काम कम झंझट वाला हो जाता है। attachShadow(), showModal() जैसे कुछ specific methods ही दिमाग में आते हैं, और उन्हें भी 10-line component में wrap करके declarative बनाया जा सकता है
    • पूरी तरह सहमत। मैंने अब तक ऐसा एक भी example नहीं देखा जिसने मुझे यह यकीन दिलाया हो कि React जैसी चीज अलग HTML और jQuery इस्तेमाल करने से जरा भी बेहतर है

  • मेरी समझ से Ryan Carniato और Solid JS अभी भी Signals से क्या-क्या संभव है, यह explore कर रहे हैं। मुझे नहीं लगता कि इस area में userland exploration पूरी तरह खत्म हो चुकी है, और अतिरिक्त innovation संभव हो सकता है

    • web development bubble के बाहर भी incremental computation problem space में काफी दिलचस्प research है, और self-adjusting computation, यानी Signals तक, कोई बहुत दिलचस्प axis नहीं है

  • दिशा मुझे पसंद है, लेकिन उससे पहले browser में कुछ और lower-level APIs आनी चाहिए, ऐसा लगता है
    standard template system पर सभी का agree करना लगभग असंभव होगा। इसके बजाय browser जो कर सकता है वह है DOM में differences को performant native तरीके से apply करने के लिए lower-level API देना
    browser में ऐसी चीज native रूप से हो तो बहुत अच्छा होगा
    element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' })
    यह तरीका element focus, input values, audio/video player state को बनाए रखते हुए और attributes बदलते हुए कम disruptive तरीके से differences apply कर सकता है। Idiomorph जैसी JavaScript library ऐसा काम करती है, लेकिन native solution के कहीं ज्यादा तेज होने की संभावना है

    • लेख में DOM part proposal का link है, जो एक useful lower-level API हो सकता है। यह VDOM-based frameworks के लिए बहुत फिट नहीं बैठेगा, लेकिन दूसरे frameworks में working model को simple कर सकता है और optimization की गुंजाइश भी बढ़ा सकता है
      framework-less projects के लिए भी यह उपयोगी होगा, और अगर Signals proposal भी adopt हो जाए तो खास तौर पर और उपयोगी होगा

  • Records and Tuples proposal सिर्फ रुका हुआ नहीं है, बल्कि withdraw हो चुका है। https://github.com/tc39/proposal-record-tuple/issues/394
    उसकी जगह https://github.com/tc39/proposal-composites ने ले ली है