HTML web components

(blog.jim-nielsen.com)

2 पॉइंट द्वारा GN⁺ 2023-11-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें

web components देखने में React components के browser version जैसे लग सकते हैं, लेकिन वास्तव में वे मौजूदा HTML को केंद्र में रखकर उस पर functionality जोड़ने वाले मॉडल के ज़्यादा करीब हैं
मुख्य अंतर JavaScript चलने से पहले rendering में है: खाली custom element को data देने की बजाय, अर्थपूर्ण HTML को custom element में wrap करना अधिक स्वाभाविक है
HTML web component मौजूदा markup को extend करता है, जबकि ऐसा खाली element जो content और functionality को पूरी तरह JavaScript पर छोड़ देता है, वह JavaScript web component के अधिक करीब है
अगर React-style componentization replacement की सोच से परिचित कराती है, तो web components content को बनाए रखते हुए functionality जोड़ने वाली augmentation की सोच मांगते हैं
web platform में HTML5, fetch, TypeScript जैसे प्रवाह दिखाते हैं कि अच्छे ideas अक्सर मौजूदा तकनीक को हटाने की बजाय उसे मजबूत और विस्तारित करने के रूप में लंबे समय तक टिकते हैं

Web components और React components की प्रकृति अलग है

“Web components” नाम सुनकर यह web platform पर React components के equivalent जैसा लग सकता है
- React का JSX <MyComponent> फ़ॉर्म इस्तेमाल करता है, और web components <my-component> फ़ॉर्म इस्तेमाल कर सकते हैं
- लेकिन अगर आप React components की तरह web components बनाने की कोशिश करेंगे, तो आसानी से निराश हो सकते हैं
दोनों तकनीकों में design की प्राथमिकताएँ और usage patterns अलग हैं
- अगर एक को दूसरे की तरह इस्तेमाल करने की कोशिश की जाए, तो यह हर तकनीक की स्वाभाविक दिशा से टकराता है

HTML web components replacement से ज़्यादा augmentation के लिए उपयुक्त हैं

एक सामान्य React component खाली component में properties के रूप में data पास करता है, और JavaScript पूरा content render करता है

<UserAvatar
  src="https://example.com/path/to/img.jpg";
  alt="..."
/>

ऊपर-ऊपर से देखें तो web components भी उसी तरह लिखे जा सकते हैं

<user-avatar
  src="https://example.com/path/to/img.jpg";
  alt="..."
></user-avatar>

लेकिन web components की असली ताकत यह है कि वे JavaScript से पहले rendering की अनुमति देते हैं
- React components इस तरह काम नहीं कर सकते
इसलिए खाली “shell component” की बजाय, core content को HTML में बनाकर custom element से wrap करना और फिर functionality जोड़ना अधिक उपयुक्त है

<user-avatar>
  <img src="https://example.com/path/to/img.jpg"; alt="..." />
</user-avatar>

Jeremy का “HTML web components” वाला भेद इस बात पर केंद्रित है कि custom element मौजूदा markup को extend करता है या नहीं
- अगर custom element खाली है, तो वह HTML web component नहीं है
- अगर वह मौजूदा markup को wrap करके extend करता है, तो वह HTML web component के अधिक करीब है
“JavaScript web component” वह रूप है जिसमें खाली element का content और functionality पूरी तरह JavaScript पर निर्भर करते हैं

<user-avatar
  src="https://example.com/path/to/img.jpg";
  alt="..."
></user-avatar>

इस रूप का JavaScript के बिना end user के लिए कोई अर्थ नहीं है
इसके उलट, HTML web component में JavaScript के बिना भी meaning और content बने रहते हैं, और JavaScript होने पर उसके ऊपर functionality जोड़ी जाती है

<user-avatar>
  <img src="https://example.com/path/to/img.jpg"; alt="..." />
</user-avatar>

वेब पर augmentation वाला तरीका लंबे समय तक टिकता है

