Lit - तेज़ और हल्के web components लिखने के लिए लाइब्रेरी

• web component standards पर आधारित, इसमें reactivity, declarative templates, और बहुत कम boilerplate जोड़ा गया है
• लगभग 5KB का छोटा आकार और तेज़ rendering; UI के केवल बदले हुए हिस्सों को update करके performance और loading speed को optimize करता है
• सभी Lit components native web components हैं, इसलिए framework से स्वतंत्र रूप से जहाँ भी HTML इस्तेमाल हो सकता है वहाँ दोबारा उपयोग किए जा सकते हैं
• Shadow DOM का उपयोग कर डिफ़ॉल्ट रूप से style scope को सीमित करता है, जिससे CSS selectors सरल होते हैं और दूसरे styles के साथ टकराव रुकता है
• Reactive Property के जरिए component API और internal state को model करता है, और property बदलने पर efficient re-rendering को support करता है
• Tagged template Literals आधारित templates की वजह से यह तेज़ और सरल है
• shared components, design systems, vendor dependency कम करने, और maintainability बेहतर बनाने वाले full app build तक, कई तरह के web projects में इस्तेमाल किया जा सकता है
• ट्यूटोरियल उपलब्ध
• GitHub

[devstudyman7]

मुझे 3 साल पहले से ऐसा लग रहा है, लेकिन vanilla web components को सीधे इस्तेमाल करने के लिए यह तेज़ है और एक transitional framework जैसा महसूस होता है, फिर भी धीमा..

[cnaa97]

इसका क्या मतलब है?

[bluemir]

हम web standards के web component और lit-html का ही इस्तेमाल करके operations tools विकसित कर रहे हैं, और यह अच्छा लगता है क्योंकि जानने वाली जानकारी न्यूनतम रहती है। lit-html में हम जिन फीचर्स का उपयोग करते हैं, वे लगभग सिर्फ event handler binding और loop templating तक सीमित हैं। (बाकी के लिए web standards ही काफी हैं..) बदलाव होने पर render को सीधे कॉल करना पड़ता है, यह थोड़ा असुविधाजनक है, लेकिन अपने-आप variable changes को पकड़कर अप्रत्यक्ष रूप से काम होने देने की बजाय, explicit call कुछ मामलों में मददगार भी होती है। चूंकि ये operations tools हैं, अलग-अलग environments को सपोर्ट करना कम प्राथमिकता है, इसलिए शायद मुझे ऐसा महसूस हुआ हो।

[GN⁺]

Hacker News राय

• मैंने कंपनी प्रोजेक्ट में Lit इस्तेमाल किया था, लेकिन अब नहीं करता, और सच में अब काफी सुकून है
  हम पहले से ही एक भारी framework इस्तेमाल कर रहे थे, और किसी ने शायद अपने resume में एक लाइन और जोड़ने के लिए Lit जोड़ दिया, जो बड़ा बोझ बन गया
  Shadow DOM ने खासकर accessibility (A11y) की समस्याओं को और गंभीर बना दिया
  id scope अलग हो जाने से label-for, describe-by जैसी लिंकिंग टूट जाती थी, और इससे बहुत परेशानी हुई
  बेशक, कुछ हद तक यह हमारी टीम की skill की कमी की समस्या भी थी
  • React codebase में web components को integrate करना सच में बहुत मुश्किल था. यह Lit की वजह से कम, और web components की वजह से ज़्यादा लगा
    styles scope हो जाते हैं, लेकिन font size जैसी अहम चीज़ें अपवाद रहती हैं, इसलिए हर replacement के साथ छोटे-छोटे regression bugs आते रहे
    DX भी काफी खराब हुआ, tooling के बेहतर होने की उम्मीद है, लेकिन अभी के लिए यह बस थकाने वाला अनुभव है
  • Lit में Shadow DOM optional है, इसलिए इसे component स्तर पर disable किया जा सकता है
  • यह सवाल भी है कि क्या लोग सच में सिर्फ resume भरने के लिए technology अपनाते हैं.
    असल में, अक्सर लोग बस कुछ नया try करना चाहते हैं, और बिना ज़्यादा तर्क के उसे अपना लेते हैं
