वेब कॉम्पोनेंट्स ठीक हैं

 (nolanlawson.com)
2 पॉइंट द्वारा GN⁺ 2024-10-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • वेब कॉम्पोनेंट्स पर बहस सर्वोच्च प्रदर्शन और प्लेटफ़ॉर्म स्टैंडर्ड में से सिर्फ एक चुनने का सवाल नहीं है, और यह मान लेना भी अतिशयोक्ति है कि उन्हें सभी JavaScript frameworks की जगह लेनी चाहिए
  • Custom Elements DOM को interface की तरह इस्तेमाल करते हैं, इसलिए overhead होता है, लेकिन वास्तविक products में performance के साथ maintainability·security·usability·accessibility को भी साथ में परखना चाहिए
  • frameworks के लिए web components support की लागत कुछ सरल checks से संभाली जा सकती है, और सिर्फ standard feature होने से यह ज़रूरी नहीं हो जाता कि हर framework उसे अपनाए
  • web components में server-side rendering (SSR), accessibility, और कुछ interoperability में कमजोरियाँ हैं, इसलिए React·Solid·Svelte जैसे विकल्प कई स्थितियों में अब भी अधिक उपयुक्त हैं
  • Salesforce जैसे environments में, जहाँ client-rendered apps, component marketplace, और लंबी अवधि की backward compatibility महत्वपूर्ण हो, web components एक व्यावहारिक विकल्प बन सकते हैं

बहस की शुरुआत और लेखक की स्थिति

  • हाल की बहस Ryan Carniato के “Web Components Are Not the Future” और Cory LaViska के “Web Components Are Not the Future — They’re the Present” से आगे बढ़ी
  • मुद्दा किसी विरोधी खेमे पर हमला करना नहीं, बल्कि यह देखना है कि अलग-अलग सीमाओं के साथ काम करने वाले developers क्या कोई साझा आधार ढूँढ सकते हैं
  • Ryan Carniato को Solid और js-framework-benchmark में दिखने वाले performance तथा framework design work के लिए बहुत सम्मान दिया जाता है
  • web components का भी framework implementation, component creation, Web Components Community Group, Accessibility Object Model group, और shadow DOM·custom elements·accessibility work से जुड़ा वास्तविक उपयोग-क्षेत्र है

प्रदर्शन: DOM की लागत सच है, पर पूरी कहानी नहीं

  • web components की बुनियादी कमजोरी यह है कि वे Custom Elements पर आधारित हैं
    • हर interface को DOM के रास्ते से गुजरना पड़ता है, इसलिए performance overhead आता है
    • अगर लक्ष्य पूरी तरह सबसे तेज framework बनाना है, तो DOM nodes को जितना हो सके कम करना चाहिए, और इस पैमाने पर web components कमजोर पड़ते हैं
  • लेकिन performance software development का एकमात्र मानदंड नहीं है
    • maintainability, security, usability, और accessibility को भी साथ में देखना चाहिए
    • aria-* attributes render न करने से DOM rendering थोड़ी तेज हो सकती है, लेकिन accessible interface के लिए वे ज़रूरी हो सकते हैं
    • for loop का .forEach() से तेज होना, या var का const/let से तेज होना जैसी micro-optimizations आम तौर पर इतने मूल्यवान नहीं होतीं कि उनके लिए समझौता किया जाए
  • DOM nodes को कम से कम रखना virtualization का मुख्य विचार है
    • सबसे तेज विकल्प न होने पर भी कई बार अधिक सरल approach पर्याप्त होती है
    • components as elements भी optimal नहीं है, लेकिन हर बार optimal होना ज़रूरी नहीं
  • अलग-अलग frameworks से बने custom elements को साथ इस्तेमाल करना भी व्यावहारिक काम में अर्थपूर्ण है
    • हो सकता है Framework A से Framework B में धीरे-धीरे migrate करना हो
    • या कई micro frontends को जोड़ना पड़ता हो
    • यह सबसे तेज interface नहीं होगा, लेकिन ज़रूरी trade-off हो सकता है
  • वास्तविक web performance में layout thrashing, network waterfall, और अनावश्यक re-rendering जैसे कम लागत वाले सुधार बिंदु अधिक आम हैं
    • js-framework-benchmark जैसी प्रतिस्पर्धाएँ framework authors के लिए रोचक हैं, लेकिन सामान्य product स्थितियों में हमेशा निर्णायक नहीं होतीं
    • अगर संसाधन-सीमित environment में हर millisecond महत्वपूर्ण है, तो web components को छोड़ देना भी उचित निर्णय हो सकता है