web पर augmentation approach इसलिए अच्छी बैठती है क्योंकि web की प्रकृति resilient progressive enhancement को प्रोत्साहित करती है, और web जैसी बड़ी चीज़ को बार-बार बदलने के लिए यही अधिक उपयुक्त है
web ecosystem के frameworks और libraries के अच्छे ideas platform में समा भी जाएँ, तब भी वे अक्सर मौजूदा तकनीक को पूरी तरह replace करने की बजाय उसे extend और strengthen करने के रूप में आते हैं
- XHTML ने HTML4 को replace करने की कोशिश की, लेकिन HTML5 ने HTML4 को enhance करने की कोशिश की, और HTML5 जीत गया
- networking libraries ने XMLHttpRequest को replace करने की कोशिश की, और अच्छे ideas अंततः fetch standard में आ गए
- fetch आज browser के बाहर कई environments में भी मौजूद है
- Sass और jQuery के अच्छे ideas भी browser में आए
- TypeScript के अच्छे ideas भी मौजूदा तकनीक को replace किए बिना उसे enhance करने के रूप में browser में आ रहे हैं
web components को React के component model के browser में आने वाली धारा की तरह देखा जा सकता है, लेकिन यह web के पहले से काम करने के तरीके को replace करने की बजाय उसे enhance करने के अधिक करीब है
अगर आप लंबे समय तक टिकने वाला technical approach चाहते हैं, तो replacement की बजाय augmentation और improvement चुनना web की दिशा के अधिक अनुकूल है

1 टिप्पणियां

GN⁺ 2023-11-14

Hacker News की राय

मुझे उम्मीद थी कि यह लेख बताएगा कि user-avatar असल में क्या करता है या क्या प्रदान करता है, लेकिन आखिर तक यह नहीं आया
अगर इसमें सिर्फ style ही है, तो समझ नहीं आता कि बस CSS class क्यों न इस्तेमाल करें, और user-avatar से हर बार अंदर img tag डलवाने के बजाय src attribute लेना कहीं ज़्यादा स्वाभाविक लगता है
Vue/React/Angular HTML को “replace” करने की कोशिश करते हैं, ऐसा कम लगता है; वे HTML/CSS/JS के ऊपर build करने के ज्यादा करीब हैं, और अगर सब कुछ canvas से render किया जा रहा होता तो यह दावा ज्यादा convincing लगता
Web Components के पहली बार announce होने पर मुझे उम्मीद थी, लेकिन built-in functionality बहुत कम है, और ऐसा कम लगता है कि वे frameworks की तरह web apps बनाने में सच में मदद करते हैं
बड़े frameworks के alternatives, खासकर htmlx जैसी चीजें, jQuery family पर थोड़ी syntax sugar चढ़ाने जैसी दिखती हैं, इसलिए web apps बनाने के लिए यह बड़ा कदम पीछे जैसा लगता है
- “बड़े framework का alternative jQuery की syntax sugar जैसा है” इस बात से सहमत हूं, लेकिन यह web apps बनाने के लिए पूरी तरह गलत choice क्यों है, यह स्पष्ट नहीं है
  अगर ‘web app’ से मतलब Google Sheets जैसी चीज है, तो सहमत हूं, लेकिन यह anti-React trend उन cases से ज्यादा, default की तरह framework लगाकर शुरुआत से बनाने की प्रथा की आलोचना करता लगता है
  असल में ऐसी कई websites हैं जिन्हें बस “ऊपर से हल्का interaction” ही चाहिए होता है
- Eric Meyer का लेख मंशा को कहीं बेहतर दिखाता है: https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the...
  मुख्य फायदा progressive enhancement है: img tag का अपना default behavior होता है, इसलिए basic rendering पर भरोसा करके सिर्फ जरूरत वाले हिस्से को web component से “enhance” किया जा सकता है
- ठोस examples की कमी की वजह से यह लेख थोड़ा shower thought जैसा लगता है
- लेख की बात को ज्यादा ठोस रूप में दिखाने वाला example यहां बेहतर है: https://www.zachleat.com/web/details-utils
  details-utils component built-in HTML detail component के behavior को enhance करता है
  किसी कारण JavaScript बंद भी हो तो detail component वैसे ही काम करता है, और JavaScript चालू हो या download पूरा हो जाए तो बाहर click करने पर collapse होने जैसी enhanced behavior मिलती है
  इस तरीके में reuse करने लायक हिस्सा यही behavior enhancement है
  11ty के creator के इस web component को देखकर लेख की बात समझ आई, और जब मैंने पहली बार Web Components देखे थे तो “आखिर JavaScript चाहिए ही और उसके बिना यह काम नहीं करता” जैसा जो लगा था, वही point Rich Harris के लेख में भी आया था: https://dev.to/richharris/why-i-don-t-use-web-components-2ci...
- पता नहीं आपने htmx इस्तेमाल किया है या नहीं, लेकिन यह client-side JavaScript user experience वाली उस problem से अलग problem को address करता है जिसे jQuery solve करता था, इसलिए वह आलोचना निशाने से चूकी लगती है
  htmx मुख्य रूप से JavaScript लिखने से बचते हुए server-rendered HTML paradigm को full page reload के बजाय partial page updates तक extend करने का तरीका है
