1 पॉइंट द्वारा GN⁺ 2023-10-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Web Components की long-term स्थायित्व और flexibility पर लेख, JavaScript frameworks की तुलना के साथ
  • लेखक का तर्क कि किसी प्रोजेक्ट में तकनीक का चुनाव default option से नहीं, बल्कि उसकी constraints से तय होना चाहिए
  • लेखक ने अपने प्रोजेक्ट के लिए vanilla JS Web Components चुनने के कारण: portability और HTML rendering capability
  • लेखक का ब्लॉग Astro, Hugo, PHP में लिखे गए custom CMS, Tumblr, Movable Type, WordPress आदि जैसे कई tools से बनाया गया है
  • plain text files में Markdown के रूप में content बनाए रखने के फायदों पर ज़ोर, जिससे systems के बीच content migration सरल हो जाता है
  • लेखक का कहना है कि Astro-specific features सुविधाजनक हैं, लेकिन portable नहीं हैं, इसलिए उन्हें प्रोजेक्ट में इस्तेमाल नहीं किया गया
  • Web Components को Markdown के भीतर HTML के रूप में लिखा जा सकता है, जिससे वे Markdown content के बाकी हिस्से जितने ही portable बन जाते हैं
  • Web Components reusable HTML elements बनाने के लिए W3C standards का एक set हैं, जो सभी HTML, CSS, JS को एक single file में encapsulate करते हैं, और build system की ज़रूरत नहीं होती
  • लेखक बताता है कि Web Components attributes expose कर सकते हैं ताकि उन्हें बाहर से configure किया जा सके, जो native props जैसा है
  • maintenance और dependencies के trade-off को लेकर चिंता के कारण लेखक ने Lit, Stencil, Svelte जैसे Web Components में compile होने वाले frameworks के बजाय vanilla JS का उपयोग करने का निर्णय लिया
  • लेखक का तर्क है कि TypeScript जैसी dependencies उपयोगी features दे सकती हैं, लेकिन नए versions और APIs के साथ compatibility बनाए रखने में समय और मेहनत लगती है
  • इस बात पर ज़ोर कि उन dependencies से बचना महत्वपूर्ण है जिन्हें user नियंत्रित नहीं करता, और long-term accessibility तथा web content की resilience के लिए स्थिर और widely known standards पर टिके रहना चाहिए
  • लेखक का निष्कर्ष: अगर web का उपयोग long-term स्थायित्व को ध्यान में रखकर किया जाए, तो यह सबसे resilient, portable और future-ready computing platform है

1 टिप्पणियां

 
GN⁺ 2023-10-27
Hacker News राय
  • वेब कंपोनेंट्स की दीर्घायु पर एक लेख, जिसमें उनकी तुलना JavaScript framework से की गई है
  • टिप्पणीकर्ताओं ने बताया कि लेख में htmx लाइब्रेरी का उल्लेख नहीं था, और यह वेब कंपोनेंट्स से अलग है क्योंकि इसका फोकस server और state को sync करने पर है
  • htmx को इस बात के लिए सराहा गया कि इसमें कोई dependency नहीं है और यह backward compatibility पर फोकस करता है, जो कई JavaScript लाइब्रेरीज़ से अलग है
  • वेब कंपोनेंट्स में state management को एक अनसुलझी समस्या बताया गया, जिसे developers को wrapper framework के बिना खुद संभालना पड़ता है
  • वेब कंपोनेंट्स का performance उतना महत्वपूर्ण नहीं माना गया जितनी उम्मीद थी, और instantiation cost की वजह से कुछ छोटे elements को वेब कंपोनेंट्स से वापस हटाया गया
  • वेब कंपोनेंट्स की तारीफ इस बात के लिए हुई कि उन्हें इस्तेमाल किए जा रहे framework की परवाह किए बिना नए पेज में आसानी से जोड़ा जा सकता है, और style encapsulation के लिए भी सराहा गया
  • कुछ टिप्पणीकर्ताओं ने कहा कि वे वेब कंपोनेंट्स जैसे static solution की बजाय JS framework की प्रगति और सुधार को अधिक पसंद करते हैं
  • नया प्रोजेक्ट शुरू करते समय टीम के ज्ञान और कौशल को ध्यान में रखने के महत्व पर ज़ोर दिया गया
  • Rails Hotwire, Phoenix Liveviews, Laravel Livewire जैसे server-side solution को दिलचस्प प्रगति के रूप में उल्लेख किया गया
  • वेब कंपोनेंट्स की आलोचना इस बात के लिए हुई कि उन्हें server पर चलाया नहीं जा सकता, और उन्हें render करने के लिए client-side JS की ज़रूरत होती है
  • वेब कंपोनेंट्स में slots का उपयोग भ्रमित करने वाला और जटिल बताया गया, जिससे वे application बनाने के लिए कम आकर्षक लगते हैं
  • DOM API की आलोचना इस रूप में हुई कि यह components को जोड़कर application को काम करने लायक बनाने के लिए उपयुक्त नहीं है
  • वेब कंपोनेंट्स की आलोचना इस बात के लिए भी हुई कि attributes और event names जैसी चीज़ों के auto-complete के लिए editor support की कमी है
  • वेब कंपोनेंट्स की कुछ बुनियादी सुविधाएँ, जैसे form के भीतर buttons, अब भी अनसुलझी समस्याएँ बनी हुई हैं