framework support की लागत और पसंद की स्वतंत्रता

  • यह दावा कि web components support framework authors के लिए अत्यधिक महँगा पड़ता है, लेखक को स्वीकार्य नहीं है
    • props और attributes की पहचान prop in element check से की जा सकती है
    • web components को output करना कष्टदायक हो सकता है, लेकिन यह ऐसा काम नहीं जिसे हर framework को अनिवार्य रूप से करना ही पड़े
    • Vue 2 ने अलग web component wrapper library का उपयोग किया, और Remount React टीम की भागीदारी के बिना भी मौजूद है
  • 2011 के बाद web platform में जुड़ी सुविधाओं को नज़रअंदाज़ करके भी frameworks शानदार बनाए जा सकते हैं
    • jQuery v1 अब भी कई websites पर काम करता है
    • browser performance teams पुराने web developer patterns को optimize करती रहती हैं, इसलिए पुराना code नए browsers में और तेज चल सकता है
  • आधुनिक web platform features अपनाने के फैसले के साथ नए विचार-विमर्श भी आते हैं
    • Symbol, Proxy, Promises जैसी सुविधाएँ भी इसी श्रेणी में आती हैं
    • web की backward compatibility की वजह से लिखा गया code 10 साल बाद भी चलता रह सकता है
  • ऐसे frameworks भी पूरी तरह उचित हैं जिन्हें web components में रुचि नहीं है या जो उन्हें support नहीं करना चाहते
    • पूरा UI web components से बनाया जा सकता है
    • HTML web components को आंशिक रूप से मिलाया जा सकता है
    • या उन्हें बिल्कुल न इस्तेमाल करने का विकल्प भी है
    • “no web components” framework भी अपने प्रशंसक पा सकता है

standard एक reference point है, बाध्यता नहीं

  • जब कोई feature standard बन जाता है, तो developers उसे तुलना के एक मूल आधार के रूप में देखने लगते हैं
    • component author को तय करना पड़ता है कि उसका <slot> native <slot> की तरह काम करना चाहिए या नहीं
    • IntersectionObserver या <img loading="lazy"> का उपयोग करना है, या अपनी abstraction बनानी है, यह भी एक चुनाव है
  • standards साझा reference point और shared vocabulary देते हैं
    • वे अलग-अलग approaches की तुलना और विरोधाभास समझने का आधार बनाते हैं
    • लेकिन सिर्फ standard होने से किसी चीज़ का इस्तेमाल अनिवार्य नहीं हो जाता
  • web पर ऐसे features और पुराने APIs साथ-साथ मौजूद हैं जिन्हें इस्तेमाल करना आवश्यक नहीं
    • document.domain, with, <frame> जैसे deprecated APIs अब भी supported हैं
    • web platform की सुविधाओं को चुना भी जा सकता है और छोड़ा भी जा सकता है

कहाँ web components सही हैं और कहाँ नहीं

  • web components बहुत-सी चीज़ें अच्छी तरह करते हैं, लेकिन वे सभी JavaScript frameworks को बदल देने वाला औज़ार नहीं हैं
  • उनकी कमजोरियों में server-side rendering (SSR), accessibility, और कुछ interoperability शामिल हैं
  • अब भी कई स्थितियाँ ऐसी हैं जहाँ React, Solid, Svelte जैसे frameworks बेहतर चमकते हैं
  • “web components भविष्य नहीं हैं” जैसी बात कुछ developers या projects के लिए सही हो सकती है
  • इस बहस की जड़ में यह तथ्य है कि अलग-अलग लोग अलग-अलग सीमाओं के भीतर अलग चीज़ें बना रहे हैं

