Web Components JavaScript frameworks से ज्यादा टिकेंगे

 (jakelazaroff.com)
1 पॉइंट द्वारा GN⁺ 2023-10-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • CRDT tutorial के interactive demo को लंबे समय तक टिकने वाली content की तरह संभालना हो, तो किसी खास framework की बजाय HTML में सीधे डाले जा सकने वाले Web Components ज्यादा उपयुक्त हैं
  • Astro के MDX components build, CSS scope, TypeScript जैसी सुविधाएं देते हैं, लेकिन Astro के बाहर ले जाने पर rewrite cost आ सकती है
  • Web Components में <pixelart-demo></pixelart-demo> जैसे custom tag को Markdown में डालकर, सिर्फ script load करने से page में कहीं भी tag-based reuse संभव है
  • Framework और TypeScript भी dependencies हैं, इसलिए version, API और compatibility changes जमा होते जाते हैं; लंबे समय तक छोड़े गए code को dependencies जितनी ज्यादा होंगी, restore करना उतना मुश्किल होगा
  • Web platform इतना stable है कि पुराने sites modern browsers में भी चलते हैं; इसलिए 5, 10, 20 साल बाद access किए जा सकने वाले काम के लिए standards-based approach फायदेमंद है

Interactive demo को content की तरह preserve करना

  • CRDT blog series में concepts दिखाने के लिए interactive demo की जरूरत थी, और example के तौर पर collaborative pixel art editor इस्तेमाल किया गया
  • Technology चुनने का criteria यह था कि demo भले ही HTML, CSS, JS से बना हो, लेकिन blog post के अंदर शामिल होने वाली content के ज्यादा करीब है
    • यह image या video की तरह post में embed की जाने वाली चीज के करीब है
    • जहाँ भी HTML render हो सकता है, वहाँ इसे ले जाया जा सकना चाहिए
  • Site 2023 के हिसाब से Astro में बनी थी, लेकिन इससे पहले यह custom static site generator, Hugo, PHP custom CMS, Tumblr, Movable Type, WordPress वगैरह से गुजर चुकी थी
  • अभी Astro पसंद हो, फिर भी यह मान लेना मुश्किल है कि website हमेशा Astro पर ही चलेगी

Markdown ने migration cost कैसे घटाई

  • हाल की migration आसान इसलिए थी क्योंकि content को Markdown plain-text files के रूप में रखा गया था
  • System बदलते समय आम तौर पर जरूरी होने वाले काम कम हो जाते हैं
    • एक system से export करके दूसरे system में import करना
    • Compatibility issues fix करना
    • जिन elements को move करने का तरीका न मिले उन्हें हटाना
  • Markdown files को नई website में डालने पर वे ज्यादातर वैसे ही काम करती हैं
  • Markdown में HTML सीधे लिखा जा सकता है, इसलिए जटिल interactive diagrams भी अगर सामान्य HTML tags से express किए जा सकें, तो बाकी content की तरह portable होते हैं

Astro MDX की सुविधा और portability की सीमा

  • Astro का MDX integration Markdown के अंदर Astro components render करने देता है
  • Astro components build system की कई सुविधाओं का फायदा उठाते हैं
    • एक file में HTML, CSS, JS लिखना
    • CSS selectors की scope handling
    • TypeScript compilation
    • Conditional markup rendering
    • अन्य optimizations
  • समस्या यह है कि ये सारी सुविधाएं Astro के अंदर ही reliably काम करती हैं
  • किसी दूसरे site generator में move करने पर components फिर से लिखने पड़ सकते हैं
    • HTML, CSS, JS को अलग करना पड़ सकता है
    • नया build system configuration चाहिए हो सकता है
    • Style scoping का नया तरीका ढूंढना पड़ सकता है
  • इसलिए Astro-specific features सुविधाजनक होने के बावजूद long-term preservation की जरूरत वाले demo के लिए सही choice नहीं बनते

Web Components ने क्या हल किया

  • Web Components reusable HTML elements बनाने के लिए web standards technologies का एक set है
  • इस्तेमाल का तरीका है custom element class लिखना, tag name register करना, और markup में उस tag का उपयोग करना
  • Pixel art demo को Markdown में सिर्फ यह HTML डालकर शामिल किया गया