“HTML Web Components” idea के बारे में और देखने के लिए ये लेख भी पढ़ने लायक हैं
https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the... - “तो बात यह रही: इन पूरी तरह Light DOM web components, जिन्हें custom elements भी कहा जाता है, को समझने और उनके साथ काम करने की मेरी journey पर कुछ हजार शब्द। अब इन्हें बस एक catchy नाम चाहिए, ताकि हम और लोगों को Web के Light Side की ओर ला सकें।”
https://adactio.com/journal/20618 में एक ठीक-ठाक नाम सुझाया गया है
- बात समझ नहीं आई
  लिखना झंझट वाला है, इसलिए आखिरकार Lit जैसे built-in framework के ऊपर एक हल्के framework की जरूरत पड़ती है, जबकि Lit तो Preact से भी बड़ा है
  ऊपर से state management, routing जैसी असली problems solve नहीं होतीं, इसलिए और चीजें लानी पड़ने की संभावना ज्यादा है
  reusable components तो मिल सकते हैं, लेकिन सोचें कि React इस्तेमाल करने वाली जगह में internally Vue इस्तेमाल करने वाला web component लाकर इस्तेमाल करेंगे या नहीं, तो बात ठीक से बैठती नहीं
- Shadow DOM के बिना web components को push करने वाली trend देखकर सच में खुशी है
  web की खूबसूरती और elegance उसकी declarative structure से आई, और इसी से observability और modifiability मिली
  Shadow DOM ज्यादा ऊंची encapsulation barriers और certainty बनाने की corporate इच्छा जैसा लगा, और निजी तौर पर यह मेरा shared goal नहीं था
  यह लेख दिखाता है कि Light DOM work कैसे compose हो सकता है
  मुझे हमेशा लगा है कि web components या custom elements को अपने internal DOM को खुद modify करने, बच्चों को move करने और नया content बनाने में सक्षम होना चाहिए
  जैसे page या framework icon डाल सकता है, और user avatar element नाम या decorative elements insert कर सकता है
  हालांकि Light DOM/HTML Web Components को लेकर एक चिंता यह है कि Shadow DOM कुछ performance benefits देता है
  CSS selectors को जितने elements scan करने पड़ते हैं उनकी संख्या कम की जा सकती है, यह developer के तौर पर दिमाग में साफ दिखता है, और अच्छा होगा अगर उस benefit को भी किसी तरह इस्तेमाल किया जा सके
  custom elements और Web Components को ज्यादा हल्के तरीके से देखने वाला approach सच में अच्छा लगा, और links के लिए भी शुक्रिया
- क्यों न इस ठीक-ठाक नाम को और छोटा करके HTML components कहा जाए
“JavaScript से पहले render किया जा सकता है। React components ऐसा कभी नहीं कर सकते” कहना निश्चित रूप से कहना मुश्किल है, और अगर यह server-side rendering है तो यह client-side JavaScript से पहले render हो सकता है
मुझे लगता है कि उदाहरण लेखक के दावे को दिखाने के लिए बहुत ज़्यादा सरल है
state changes को handle करने वाला web component तुलना के लिए बेहतर होता, और तर्क भी बेहतर हो जाता
- अच्छी बात है, और उल्टा देखें तो web components को भी page load होने से पहले JavaScript से register होना पड़ता है, इसलिए कहा जा सकता है कि वे भी ऐसा नहीं कर सकते
  Hydration के समाधान हैं, लेकिन आम तौर पर वे और खराब होते हैं, उनमें चौंकाने वाले trade-offs होते हैं और अक्सर composability को नुकसान पहुंचाते हैं
- Web Components में सबसे बड़ी समस्या यह है कि वे server-side rendering-friendly नहीं हैं
- समझ नहीं आ रहा कि “HTML Web Component” state changes को कैसे handle करेगा
  सिर्फ img tag को wrap करने वाला उदाहरण देखकर फायदा ठीक से समझ नहीं आया, और सामान्य elements को group करके reuse तो किया जा सकता है, लेकिन interaction के लिए फिर भी JavaScript चाहिए
  उदाहरण में image का alternative text भी आजकल localization की वजह से आम तौर पर dynamic होता है, इसलिए JavaScript न हो तो content गायब हो सकता है