• मैंने Lit के लिए एक state management library खुद बनाई थी (258 lines, https://github.com/gitaarik/lit-state)
  यह complex apps में nested components के interaction के साथ अच्छी चली, और React जैसी होने के बावजूद कहीं ज़्यादा browser-native है, boilerplate कम है, और rendering भी तेज़ है
  मुझे समझ नहीं आता कि Lit ज़्यादा popular क्यों नहीं है
  • मैंने भी Lit के अंदरूनी कामकाज को समझने के लिए इसे basics से दोबारा implement किया था
    इसकी core functionality हैरानी की बात है कि काफी simple है, और ज़्यादातर platform APIs पर निर्भर करती है
    इसलिए कोई भी इसे खुद implement कर सकता है, और मुझे लगता है कि यही simplicity इसकी बड़ी value है
    संदर्भ के लिए, मेरा alternative implementation यह है: https://github.com/ruphin/lite-html
• मैं Lit का maintainer हूँ. आज यह अचानक HN front page पर क्यों आया, पता नहीं, लेकिन सवाल हों तो जवाब दे सकता हूँ
  • lit-html सच में बहुत उपयोगी है, इसलिए मैं इसे लगभग हर personal project में इस्तेमाल करता हूँ
    इसे CDN से सीधे लोड करके बिना build step के experiment करना भी इसकी बड़ी ताकत है
    यह दूसरे frameworks की तरह भारी नहीं है, और बस Vanilla JS + HTML लिखने जैसा महसूस होता है, इसलिए cognitive load बहुत कम है
  • Shadow DOM पर बहुत बात हो रही है, तो मैंने अपने विचार समेटे हैं
    Shadow DOM मूल रूप से component के अंदर के DOM को अलग करने वाला एक private tree है
    इससे slot का कॉन्सेप्ट संभव होता है, और सच में composable components बनाए जा सकते हैं
    समस्या यह है कि style encapsulation मौजूदा systems के साथ integrate करते समय बड़ा अवरोध बन जाती है
    इसलिए मैंने Open Styleable Shadow Roots नाम का एक proposal दिया है, जिसमें बाहरी styles अंदर तक flow कर सकें, जबकि slots बने रहें. अभी browser vendors को मनाने की कोशिश चल रही है
  • Lit एक साफ-सुथरा tool है जो रास्ते में नहीं आता, इसलिए मैं अपने सभी personal/work apps Lit से बनाता हूँ
    इस बारे में मेरा एक लेख भी है: https://medium.com/gitconnected/getting-started-with-web-com...
  • Lit की वजह से simple cases हों या complex, development मज़ेदार रहता है
    कभी-कभी सोचता हूँ कि यह और ज़्यादा widely used क्यों नहीं है
  • यह भी सवाल है कि क्या Web Components standard में Lit जैसी functionality शामिल हो सकती है
    • Web Components native होने की वजह से अच्छे हैं, लेकिन उनमें reactivity की कमी है, इसलिए adoption धीमा है
    • Lit उस gap को भरने वाला एक natural extension है
• मैंने Converse.js नाम के XMPP chat client project में Lit इस्तेमाल किया था
  यह पहले Backbone.js पर आधारित था, और हमने इसे lit-html → lit-element → lit के क्रम में धीरे-धीरे replace किया
  अब यह <converse-root /> नाम के web component के रूप में दिया जाता है, इसलिए React जैसे दूसरे frameworks के साथ भी अच्छी तरह integrate हो जाता है
  GitHub: https://github.com/conversejs/converse.js / demo: https://chat.conversejs.org/
• आजकल मुझे लगता है कि Lit की ज़रूरत नहीं है. बस pure Web Components के साथ काम करना ज़्यादा आसान है
  अगर server पर JSX जैसे template system का इस्तेमाल हो, तो अनुभव काफी अच्छा रहता है, और client side पर बस JS होने से upgrade की चिंता भी नहीं रहती
  • Web Components की खूबी यह है कि आप इन्हें अपनी पसंद के तरीके से बना सकते हैं
    लेकिन native APIs बहुत low-level हैं, इसलिए DX कमज़ोर है, और Lit उसके ऊपर declarative reactivity जोड़ देता है
  • मुझे लगता है Lit बार-बार होने वाले `` हैंडलिंग और DOM wiring को अच्छी तरह abstract कर देता है
    जिन चीज़ों को खुद implement करना झंझट होता, उन्हें यह साफ तरीके से संभाल देता है
  • व्यक्तिगत रूप से, मुझे Lit के html template literal और JSX के बीच कोई बहुत बड़ा अंतर महसूस नहीं हुआ
    बल्कि JSX में compile step चाहिए, इसलिए वह और झंझट वाला लगता है
• मैं 3 साल से production में Lit इस्तेमाल कर रहा हूँ. मुझे लगता है कि यह Web Components API के ऊपर सबसे अच्छी abstraction layer है
  • मेरा अनुभव भी कुछ ऐसा ही है
    शुरू में मैंने dependency-free environment में खुद Web Components बनाए थे, लेकिन बाद में LitElement पर आने के बाद चीज़ें काफी आसान हो गईं
    हालांकि Shadow DOM default है, लेकिन कई बार वह उल्टा और समस्याएँ पैदा करता है, इसलिए अब मैं Shadow DOM के बिना LitElement इस्तेमाल करता हूँ
• मैं 2020 से production में Lit इस्तेमाल कर रहा हूँ, और मुझे बिल्कुल पछतावा नहीं है
  इसकी सबसे बड़ी ताकत यह है कि यह एक stable foundation पर खड़ा है
  native Web Components सभी browsers में स्थिर रूप से supported हैं, इसलिए framework बदलने के जोखिम के बिना development पर ध्यान दिया जा सकता है
  काश ज़्यादा teams इसे आज़माएँ
  वैसे Lit पर HTTP 203 वीडियो भी recommend करूँगा
• frontend काम में Lit सच में एक जीवनरक्षक जैसा रहा
  Angular बहुत भारी है, और React ऐसा लगता है जैसे पुराने browsers की सीमाओं को ध्यान में रखकर बनाया गया था, और अब बस inertia की वजह से बचा हुआ है
  • आप किन पुराने browser features की बात कर रहे हैं, यह थोड़ा और specific सुनना चाहूँगा
  • मुझे Aurelia framework पसंद है, क्योंकि यह standards को अच्छी तरह follow करता है और इसका code भी concise है
    Angular के boilerplate या React hooks की complexity के मुकाबले यह कहीं ज़्यादा intuitive है
    बस अफसोस है कि इसे popularity नहीं मिली
  • जब यह बात आई कि React पुराने browser support की वजह से मशहूर हुआ, तो अचानक मुझे लगा कि मैं बूढ़ा हो गया हूँ
• मुझे standalone rendering library के रूप में lit-html पसंद है, लेकिन पूरे Lit की ज़रूरत कभी महसूस नहीं हुई
  असल में मुझे लगता है कि + Web Components का combination ही काफी है
• मैं Vue 3 के एक बड़े project में बने components को दूसरी sites पर reuse करने के लिए web components के रूप में ship करना चाहता हूँ
  लेकिन सोच रहा हूँ कि Vue की जगह Lit में उन्हें दोबारा बनाने का क्या फायदा होगा
  • मैंने Vue और Lit दोनों इस्तेमाल किए हैं, और व्यक्तिगत रूप से मुझे Vue थोड़ा बेहतर लगा
    Vue 3 का ref/reactive state management शक्तिशाली है, और DOM पर निर्भर हुए बिना test भी किया जा सकता है
    Lit की reactivity widget स्तर की है, इसलिए update triggers आपको खुद manage करने पड़ते हैं
    Vue का lifecycle simple है, जबकि Lit में कई callbacks पर ध्यान देना पड़ता है, इसलिए bugs आना आसान है
    अगर कोई खास वजह नहीं है, तो feature development पर ध्यान देना बेहतर है, क्योंकि tech stack बदलने से users पर लगभग कोई असर नहीं पड़ता
  • consumer के नज़रिए से देखें तो Vue हो या Lit, output आखिरकार Web Components ही है, इसलिए कोई खास फ़र्क नहीं है
    Vue एक framework है, इसलिए features ज़्यादा हैं; Lit native APIs के ज़्यादा करीब implement होता है
    Vue में build चाहिए, लेकिन Lit में runtime loading संभव है
    Vue दूसरे targets पर भी compile हो सकता है, लेकिन Lit सिर्फ Web Components के लिए है, इसलिए ज़्यादा साफ-सुथरा है
    आख़िरकार सबसे महत्वपूर्ण बात यही है कि team जिस technology से ज़्यादा परिचित हो, वही इस्तेमाल करे
  • सच कहें तो सबसे practical तरीका यह है कि बस एक web component bundle बनाकर export कर दिया जाए, और अंदर जो चाहें उससे implement किया जाए
    consumers को अंदरूनी implementation से मतलब नहीं होता; उनके लिए size और API ही मायने रखते हैं
    वैसे भी दूसरे लोग अपने environment के हिसाब से adapter बनाकर इस्तेमाल करेंगे