<pixelart-demo></pixelart-demo>
  • अलग से special configuration या किसी specific element को पहले place करके function call करने जैसी प्रक्रिया की जरूरत नहीं है
  • JS file maintain रखनी और <script> tag से connect करनी होती है, लेकिन text content के अंदर media reference करने का तरीका चाहिए—यह बात दूसरे media जैसी ही है
  • Script load होते ही tag name register हो जाता है, और JavaScript चलने से पहले markup पहले से मौजूद हो, तब भी यह page में कहीं भी काम करता है

Single-file structure और Shadow DOM

  • Web Components HTML, CSS, JS को एक file में encapsulate कर सकते हैं, और अलग build system की जरूरत नहीं होती
  • Component code एक जगह इकट्ठा हो तो mental overhead घटता है, और single-file component development experience के लिहाज से भी advantage देता है
  • Example <pixelart-demo> component HTMLElement को inherit करता है, attachShadow({ mode: "closed" }) से Shadow DOM attach करता है, फिर internal markup और styles render करता है
  • File के top पर import PixelEditor from "./PixelEditor.js"; ES module import है, इसलिए यह अलग build system पर निर्भर नहीं है
  • Related files साथ रखी जाएं तो browser modules को handle करता है
  • Shadow DOM component को आसपास के page से isolate करता है
    • जब पूरे app के साथ styles share करनी हों, तो यह awkward हो सकता है
    • जब पूरी तरह isolation चाहिए हो, तो यह उपयुक्त है
    • Image या video की तरह, जहाँ भी इस्तेमाल हो, वही appearance और behavior बनाए रख सकता है

Attributes से बाहरी settings लेना

  • Web Components बाहर से configure किए जा सकने वाले attributes expose कर सकते हैं
  • Attributes को native attributes की तरह इस्तेमाल किया जा सकता है
  • CSS variables उन कुछ values में से हैं जो Shadow DOM के अंदर जा सकती हैं, इसलिए example range slider accent color इस तरह set करता है
<range-slider style="--accent: #0085F2"></range-slider>
  • Pixel art demo attributes से resolution को 20 में बदलता है और हर pixel की debug information दिखाता है
<pixelart-demo debug resolution="20"></pixelart-demo>
  • Component class के getAttribute और hasAttribute calls ऐसे attribute values पढ़ने के लिए इस्तेमाल होते हैं
  • Tutorial के कई stages में वही component reuse करते हुए, progress stage के अनुसार specific features on करने में यह useful था

Framework और TypeScript भी dependencies हैं

  • Lit, Stencil, Svelte जैसे tools हैं जो Web Components में compile होते हैं, लेकिन framework आखिरकार dependency ही है
  • यहाँ सबसे बड़ी चिंता वाला trade-off long-term maintenance cost था
  • TypeScript भी web का native base नहीं है, इसलिए यह dependency है
  • TypeScript के हाल के 15 versions में breaking changes थे, और उनमें से कई changes useful new features थे, लेकिन code modifications जरूरी थे
  • Dependencies इस्तेमाल करने पर new version releases, API changes, compatibility check की cost साथ आती है
  • इस code को लगातार touch करने की योजना नहीं है, इसलिए बाद में कभी जरूरी fix करना पड़े तो कई साल के updates एक साथ handle नहीं करने की स्थिति चाहिए

पुरानी websites restore करने का अनुभव और web platform की stability

  • Online museum बनाते समय 10 साल से चालू न किए गए laptop में stored पुराना code restore किया गया, और dependencies जितनी ज्यादा वाली websites थीं, उन्हें वापस चलाना उतना मुश्किल था
  • करीब 20 साल web बनाते हुए jQuery का जन्म, बढ़त और गिरावट देखी, और Node.js का बनना तथा io.js fork और merge भी अनुभव किया
  • Backbone को AngularJS ने, AngularJS को React ने तेजी से replace किया, और React ने भी उसके लगभग आधे समय में component लिखने के कई तरीके देखे
  • Ecosystem बदलता रहा, लेकिन web platform खुद existing websites को न तोड़ने के लिए सावधानी से बदला गया और काफी stable बना रहा
  • पुरानी sites आज भी modern browsers में चलती हैं
  • अगर 5, 10, 20 साल बाद भी access किए जा सकने वाला काम चाहिए, तो जिन dependencies को control नहीं कर सकते उन्हें घटाना और जिन web standards के टूटने की संभावना कम है उनसे जुड़े रहना बेहतर है
  • Web में खामियां हों, फिर भी जब बीच की layers के बिना उसकी characteristics को ध्यान में रखकर बनाया जाता है, तो यह resilient, portable और future-oriented computing platform बनता है

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