Web Components को लेकर आखिरकार मुझे समझ आने लगी है: https://github.com/kennyfrc/cami.js
“No Build Steps, No Client-Side Router, No JSX, No Shadow DOM. We want you to build an MPA, with mainly HTML/CSS, and return HTML responses instead of JSON. Then add interactivity as needed.”
“Declarative templates with lit-html. Supports event handling, attribute binding, composability, caching, and expressions.”
- Web Components की खूबसूरती यह है कि आप अपनी जरूरत के हिसाब से काम करने वाली base class ढूंढ या बना सकते हैं
  व्यक्तिगत रूप से मुझे XState से प्रेरित built-in state machine वाली React class component style की class पसंद है
  https://github.com/codewithkyle/supercomponent/blob/master/s...
- जानना चाहूंगा कि आपने HTMX इस्तेमाल किया है या नहीं
  दिशा काफी मिलती-जुलती लगती है, और शायद HTMX की community बड़ी हो सकती है
  अगर इस्तेमाल किया है तो जानना चाहूंगा कि उसमें क्या कमी लगी
- JSX को non-standard custom DSL से बदलकर उसे जीत कहना जैसा है
“web components” कोई एक चीज़ नहीं है, और आप “a web component” भी नहीं बनाते
“Web Components” तीन चीज़ों को जोड़ने वाली Web Components API का नाम है
असल में आप custom element बनाते हैं, और उसमें Shadow DOM इस्तेमाल कर सकते हैं या HTML template इस्तेमाल कर सकते हैं
तीनों में सबसे अहम custom element है
मूल concept है “और HTML elements बनाना”, इसलिए कौन-से attributes और JavaScript API support करने हैं, यह सब आप खुद तय करते हैं
इसे page पर डालना, उससे interact करना और events listen करना भी बाकी HTML elements जैसा ही है
अगर आप “पुराने तरीके” से web page लिखना जानते हैं, तो custom elements इस्तेमाल करना आप पहले से जानते हैं; बस उन्हें declare करना सीखना है
हाल ही में build environment के बिना Web Components आजमाने शुरू किए हैं
npm, bun, webpack जैसा कुछ नहीं है, dependencies भी नहीं हैं, और TypeScript में लिखा है
IntelliJ अपने आप JavaScript में compile कर देता है, और browser view development के दौरान live updates के लिए एक छोटा change-detection handler inject करता है
अभी तक कोई समस्या नहीं हुई
Web Components को पीछे खींचने वाली चीज़ HTML Modules लगती है
अगर web component import करने के लिए .js file के बजाय .html file को link किया जा सके तो अच्छा होगा, लेकिन अभी templates या कुछ ज्यादा complex इस्तेमाल करने के लिए .innerHtml = \...`` जैसी भद्दी injection करनी पड़ती है
लगा था कि यह समस्या बनेगा, लेकिन IDE template strings को काफी अच्छी तरह parse कर देता है
- HTML Modules को abandon करके हटा दिया गया और JavaScript-only imports से replace कर दिया गया
  और Web Components को रोकने की यह अकेली वजह भी नहीं है
“React enhancement नहीं, replacement है” वाले दावे से मैं पूरी तरह सहमत नहीं हो पाता
आखिर React भी HTML elements render करता है और JavaScript event handlers जोड़ता है
img को React component में wrap करने से img की functionality छिन नहीं जाती; उसके ऊपर कुछ जोड़ा जाता है, यानी enhancement ही है
हो सकता है लेखक ने अलग React codebase में काम किया हो, लेकिन मेरे अनुभव में हम बिना वजह browser की built-in functionality को वैसे ही इस्तेमाल करते हैं
शायद हम बस lucky रहे हों
- यह तो स्वाभाविक है कि कोई भी web architecture आखिरकार HTML elements ही render करता है, लेकिन point वह नहीं था
  point यह है कि “HTML Web Component” वाला तरीका React के उलट rendering शुरू करने के लिए JavaScript पर निर्भर नहीं करता
- लेख जिस मुख्य फर्क की बात करता है, वह मुझे मोटे तौर पर ऐसा लगता है
  Browser rendering के लिहाज से React “page load → component load” है, जबकि Web Component “page load → basic rendering → component load” के करीब है
  जिन लोगों ने JavaScript बंद कर रखा है, वे web components में कुछ देख सकते हैं, लेकिन React में शायद कुछ भी न देख पाएं; और JavaScript हो तो वह और उन्नत rendered state तक जा सकता है