Salesforce का उदाहरण और व्यावहारिक निर्णय

  • Salesforce दिखाता है कि किन environments में web components अच्छा विकल्प हो सकते हैं
    • यह client-rendered apps बनाता है
    • इसका अपना component marketplace है
    • इसे कड़ी backward compatibility guarantee की आवश्यकता है
    • support अवधि कई वर्षों, और कुछ मामलों में दशकों में मापी जाती है
  • अगर ये शर्तें लागू नहीं होतीं, तो पूरे UI को web components, shadow DOM, और उससे जुड़ी पूरी संरचना में बनाना आवश्यक नहीं हो सकता
  • web platform पर WebGL, Wasm, Service Workers जैसी विविध तकनीकों से बने games, art projects, और enterprise SaaS apps साथ-साथ मौजूद हैं
  • platform में नई सुविधाएँ जुड़ने से रचनात्मकता सीमित नहीं होती, बल्कि ऐसे अभिव्यक्ति-मार्ग खुलते हैं जिनकी पहले कल्पना भी नहीं की गई थी
  • साथ पढ़ने लायक लेखों में Lea Verou का लेख और Baldur Bjarnason का लेख भी शामिल हैं

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

1 टिप्पणियां

 
GN⁺ 2024-10-01
Hacker News की राय

  • संदर्भित लेख “Web Components Are Not the Future” को समझने की कोशिश की, लेकिन बहुत ज़्यादा भरोसेमंद तर्क नहीं मिले
    आज के frontend framework की हालत गड़बड़ है, और मैं ऐसे जटिल framework या ऐसी magic (useState, createSignal आदि) सीखना नहीं चाहता जिसे docs पढ़े बिना समझा न जा सके
    Web Components से शुरुआत करने पर यह सहज लगता है, और Shadow DOM isolation जैसी क्षमताएं भी मिलती हैं जो कहीं और नहीं हैं
    React युग से बचाकर रखने लायक चीज़ सिर्फ JSX है, ऐसा मानते हुए Web Components को JSX के साथ इस्तेमाल करने वाली एक library बनाई: https://webjsx.org

    • “मैं जटिल framework सीखना नहीं चाहता” वाले वाक्य में कई बातें मिली हुई हैं, इसलिए उसे समझना मुश्किल है
      क्या framework खुद सीखना नहीं चाहते, या कुछ ऐसा चाहते हैं जो सीखने की ज़रूरत न पड़े इतना magic जैसा लगे, या docs पढ़ना चाहते हैं या नहीं—यह अस्पष्ट है
      मैंने मुख्यतः Vue इस्तेमाल किया है, और SPA ecosystem जटिल है, लेकिन जटिल state वाले client app को manage करने के लिए और कौन-सा system संभव है, यह भी ठीक से नहीं पता
    • UI के बारे में सोचने के तरीके में भी फर्क है
      jQuery का basic pattern element चुनकर उसे बदलने वाला side-effect centric तरीका है, जबकि React या Vue.js आपको ऐसे components बनाने देते हैं जिनमें UI state data से तय होती है
      Data बदलने पर कम-से-कम DOM बदलावों से update होता है, और यह तरीका location के हिसाब से UI widget को कहीं ज़्यादा readable और maintainable बनाता है
      आज की websites और web-based desktop apps 20 साल पहले की तुलना में कहीं ज़्यादा जटिल हैं, इसलिए अगर सिर्फ simple UI नहीं बनाना है तो state management के लिहाज़ से innovation अहम है
    • React app लिखने के लिए यह जानना ज़रूरी नहीं कि useState अंदर से कैसे काम करता है, और इसे apply करने का तरीका काफ़ी intuitive है
      इसके उलट, पेश की गई library शुरुआत से ही ज़्यादा जटिल mental model मांगती हुई लगती है
      framework की details को गहराई से समझना ideal तो है, लेकिन React इस मायने में सफल रहा है कि internal model लगभग न जानते हुए भी काफ़ी sophisticated apps बनाए जा सकते हैं
    • Angular इतना मुश्किल नहीं था, और करीब एक हफ्ते में इतना सीख लिया जा सकता था कि जटिल site बना सकें या ठीक-ठाक PR दे सकें
      शायद इसलिए भी कि मैं C# beta के समय से और HTML/JS/CSS के शुरुआती दौर से developer रहा हूं, लेकिन यह जल्दी समझ में आ गया
      पुराने और जटिल core infrastructure management portal को replace करते समय Angular चुना, और यह stable, fast और अच्छा दिखने वाला था; सभी संतुष्ट थे
      “steep learning curve” मुख्यतः उन developers से आता दिखता है जो सिर्फ JavaScript और थोड़ा-सा React जानकर industry में आए हैं; ज़्यादा experience हो तो इसे तुरंत सीखा जा सकता है
    • अगर कोई developer useState के अंदरूनी हिस्से को लेकर उत्सुक है, तो कुछ सेकंड में logical और सही जवाब तक पहुंच सकता है
      यह complex या magic नहीं है, और React hook जैसा minimal implementation कुछ सौ lines में संभव है
      basic useState और runFunctionComponent implementation university computer science के तीसरे semester के ज़्यादातर assignments से आसान है
      अगर यही magic का standard है, तो हमारे आसपास breakfast करते-करते नए Eldritch Invocation बना देने वाले level 20 Warlocks भरे पड़े हैं

  • मुझे लगता है इस debate में लोगों के एक-दूसरे से चूकने की एक वजह यह है कि वे अलग-अलग चीज़ों को optimize कर रहे हैं
    VC-funded startup में अगर तेज़ी से आगे बढ़ते हुए ऐसा core product बनाना है जिसे लगातार maintain किया जाएगा, तो framework सही बैठ सकता है
    लेकिन academic lab में पहले से बने app को maintain करने के लिए बहुत पैसा नहीं होता, और grant नए project पर जाने के बाद भी उसे चलता रहना चाहिए
    एक Vue app को Web Components में फिर से लिखने का काम लगभग पूरा कर लिया है, क्योंकि dependencies सड़ चुकी थीं और update करना नामुमकिन था
    पहले dependency hell ठीक करने में समय लगता था और आगे भी यही होता, लेकिन Web Components को experiment करके देखा तो तुरंत अच्छा लगा और switch कर लिया
    dependencies करीब 15 से घटकर करीब 1 (d3js) रह गईं, और कोई पछतावा नहीं
    पुराना app https://bam.iobio.io/, नया app https://bam2.iobio.io/

    • यह logic कभी-कभी समझना मुश्किल होता है
      कोई भी framework को हमेशा latest version पर upgrade करने के लिए मजबूर नहीं करता, इसलिए जिस Vue version का इस्तेमाल हो रहा था उसी पर रहना भी संभव था
      कोई खास वजह न हो तो अंत तक वही version इस्तेमाल करना भी ठीक हो सकता था
      इसका मतलब यह नहीं कि उस use case में Vue की ज़रूरत नहीं थी या dependencies हटाना गलत choice था, लेकिन अगर Vue पसंद था तो latest version पर बने रहने की कोई मजबूरी नहीं दिखती
    • अगर d3js छोड़कर बाकी dependencies हटाई जा सकती थीं, तो क्या वही काम करते हुए Vue dependency भी रखी नहीं जा सकती थी
      सोच रहा हूं कि Vue को extra dependencies की ज़रूरत build system की वजह से पड़ती है या नहीं
    • familiar हो जाने पर Web Components development किसी भी framework से धीमा नहीं होगा, ऐसा लगता है
      इसलिए समझ नहीं आता कि VC ecosystem framework के बिना क्यों नहीं चल सकता
    • यह मानना मुश्किल है कि सारे Web Components हाथ से लिखे जा रहे हैं, और यह भी मानना मुश्किल है कि कोई external dependency बिल्कुल नहीं है

  • Svelte में Custom Elements API के ज़रिए Web Components generate करने का support है, यह बात अच्छी लगती है
    Svelte सामान्य JS/HTML/CSS में compile होता है, इसलिए किसी भी framework या vanilla JS में काम करने वाले reusable components बनाना natural है: https://svelte.dev/docs/custom-elements-api

    • Rich भी मानते हैं कि यह Svelte का top-priority goal नहीं है, इसलिए अगर reality promise से कम निकले तो हैरानी की बात नहीं
    • Vue भी यह feature देता है: https://vuejs.org/guide/extras/web-components

  • Web Components पर चर्चा को कई सालों से follow कर रहा हूँ, लेकिन एक full-stack developer के तौर पर यह अभी तक ठीक से समझ नहीं आया कि यह मेरी ज़िंदगी बेहतर बनाने के लिए क्या कर सकता है
    ये examples ज़्यादातर data को HTML में template के रूप में डालने भर के थे, और वह काम तो पहले से ही handlebars से किया जा सकता है
    क्या मैं कुछ miss कर रहा हूँ

    • “web” में एक model है जो HTML को document के रूप में देखता है, और दूसरा model है जो HTML को किसी अधिक जटिल app के scene graph के रूप में देखता है
      अगर आप HTML को document की तरह इस्तेमाल करते हैं, तो Web Components से ज़्यादा शानदार real-time interaction features जोड़े जा सकते हैं
      WebSocket से जुड़ने वाला terminal emulator, date picker, custom form elements, maps, data tables, tab widgets, और पुराने jquery-ui द्वारा दिए जाने वाले custom components इसके examples हैं
      Web Components के बिना भी यह संभव है, लेकिन custom component के रूप में बनाने पर HTML कहीं ज़्यादा साफ़ और document-जैसा बना रहता है
      एक consistent Web Components library हो तो अच्छा होगा, और HTMX व server-sent events से भी काफी अच्छा real-time chat संभव लगता है
    • पूरी तरह native isolation संभव है
      HTML, CSS, JS सबको browser बिना किसी अलग hack के isolate कर देता है
      Web Component बनाकर JS, HTML, CSS API को variables के आधार पर स्पष्ट रूप से define करने के बाद उसे किसी भी environment में डालें तो वह टूटता नहीं, या जटिल CSS namespace और framework dependency की भूलभुलैया बनाने की ज़रूरत नहीं पड़ती—यह अच्छी बात है
    • यह progressive enhancement के लिए बहुत अच्छा है
      उदाहरण के लिए, table को wrap करने वाले Web Component से filtering या drag-and-drop sorting जैसी functionality जोड़ी जा सकती है, और JS बंद हो या load fail हो जाए तो भी user को basic table और content मिलता है
      पहले यह frontend framework की white screen से कहीं बेहतर था, लेकिन अब server-side rendering व्यापक रूप से उपलब्ध हो गई है, इसलिए फायदा कुछ कम हो गया है
      style encapsulation भी अच्छा है, लेकिन आजकल headless UI libraries और frameworks के scoped styles आम हो गए हैं, इसलिए 10 साल पहले जितना ज़रूरी नहीं लगता
      हालांकि slots इस्तेमाल करने के लिए Shadow DOM चुनना पड़ता है, इसलिए अपने reusable components बनाते समय page में एक stylesheet डालकर styling न कर पाना irritate करता है
    • examples dynamic API से बचते हैं, शायद इसलिए कि वह हिस्सा बहुत बदसूरत है और उसमें बहुत state होती है
      अगर demo manual DOM adjustment की 200 lines दिखाए, तो Web Components को future कहना मुश्किल है
    • Web Components दूसरे frameworks में बने UI components को मेरे framework में इस्तेमाल करने देते हैं
      बस यही है, और ज़्यादातर दूसरे use cases के लिए यह काफी खराब है
      साथ ही UI component को 7 versions में बनाए बिना सभी frameworks में काम करने लायक publish किया जा सकता है

  • Web Components और Shadow DOM का सबसे खराब हिस्सा यह है कि वे browser extensions को ठीक से काम न करने, या बिल्कुल काम न कर पाने की स्थिति में डाल सकते हैं
    browser vendors भी इस स्थिति को ठीक करने की जल्दी में नहीं हैं

    • user agent की configurability web का killer feature है

  • Web Components की सबसे बड़ी “गलतियों” में से एक, मेरे हिसाब से, यह है कि लोगों के दिमाग में इसे Shadow DOM के साथ जोड़ दिया गया
    app development में live DOM पर टिके रहें तो Web Components बहुत हल्का और आसान विकल्प बन जाता है
    bootstrap, tailwind जैसे पसंदीदा CSS tools इस्तेमाल करते रहते हुए भी लगभग बिना cost के शानदार functional encapsulation मिल सकता है, और renderer के तौर पर lit-html जैसी चीज़ इस्तेमाल करें तो यह खास तौर पर अच्छा है
    teams को native Web Components पर काम करना आम तौर पर fresh लगा, और framework दुनिया से आए developers ने लगभग एक हफ्ते के adjustment के बाद वापस जाना नहीं चाहा
    simple class properties और set() में render function को manually call करने भर से framework की झंझट के बिना reactivity के फायदे मिल जाते हैं
    समस्या यह है कि “easy mode” से शुरू करने का तरीका दिखाने वाले resources बहुत कम हैं
    ज़्यादातर beginner resources app developers के बजाय library authors के लिए बने Shadow DOM, CSS parts जैसी दर्दनाक technologies में सीधे धकेल देते हैं
    लगता है Web Components से ज़िंदगी आसान बनाने वाली “The Good Parts” जैसी guide लिखनी चाहिए

    • Shadow DOM रोज़ इस्तेमाल करता हूँ, लेकिन Web Components में लोगों को सबसे ज़्यादा confuse करने वाला हिस्सा भी आम तौर पर यही होता है। शायद इसलिए कि इसकी ज़रूरत नहीं होती
      alternative के तौर पर “HTML web components” हैं, जो सिर्फ live DOM इस्तेमाल करते हैं, server-side rendering-first हैं और “jQuery seasoning” के replacement के लिए अच्छे हैं: https://adactio.com/journal/20618
      और “Shadow gristle” भी है, जो Shadow DOM को जितना हो सके उतना कम इस्तेमाल करता है, और styling या composition चाहिए तो उसे live DOM में रखता है: https://glazkov.com/2023/03/02/shadow-gristle/
    • अगर इस पर लिखें तो पढ़ना चाहूँगा। सुनना भी अच्छा लगेगा
      यह technology इस्तेमाल करने के तरीके के हिसाब से आशीर्वाद और अभिशाप दोनों लगती है, इसलिए इससे जुड़े resources और comments इकट्ठा कर रहा हूँ
    • पिछली नौकरी में हमने यही stack इस्तेमाल किया था, यानी Shadow DOM के बिना WC और सिर्फ lit-html, और यह बहुत अच्छा था
      सबसे अच्छी बात यह थी कि हर दूसरे हफ्ते dependency hell में नहीं फँसना पड़ता था
    • बिल्कुल वही बात है। अभी जो missing है, वह light DOM के लिए slots हैं

  • interoperability यूज़र के नज़रिए से सबसे बड़ा फ़ायदा है, लेकिन लगता है कि इसके बदले हर इस्तेमाल किए गए component के साथ अनावश्यक runtime आ सकता है, जिससे performance cost पैदा होती है—इस बात को कम आंका जा रहा है
    Web Components के साथ Lit जैसे framework का इस्तेमाल recommended तरीका है, और समय के साथ नए framework आते हैं और components पुराने versions से बंध जाते हैं, तो यह cost जमा होती जाती है
    एक ही page पर कई duplicate libraries रखने वाली दिशा किसी को भी recommend नहीं करना चाहूंगा, और अगर यह best practice में शामिल है तो लंबी अवधि में अच्छा नहीं है
    Web Components समर्थकों के लेख, social media और videos मैंने कई साल देखे हैं, और मुझे ही उनका target user होना चाहिए, लेकिन interoperability tax के ऊपर मुख्यधारा frameworks में न मिलने वाली कमियों से यह भरा है
    हर framework ecosystem के अंदर interoperability अच्छी तरह काम करती है, और developers को interoperability खोजने के लिए प्रेरित करने वाली वही dynamics उन्हें कुछ मुख्यधारा frameworks के आसपास इकट्ठा कर देती है
    मुझे लगता है Web Components तकनीकी रूप से पीछे रह जाते हैं, और 2010 के शुरुआती दशक के design के लिए web platform में बहुत complexity जोड़ते हैं: https://x.com/Rich_Harris/status/1840116730716119356

    • दूसरे लेख में इसे कवर किया था, लेकिन मोटे तौर पर देखें तो हर web app अतिरिक्त kB के प्रति performance-sensitive नहीं होता। e-commerce होता है, पर productivity tools आम तौर पर नहीं होते
      Svelte जैसे छोटे runtime वाले framework भी बहुत हैं, और 100 को एक page पर डालने की बात नहीं है, लेकिन 5–6 तक ठीक लगते हैं
      इसका मतलब यह नहीं कि यह ideal है, लेकिन gradual migration या micro frontends में मदद कर सकता है
      संदर्भ के लिए, React 17 ने भी एक ही page पर कई React versions रखने की क्षमता जोड़ी थी: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/, https://bundlephobia.com/package/svelte@4.2.19, https://legacy.reactjs.org/blog/2020/10/20/react-v17.html
    • बात सही है, लेकिन आजकल बनने वाले ज़्यादातर web apps को देखें तो कई libraries की समस्या rounding error जैसी लगती है
      React और react-dom मिलाकर 100KB से ज़्यादा हैं, और Svelte व Lit single-digit KB में हैं
      लोग रोज़ बिना सोचे-समझे जितना bloat इस्तेमाल करते हैं, उसके करीब पहुँचने के लिए काफ़ी सारे frameworks डालने पड़ेंगे
    • और व्यापक रूप से देखें तो Web Components को framework authors को मनाना होगा
      अब तक लगातार दिखे संकेत अच्छे नहीं हैं, और वह community X पर है; Web Components उनकी समस्याएँ हल नहीं करते और best-case में भी अच्छे से इस्तेमाल नहीं होते
      उम्मीद है वे मनाने में सफल हों, लेकिन वे आम तौर पर कहते हैं कि Web Components failed रहे और कुल मिलाकर web के लिए खराब थे
    • यह दावा सच कहूँ तो अच्छी तरह समझ नहीं आता
      ज़्यादातर runtimes काफ़ी छोटे होते हैं, और दो runtimes साथ चलने से performance overhead बड़ा नहीं हो जाता
      सभी modern web frameworks reactive हैं, इसलिए respond करने को कुछ न हो तो वे कुछ नहीं करते
      अगर page का एक हिस्सा React से, दूसरा Lit से, और तीसरा Svelte से बना हो, तो user experience या battery consumption किसी single-framework page से स्पष्ट रूप से खराब क्यों होगा, यह समझ नहीं आता
      जिस tweet को quote किया गया है वह इस बारे में है कि Web Components “framework बनाने के लिए उपयोगी primitive elements” हैं या नहीं, और जिन्हें इन्हें सच में इस्तेमाल करने का experience है वे fans भी आम तौर पर ऐसा नहीं कहेंगे
      Web Components एक distribution mechanism हैं, और अगर alternative सिर्फ़ यही है कि वही library React, Preact, Svelte, Solid, Vue और vanilla JS के लिए 7 बार बनाई जाए, तो वह बेहद खराब है

  • मुझे Web Components पसंद हैं, और मैं optimistic हूँ कि ये हमें हमारे खुद बनाए हुए मौजूदा frontend hell से बाहर निकाल सकते हैं
    हाल ही में frontend के भविष्य पर एक छोटी presentation दी थी, और लगा कि दूसरे लोग भी निकलने का रास्ता उम्मीद कर रहे हैं
    DB GUI के लिए data table बनाया, और लाखों rows load करने पर भी scrolling बहुत smooth है
    Web Component library भी जल्द release करने वाला हूँ; अभी शुरुआती और rough है, लेकिन अच्छा होगा अगर ज़्यादा लोग देखें: www.astra-ui.com

    • मुझे लगता है मौजूदा frontend hell से निकलने का इकलौता रास्ता client-side import का आना है: https://github.com/whatwg/html/issues/2791
    • docs देखे, और iPhone 15 Pro Max के Safari 18.0 में rendering बहुत अजीब है
      छोटे screens के लिए responsive design को ध्यान में रखते हुए sidebar को reposition करना, और body पर width के बजाय max-width रखना बेहतर होगा
      homepage के नीचे वाला “explore components” button कहीं भी link होता नहीं दिखता
      कहा गया है “अच्छी तरह structured और accessible component implementations से सीखें,” लेकिन docs में implementation link नहीं मिला
      कहा गया है “manage या update करने के लिए कोई dependency नहीं,” लेकिन astra-ui खुद dependency नहीं है क्या, ऐसा लगता है; और changelog भी है: https://www.astra-ui.com/changes/
      यह भी कहा गया है कि “code और styling पर पूरा control” है, लेकिन library द्वारा दी गई implementation पर निर्भर रहते हुए पूरा control कैसे संभव है, यह समझ नहीं आता
      उत्सुकता है कि इस library को public करने का फैसला क्यों लिया। internal software को open source करना तब उपयोगी होता है जब company का कोई खास goal हो, लेकिन आम तौर पर यह बिना reward वाला time sink बनना आसान है
      component libraries को ecosystem adoption के लिए लड़ना पड़ता है; वरना audience न होने से public करने की वजह कम रह जाती है
    • Vue components जैसी चीज़ की जगह इसे इस्तेमाल करने की वजह क्या होगी
    • Web Components अब तक स्थापित क्यों नहीं हुए या ज़्यादा व्यापक रूप से क्यों इस्तेमाल नहीं हो रहे
      यह शानदार समाधान जैसा दिखता है
    • company के frontend ad code को Web Components में फिर से लिखा

  • कुछ महीने पहले नई नौकरी में मुझे लगभग 2.5 लाख लाइनों वाला JS codebase विरासत में मिला
    एक विशाल class और कुछ subclasses ही सब कुछ कर रही थीं, और एक file तो 30 हजार लाइनों की थी
    कोई framework नहीं था, कोई reactivity नहीं थी, इसलिए button click करने पर event listener के जरिए screen की हर चीज़ को manually update करना पड़ता था
    code ऐसा था जैसे किसी ने सिर्फ़ एक basic JavaScript किताब लेकर मठ की कोठरी में कई साल बंद रहकर लिखा हो
    चूँकि काम धीरे-धीरे करना था, इसलिए मैंने Web Components के साथ refactoring शुरू की, इससे बहुत मदद मिली और अब तक 50 हजार lines कम हो चुकी हैं
    हालांकि असली मकसद rewrite करने से पहले यह सब सीखना था कि मौजूदा code करता क्या है

    • पुराने और उलझे हुए codebase को समझने की कुंजी है एक बार में छोटे-छोटे हिस्से refactor करना
      Web Components के साथ दोबारा बनाना उस लक्ष्य को हासिल करने का एक तरीका है, और अच्छी बात यह है कि सब कुछ फेंककर नए सिरे से शुरू नहीं किया गया
      हालांकि कुछ हद तक आगे बढ़ने के बाद अगर आप किसी दूसरे project में चले जाएँ, तो जोखिम है कि अगला व्यक्ति आएगा और अपने style में refactoring शुरू कर देगा, जिससे तीन अलग-अलग styles वाला उलझा codebase बन जाएगा
      फिर भी यह 2.5 लाख lines को एक साथ दोबारा लिखने से बेहतर है

  • Web Components में मुझे जो एक बात अच्छी लगी, वह यह है कि कम-से-कम theory में यह JS disabled state में भी काम कर सकता है
    progressive enhancement के लिए मैंने कुछ बार ऐसा किया है
    कुल मिलाकर Nolan की बात से सहमत हूँ। Web Components में अभी भी rough edges काफी हैं, इसलिए मौजूदा हालत में इसका दुनिया पर छा जाना मुश्किल है, लेकिन कुछ खास use cases में यह काफी अच्छा है
    हालांकि यह बात मुझे ठीक से समझ नहीं आती कि यह server-side rendering के साथ अच्छी तरह fit नहीं होता, मैंने तो इसे बिना समस्या किया है

    • जानना चाहूँगा कि आप ऐसा क्यों कह रहे हैं
      जहाँ तक मैंने देखा है, किसी खास tag पर template register करने के लिए JavaScript की ज़रूरत लगती है: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots
    • मुझे समझ नहीं आता कि यह कैसे काम करना चाहिए
      ReactJS में component या template को server render किया जा सकता है, और मेरे हिसाब से JSX काफी अच्छा template language है
      मेरी समझ में Web Components में built-in अच्छा template language नहीं है, इसलिए आपको अपना लाना पड़ता है
      मैं ऐसा कोई standard mechanism नहीं जानता जो tag से जुड़े JS component piece को लेकर, JS चलाए बिना आवश्यक HTML render कर सके
    • मैं लेखक हूँ। मैंने दूसरे लेख में इसे cover किया था, लेकिन मूल रूप से client पर मिलने वाले interoperability advantages server पर अभी नहीं हैं
      अगर भविष्य में server पर 3 अलग-अलग Web Component frameworks render किए जा सकें, वे आपस में compose हों, और cleanly hydrate हों, तो इसे solve हुआ माना जा सकता है: https://nolanlawson.com/2023/08/23/use-web-components-for-what-theyre-good-at/