1 टिप्पणियां

 
GN⁺ 2023-10-27
Hacker News की रायें

  • htmx कोई framework नहीं, बल्कि library है, और लेख में इसका ज़िक्र हुआ है, इसलिए कुछ बातों का जवाब देना चाहूँगा
    सबसे पहले, लेख server और state को synchronize करने की समस्या पर बात नहीं करता, जबकि htmx hypermedia exchange के ज़रिए ठीक इसी समस्या पर focus करता है। इसलिए इस नज़रिए से htmx और Web Components एक-दूसरे से orthogonal संबंध रखते हैं
    dependencies के साथ नई versions, API changes और compatibility बनाए रखने की लागत आती है, इसलिए htmx की कोई dependency नहीं है और यह backward compatibility पर बहुत ज़्यादा focus करता है। उदाहरण के लिए, यह IE11 के साथ compatible है, और htmx 1.0 जैसा intercooler.js 2013 में सिर्फ़ एक jQuery dependency के साथ आया था, लेकिन अब भी supported है
    कई JavaScript libraries में API rewrite और मुश्किल upgrades की culture होती है, लेकिन htmx स्पष्ट रूप से वैसा नहीं है, और उसे ऐसी generalization में नहीं बाँधना चाहिए। htmx 2.0 में शायद एकमात्र breaking change IE support हटाना होगा
    Web Components htmx से ज़्यादा लंबे समय तक टिकेंगे या नहीं—क्योंकि वे browser का हिस्सा हैं, तो शायद हाँ—लेकिन जहाँ तक संभव हो htmx आगे भी बहुत stable और कम बदलाव वाला रहेगा। API मूल रूप से सही दिशा में है, और मुझे नहीं लगता कि purity या coolness के लिए सब कुछ फिर से लिखने की ज़रूरत है
    सबसे बढ़कर, htmx Web Components से अलग सवाल का जवाब देता है: server और state को कैसे synchronize किया जाए

    • हमारी company में React को Htmx से replace किए हुए लगभग 1 साल हो गया है, और जिन React components को हम बचाकर रखना चाहते थे, उन्हें native browser widgets की तरह reuse करने में Web Components बहुत उपयोगी रहे
      WebComponent इस्तेमाल करने पर आप उन DOM elements के lifecycle में hook कर सकते हैं जिन्हें बाहर से modify किया जाता है, जैसे Htmx का morphdom करता है। attributes बदलें तो React component को बताना होता है, और node DOM से हटे तो React को cleanup procedure चलाने के लिए बताना होता है। मुझे लगता है WebComponents के बिना इसे साफ़ और efficient तरीके से करना मुश्किल होता
      नतीजतन हम Htmx वाले तरीके पर बने रह सकते हैं, जिसमें business logic state पूरी तरह server पर रहती है, और client पर सिर्फ़ कुछ conservative चीज़ें रहती हैं, जैसे currently focused element या typing के दौरान का text। इस दिशा में जितना आगे बढ़ते हैं, bugs और race conditions उतनी कम होती हैं और user experience काफ़ी बेहतर होता है, इसलिए मेहनत वाजिब है
    • मैं लेख का लेखक हूँ; लगता है बात मेरे इरादे से अलग समझी जा रही है, इसलिए वह sentence हटा दूँगा। Twitter पर भी मैंने लिखा था कि Web Components आपकी पोस्ट में समझाई गई hypermedia-friendly scripting में स्वाभाविक रूप से fit होते हैं, और मुझे वह पोस्ट काफ़ी पसंद है
      https://x.com/jlazaroff/status/1717176726248108469
      https://htmx.org/essays/hypermedia-friendly-scripting/
    • मुझे उम्मीद थी कि htmx सिर्फ़ एक साधारण JavaScript library बनकर न रह जाए, बल्कि long term में HTML का ही standard बन जाए
      सिर्फ़ forms के POST कर सकने और response handle करने का इकलौता तरीका पूरी page को फिर से लिखना होना—ये constraints मनमाने ढंग से restrictive लगते हैं। अगर htmx HTML6 जैसी कोई चीज़ बन जाए, तो यह सभी JavaScript frameworks से ज़्यादा लंबे समय तक चलेगा
    • यह सुनकर वाकई अच्छा लगा कि htmx आगे बहुत stable और कम बदलाव वाला रहेगा
      मैं मुख्य रूप से backend पर focus करने वाला engineer हूँ, इसलिए ज़्यादातर JS libraries जिन्हें मैं इस्तेमाल करता हूँ, बाद में maintenance burden बड़ा होता है और major API changes भी अक्सर आते हैं। htmx को personal project में एक बार try करने का सोच रहा हूँ
    • मैं अपने side project SPA को htmx में फिर से लिखना चाहता था। Web Components में खास interest नहीं था, लेकिन htmx के साथ उनका इस्तेमाल करना दिलचस्प idea है
      server side पर HTML fragments generate करने वाले templates भी शायद कम complex हो जाएँगे
      htmx अपने आप में सचमुच compelling concept है, लेकिन काश इसकी community बड़ी होती। यह chicken-and-egg problem तो है, लेकिन दूसरे web frameworks की तुलना में blog posts या videos जैसे resources ज़्यादा नहीं हैं। उदाहरण के लिए, Auth0 authentication को htmx app में integrate करने जैसी basic चीज़ भी ढूँढना मुश्किल है

  • non.io को पूरी तरह pure Web Components में लिखा गया है, और यह एक पूर्ण SPA है। साधारण nested blog components से आगे बढ़ते हुए कुछ बातें सीखने को मिलीं
    State management का अब भी कोई साफ़ जवाब नहीं है। अगर wrapper framework न इस्तेमाल करें, तो बहुत कुछ खुद करना पड़ता है। React की अच्छी बातों में से एक यह है कि state management बड़े स्तर पर हल हो चुका है और मौजूदा patterns व expectations हैं। Web Components में यह Wild West जैसा है, और JSX की तरह complex objects को attributes के रूप में पास नहीं किया जा सकता, इसलिए attributes, events और class functions को सीधे call करने का मिश्रण करना पड़ता है
    Performance भी उम्मीद जितना बड़ा फायदा नहीं निकली। छोटे atomic elements, जैसे icons, जब page पर सैकड़ों हों तो instance बनाने की cost उनकी value से ज्यादा हो जाती है, इसलिए उन्हें Web Components से वापस हटा दिया। Static elements को Web Components के रूप में इस्तेमाल करना, भले ही code readability दे, worth it नहीं लगा—काफी निराशाजनक था
    फिर भी कुछ बातें सच में बहुत पसंद आईं। लेखक ने जैसा कहा, आप जो भी framework इस्तेमाल कर रहे हों, नए page में component जोड़ना बहुत आसान है। अगर वह Web Components से बना है, तो उसे सचमुच कहीं भी इस्तेमाल किया जा सकता है। nonio के API docs जैसी सहायक sites बनाते समय, stack अलग होने पर भी मनचाहे components चुनकर इस्तेमाल करना आसान था, यह अच्छा लगा। अगर component embed करना हो, तो JS लाएँ और HTML जोड़ दें—बस
    shadow root की style encapsulation भी काफी अच्छी है। Page पर काम करते समय किसी component की styling टूट जाएगी, इसकी चिंता न करनी पड़े, यह पसंद आया। दूसरे elements की styles को overwrite करेंगे या नहीं, इसका अनुमान लगाने और जांचने का काम घटता है, और इसे guarantee करने के लिए visual diff testing framework की ज़रूरत भी कम होती है
    Package size छोटा होना भी अच्छा है। कोई library या extra load नहीं, सब कुछ built-in है। जरूरी components को आसानी से चुनकर इस्तेमाल किया जा सकता है, इसलिए package size कम रखना भी बहुत आसान है
    nonio के source components यहां हैं: https://github.com/jjcm/nonio-frontend/tree/master/component...

    • attributes के रूप में objects पास नहीं कर पाने वाली बात के लिए—element की properties के जरिए उन्हें पास किया जा सकता है
      State management की तरफ भी, आप जो भी state management solution चाहें उसे जोड़ने से कुछ भी नहीं रोकता। अगर लक्ष्य dependencies को minimum रखना है, तो browser के built-in event model का इस्तेमाल करने वाले solutions भी काफी देखे हैं
      अंत में, pure Web Components में पूरी app लिखना व्यक्तिगत तौर पर मुझे काफी ज्यादा खिंचा हुआ विचार लगता है। 5KB में Lit इस्तेमाल करने से कहीं बेहतर developer experience मिल सकता है: https://lit.dev
    • क्या performance सच में फायदा है? सामान्य web frameworks जैसे React, Vue, Svelte आदि इस्तेमाल करने की तुलना में performance खराब होने की उम्मीद है
      ये frameworks आमतौर पर पूरे page में DOM manipulations को batch करके performance हासिल करते हैं, लेकिन Web Components में ऐसा नहीं किया जा सकता
      सिर्फ इसी वजह से भी Web Components मुझे लगभग dead end लगते हैं। जब पूरी तरह client-rendered page के बजाय सिर्फ छोटे feature islands चाहिए हों, तब ये उपयोगी हो सकते हैं
    • सोच रहा हूं कि shadow DOM न इस्तेमाल करने वाले Web Components में भी performance problem थी या नहीं
      मैंने भी ऐसी ही performance limits देखी हैं, लेकिन हमेशा सोचा कि shadow DOM भारी होने की वजह से है। अब सोच रहा हूं कि क्या instance creation खुद ही भारी है
      State management में भी वही समस्या महसूस हुई, और desktop development से idea लेकर window-level message bus रखने का सोच रहा हूं, जहां सभी components subscribe/filter करें और हर state change उस message bus पर publish हो
    • JSX की तरह complex objects को attributes के रूप में pass किया जा सकता है
      complex objects को attributes के रूप में pass करने का उदाहरण यहां zx-listeditor में देखें:
      https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
      Web Component खुद यहां है:
      https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
      इसे संभव बनाने वाली छोटी 500-line library यहां है:
      https://github.com/wisercoder/uibuilder/#jsx-for-web-compone...
    • Web Components में state management को अनसुलझी समस्या कहा गया, इसलिए एक ऐसा project साझा कर रहा हूं जिसका लक्ष्य solution देना है: https://github.com/launchscout/live_state
      LiveState का basic pattern है “events dispatch करो, state subscribe करो।” Events और state updates WebSocket connection से भेजे जाते हैं, और frontend व backend libraries Phoenix Channels के ऊपर एक thin layer हैं
      फिलहाल event handler functions Elixir में लिखे जाते हैं, लेकिन ऐसे किसी भी language में लिखने लायक बनाने पर काम चल रहा है जो WebAssembly में compile होती हो

  • मुझे उम्मीद नहीं है कि मेरी पसंदीदा JS framework हमेशा वही रहेगी। मुझे पता है कि इसकी उम्र छोटी होती है, और मुझे यही बात अच्छी लगती है
    आगे बढ़ना, progress करना और improve करना ही React, Vue, Svelte आदि इस्तेमाल करने की वजह है। अभी मुझे कोई static चीज़ नहीं चाहिए। क्योंकि Web Components सहित आज उपलब्ध frameworks में से कोई भी इस समस्या को खास elegant तरीके से solve नहीं करता
    अगर दावा यह है कि Web Components से बनी sites, JS framework से बनी sites से ज़्यादा समय तक चलती हैं, तो मैं इस पर शर्त लगाना चाहूँगा। सच कहूँ तो, अगले 20 सालों में Web Components technology stack का कोई हिस्सा Chrome, Safari, Firefox से हटकर apps तोड़ दे, इसकी संभावना मुझे 2 साल पहले लिखी React 16 app के JavaScript में बदलावों की वजह से टूटने की संभावना से ज़्यादा लगती है

    • वह शर्त शायद जीतने लायक है, लेकिन लगता है कि उसकी शर्तें ऐसी रखी गई हैं कि उसका मतलब लगभग नहीं रह जाता
      अगर React 16 app की सभी dependency versions को पूरी तरह pin कर दिया जाए, तो वह टूटे बिना चल सकती है, लेकिन वह “React 16 app पर लगातार काम और hacking कर पाना” से ज़्यादा किसी पुराने program को VM या emulator में चलाने जैसा है
      ज़्यादा meaningful शर्त यह होगी: “क्या React ZZZ app पर लगातार development किया जा सकता है vs क्या Web Components से बनी app पर लगातार development किया जा सकता है”
      अगर मैं शर्तों को अपने पक्ष में रखते हुए भी उन्हें ज़्यादा meaningful बनाऊँ, तो सवाल होगा: “N सालों की dependency updates catch up करने के लिए React app को update करने की लागत Web Components app से ज़्यादा है या कम?” अगर Web Components app में अजीब dependencies का ढेर नहीं डाला गया है, तो मुझे लगता है कि React app वाली update cost के ज़्यादा होने की संभावना बहुत अधिक है
      मूल रूप से यह शर्त लगाने जैसा है कि browser vendors, React authors की तुलना में backward compatibility कम नहीं तोड़ेंगे
    • ऐसा पहले हो चुका है
      HTML Imports को JS-only solution को तरजीह देते हुए deprecate कर दिया गया था, और Firefox ने इसे पहले ही implement किया था
      Custom Elements v0 भी deprecate हुआ था; Chrome ने इसे implement किया था और YouTube को जल्दबाज़ी में इसी पर फिर से लिखा गया था। YouTube को migrate करने में इतना समय लगा कि implementation हटाने के लिए करीब 4 साल इंतज़ार करना पड़ा
    • मुझे लगता है कि अगर आप पुराना code चलाते रहें और dependencies update न करें, तो समय के साथ खोजी जाने वाली और नई library versions में fix होने वाली security vulnerabilities के लिए site expose हो सकती है
      code को सुरक्षित रखने के लिए libraries update करनी पड़ती हैं। लेकिन पुरानी library versions का support बंद हो जाता है, और ऐसी known vulnerabilities जमा होने लगती हैं जिन्हें आप fix नहीं कर सकते। attackers के पास known vulnerabilities वाली websites को scan करके automatic attack करने वाले programs होने की संभावना ज़्यादा है
      इसके उलट, Web Components जैसी backward compatibility को महत्व देने वाली library या platform इस्तेमाल करने पर security बनाए रखते हुए पुराने code को ज़्यादा लंबे समय तक support किया जा सकता है

  • ध्यान technology से ज़्यादा लोगों पर जाने लगता है
    अगर कोई नया project शुरू कर रहा हूँ, तो पहले देखता हूँ कि उस project पर काम करने वाले लोग क्या जानते हैं। frontend में आजकल React जैसा कोई common denominator या best practice हो, तो बस वही इस्तेमाल करता हूँ
    ऐसे technical decisions को लेकर ज़्यादा परेशान नहीं होता। क्योंकि team composition, job-seeker market और StackOverflow की technology rankings ऐसे सवालों के जवाब आसानी से दे देती हैं

    • मुझे यह approach समझ में आती है और practical लगती है
      लेकिन अगर हर कोई ऐसा ही सोचे, तो software बनाने का कोई बेहतर जवाब मौजूद होने पर भी हम हमेशा React ही इस्तेमाल करते रहेंगे। popular चीज़ इस्तेमाल करने का मतलब है कि आप अपने tech stack के improvement के लिए उन दूसरे लोगों पर निर्भर हैं जो अच्छे technical solutions खोजकर उन्हें popular बनाएँगे
      दूसरे शब्दों में, यह strategy adoption curve पर साफ़ तौर पर mid-to-late adopters की तरफ़ आती है। ऐसे लेखों और चर्चाओं का बड़ा हिस्सा earlier adopters को target करता है

  • Markdown के अंदर HTML लिखा जा सकता है, इसलिए यह बात कि चमकदार interactive diagrams भी अगर सामान्य HTML tags से व्यक्त किए जा सकें तो वे Markdown के बाकी हिस्सों की तरह portable होंगे, MDX से भी बिल्कुल वही काम किया जा सकता है
    यहाँ Web Components नाम की तकनीक अपने-आप में मदद नहीं कर रही है। लेखक जिस चीज़ की परवाह कर रहा है, वह markup और runtime functionality लागू करने वाले code snippets के बीच का interface है। Web Components यहाँ सिर्फ implementation detail हैं। Angle brackets के बीच नाम लिखते समय आप React component को refer कर रहे हैं, Astro की किसी चीज़ को, या Web Component को—यह महत्वपूर्ण नहीं है। असली बात यह है कि कोई दूसरी चीज़ call होती है
    यहाँ Web Components की कमी यह है कि वे व्यावहारिक रूप से सिर्फ client पर ही चलते हैं। Server पर render किए गए shadow DOM content को client तक पहुँचाने का कोई तरीका नहीं है, इसलिए Web Component पूरी तरह non-interactive हो तब भी उसे render करने के लिए client JS चाहिए। दूसरे frameworks में ऐसा नहीं है
    इसका मतलब यह नहीं कि लेखक की बात गलत है। Code snippets के बीच interface को व्यवस्थित करने के तरीके के रूप में Web Components शायद सबसे अच्छे और लंबे समय तक टिकने वाले तरीकों में से एक हो सकते हैं। लेकिन server पर Web Components कोई मदद नहीं करते। वे render नहीं होते, interface झंझट भरा है, और code पहले से ही शायद ऐसे लिखा गया होता है कि उसे पूरे रूप में संभाला जा सके। अगर server पर Astro इस्तेमाल कर रहे हैं, तो Astro ही इस्तेमाल करते रहें। React हो, Vue हो या कुछ और—बात वही है
    Web Components जहाँ चमकते हैं, वह client है। जब आप third-party components इस्तेमाल करते हैं जो शायद आपके चुने हुए framework में नहीं लिखे गए हों, तो page पर रखे गए component को किस framework से बनाया गया है, यह जानने की ज़रूरत नहीं होती। HTML tag लिखिए और वह काम करता है। Interface mechanism browser level तक ऊपर चला जाता है, इसलिए दो frameworks को एक-दूसरे की implementation details जानने की ज़रूरत नहीं रहती

    • मुझे लगा था कि आप यह दावा करने वाले हैं कि server पर tag के पास जादुई तरीके से अपना internal HTML खुद पाने का कोई तरीका नहीं है
      उस लिहाज़ से, कोई tool चाहिए—इस बात में आप सही हैं। हालांकि वह tool कोई भी server-side template engine हो सकता है जो initial HTML भरकर bootstrap कर दे
      लेकिन server-rendered shadow DOM को client तक पहुँचाया जा सकता है। इसे declarative shadow DOM कहते हैं, और Firefox को छोड़कर सभी प्रमुख browsers में चलता है। Firefox भी इस पर काम कर रहा है और polyfill भी मौजूद है
    • मैं यह बताना चाहता हूँ कि यह property सामान्य HTML में भी होती है
    • server-rendered shadow DOM को client तक पहुँचाने का एक proposal है। हालांकि long term में यह बचेगा या नहीं, कोई नहीं जानता
      https://developer.chrome.com/articles/declarative-shadow-dom...
      वैसे यह polyfill काफ़ी आसान है, इसलिए browser अभी support न भी करे तो भी शायद इसे इस्तेमाल किया जा सकता है
    • Lit द्वारा दिए गए अच्छे tools के साथ Web Components इस्तेमाल करना मुझे पसंद है, लेकिन मैं सहमत हूँ कि server-side rendering और hydration की कमी के कारण वे Stimulus या Alpine जैसी server-side progressive enhancement libraries की तुलना में कम practical लगते हैं
      अगर server पर render हो सकने वाले Web Components आ जाएँ, तो multi-page apps का user experience बेहतर बनाने की बहुत संभावनाएँ खुलेंगी

  • JS world अब भी पूरी control रखने वाले thick client को लेकर इतना obsessed है कि server world में हो रही दिलचस्प चीज़ें missed हो रही हैं
    Rails Hotwire, Phoenix LiveView, Laravel Livewire जैसे solutions न्यूनतम JS और developer experience complexity लगभग न के बराबर रखते हुए frontend का 80% हल कर सकते हैं

    • क्या यह भी संभव नहीं कि frontend और backend दोनों mature हों और ज़्यादा powerful बनें? क्या हम यही नहीं चाहते?
      मैंने बिना server के database और object storage को read/write करने वाले feature-rich frontend apps भी बनाए हैं। उनकी portability बहुत अच्छी है, और installation step सिर्फ कुछ files upload करना है। वे simple CDN से सीधे चल सकते हैं और बहुत fast होते हैं
      मेरे जानने वाले ज़्यादातर frontend developers भी Hotwire family के बारे में जानते हैं, लेकिन उनके लिए ऐसे stacks developer experience complexity बढ़ाते हैं। कभी-कभी लोग “complexity” कहते हैं, पर असल में उनका मतलब “unfamiliarity” होता है। Frontend और backend दोनों बहुत ज़्यादा complex हो सकते हैं, लेकिन ऐसा होना ज़रूरी नहीं
    • Complexity कहीं न कहीं मौजूद होनी ही है। या तो वह engineer के हाथ में होगी, या framework को magic करने देने के लिए उसे carpet के नीचे बुहार दिया जाएगा। खासकर Rails ecosystem याद आता है
      जब चीज़ें बिगड़ती हैं, तो मेरे हिसाब से ज़्यादा control होना बेहतर है। खासकर उस तेज़ environment में जहाँ client तुरंत मांग करता है कि उसे यह चाहिए
    • या तो JavaScript के अंदर HTML लिखते हैं, या HTML के अंदर JavaScript
      निजी तौर पर, HTML के ऊपर syntax sugar छिड़कने के बजाय मैं सब कुछ JavaScript/TypeScript में लिखना पसंद करूँगा
    • क्या यह वही trade-off space नहीं है जिसे UI की शुरुआत से explore किया जाता रहा है—UI को कितना thin रखना है?
      Livewire की तरह server side में डाल देने से latency जैसी मजबूत कमियाँ गायब नहीं हो जातीं
    • Laravel side पर Inertia के बारे में भी और सीखना चाहता हूँ, लेकिन Laravel developer के तौर पर Livewire, खासकर Filament के साथ, अविश्वसनीय रूप से productive लगता है

  • Title शायद सही होगा, लेकिन यह महत्वपूर्ण है या नहीं, पता नहीं। ज़्यादातर applications इतने लंबे समय तक नहीं टिकते
    हाल ही में Web Components इस्तेमाल किए, और किसी भी framework में बहुत simple functionality भी setup करना सचमुच confusing और complex था। अगर component simple हो तो शायद फ़र्क न पड़े, लेकिन अगर JS में application बना रहे हैं तो slots core feature हैं, क्योंकि वे composable components बनाने देते हैं
    Developer tools में shadow DOM debug करना भी सचमुच confusing था

    • कुछ चीज़ों को MutationObserver या उसके polyfill के बिना ठीक से काम करवाना लगभग असंभव है
      React का renderProp या Vue का scoped slot parent component से child component में data inject करने के लिए बहुत आम तौर पर इस्तेमाल होता है। लेकिन Web Component में वैसा behavior reproduce करना MutationObserver hacks के बिना practically impossible है। Web Component की यह assumption कि child और parent components को एक-दूसरे की जानकारी जानने की ज़रूरत नहीं, real world से मेल नहीं खाती
      यह assumption भी ज़्यादातर frameworks में गलत है कि child component parent से स्वतंत्र रूप से हमेशा load और initialize होता है। ज़्यादातर frameworks में parent component तय करता है कि child को सच में load या initialize करना है या नहीं

  • Web Components अलग-थलग और reusable components लिखने के लिए बेहतर हो सकते हैं, लेकिन application को चलाने के लिए इधर-उधर चीज़ें जोड़ने में इस्तेमाल होने वाला DOM API बस बेहद खराब है
    साफ दिखता है कि इसे XML documents edit करने के लिए बनाया गया था
    अलग-थलग और reusable components के लिए भी Web Components न बनाने की एक और वजह है। कोई भी editor properties या event names की autocomplete, typo checking जैसी चीज़ें ठीक से पकड़कर नहीं देता

  • इन्हें उपयोगी बनाने के लिए कई dependencies को जोड़ना पड़ता है, और वे dependencies शायद React जितनी अच्छी तरह maintain नहीं होंगी
    मैंने एक ऐसी philosophy अपनाने वाली कंपनी में काम किया है। हर UI component एक Web Component था, जिसका अपना npm package install करना पड़ता था। यह ठीक काम करता था, लेकिन इसका कोई फायदा नहीं था। 6 साल बाद भी कोई फायदा नहीं है। शायद यह ऐसे भविष्य के लिए optimize करने जैसा है जो कभी आएगा ही नहीं

  • HTML/CSS sites बाकी सब से ज्यादा समय तक टिकेंगे
    क्योंकि text, images और layout सचमुच static चीज़ के अंदर होते हैं, जिन्हें छुए बिना वे हमेशा रह सकते हैं, और इनके लिए complex code execution या अस्पष्ट और तेजी से बदलते quasi-standards को maintain करने की जरूरत नहीं होती
    अगर आप लंबे समय तक चलने वाली sites बनाना और लंबे समय तक टिकने वाली technology रखना चाहते हैं, तो progressively enhanced HTML websites बनाना सीखें। Web Components की तरह बेकार hyphen वाले undefined HTML elements बनाकर फिर बहुत सारा JavaScript चलाने के बाद उन्हें define करना, या ऐसे JavaScript frameworks जो HTML इस्तेमाल करने का दिखावा भी नहीं करते, सिर्फ कुछ साल ही चलेंगे
    कम-से-कम तब तक तो ऐसा रहेगा जब तक browsers से HTTP/1.1 support हट नहीं जाता

    • मुझे हैरानी है कि Web Components का कौन-सा हिस्सा progressive enhancement की definition में फिट नहीं बैठता
    • मुझे हैरानी है कि article में आपने देखा कि मैंने Web Components कहाँ इस्तेमाल किए हैं। JavaScript के बिना interactive demo वाला tutorial article कैसे बनाया जा सकता है?