- कुछ मामलों में React built-in functionality तक पहुंचना और मुश्किल भी बना देता है
  उदाहरण के लिए, अगर onchange को किसी element पर assign करें, तो React आपको change event नहीं बल्कि input event के करीब कुछ देता है
  असल में वह दोनों में से कोई नहीं, बल्कि change की तुलना में input के करीब एक synthetic event देता है
  अगर सच में change चाहिए, तो element reference इस्तेमाल करके effect के अंदर handler को सीधे attach करना पड़ता है
- यह app architecture पर निर्भर करता है
  अगर React से server पर HTML return कर रहे हैं, तो img को React component में wrap करना मौजूदा element को enhance करना ही है
  लेकिन अगर पूरा कुछ client-side render हो रहा है, तो वह img आखिरकार React component से अलग नहीं हो सकता
- उस हिस्से को पढ़ते हुए मुझे उल्टी दिशा, यानी किसी दूसरे HTML के अंदर React डालने वाला मामला याद आया
  मेरे अनुभव में React तब शानदार है जब page structure पूरा ऊपर से नीचे तक उसी को सौंप दिया जाए, लेकिन server-side rendering जैसे काम करते हुए उसे मौजूदा structure के अंदर फिट करने की कोशिश करें तो चीजें मुश्किल हो सकती हैं
अगर लंबे समय तक चलने वाला तरीका चाहिए, तो replacement के बजाय enhancement और progressive improvement चुनने वाला निष्कर्ष मेरे अनुभव से भी मेल खाता है
इसी philosophy की वजह से मेरे web projects maintenance और dependencies को minimum रखते हुए लंबे समय तक चलते रहे
Web component को एक ही काम करना चाहिए, जबकि JavaScript framework लगभग पूरे ecosystem जैसा होता है
मैंने एक video player web component बनाया था जो कई तरह के inputs ले सकता था, और सबसे जटिल input torrent file था
StencilJS [0] से उसे Vue/React में port भी किया जा सकता था, लेकिन उसके बिना भी वह पर्याप्त रूप से usable था
awesomePlayer.js से exported class के साथ बस वह tag डाल दें, और torrent चलाने वाला copy-paste-ready HTML5 video player मिल जाता है
जहां संभव हो, मौजूदा HTML elements की नकल करने की भी जोरदार सलाह दूंगा
उदाहरण के लिए src इसलिए इस्तेमाल किया क्योंकि video ऐसा करता है; इससे इस्तेमाल करने वाले को documentation खंगाले बिना ही interaction समझ आ जाता है
[0] https://stenciljs.com/
यह मानना मुश्किल है कि frontend framework components पूरी तरह replacement के लिए होते हैं और composable नहीं होते
ऊपर-ऊपर से ऐसा लग सकता है, लेकिन मेरे components में मैं slots का खूब इस्तेमाल करता हूं, और implementation भी आसान है तथा वे naturally काम करते हैं
इसके उलट Web Components आम तौर पर किसी editor जैसी चीज बनाने के लिए ढेर सारा code inject करने के रूप में demo किए जाते हैं
Web Components में slots इस्तेमाल करना तकलीफदेह है, बहुत सारे nodes हाथ से जोड़ने पड़ते हैं, templates को strings की तरह handle करना पड़ता है, और थोड़ा complex काम करना हो तो slotchange event तक सुनना पड़ता है
मूल रूप से यह DOM API इस्तेमाल करना ही है, और अगर वह API इतनी खराब न होती तो हम React जैसे frontend frameworks की तरफ जाते ही नहीं
XHTML इसलिए failed हुआ क्योंकि उसने HTML को enhance नहीं किया—इस साइड वाले तर्क से भी मैं सहमत नहीं हूं
मेरे हिसाब से वह इसलिए fail हुआ क्योंकि application को पूरी तरह valid होना पड़ता था और उस validation को client/browser पर छोड़ दिया गया था
अगर सचमुच XHTML इस्तेमाल किया जाता, तो markup की एक छोटी-सी गलती से page टूट जाता; इसलिए सभी ने future-proofing के लिए XHTML validate तो किया, लेकिन कोई भी company सिर्फ इसलिए अपना business टूटने का risk नहीं लेती कि एक p tag ठीक से close नहीं हुआ था

HTML web components

Web components और React components की प्रकृति अलग है

HTML web components replacement से ज़्यादा augmentation के लिए उपयुक्त हैं

वेब पर augmentation वाला तरीका लंबे समय तक टिकता है

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

1 टिप्पणियां

Hacker News की राय