"Web Components" के बजाय हमें क्या चाहिए
Web Components की आलोचना उनकी जटिलता, कमजोर semantics, और इस बात को ठीक से न संभाल पाने पर केंद्रित है कि आधुनिक JavaScript frameworks वास्तव में UIs कैसे बनाते हैं; कई लोग तर्क देते हैं कि ये brittle specs जोड़ते हैं लेकिन state management, reconciliation, और styling जैसी मूल समस्याएँ हल नहीं करते। इसके बजाय टिप्पणीकार ब्राउज़रों से आग्रह करते हैं कि वे ऐसे निचले-स्तर के primitives standardize करें जिन पर डेवलपर्स पहले से converge कर रहे हैं—जैसे बेहतर DOM diffing, reactivity, और UI widgets—जबकि अन्य लोग Web Components (अक्सर Lit जैसी libraries के माध्यम से) को interactive elements को encapsulate करने का एक उपयोगी, framework-agnostic तरीका मानते हैं। यह बहस JavaScript ecosystem churn, Observables और signals जैसे overlapping standards, और क्या web को अधिक native-like या binary application models की ओर बढ़ना चाहिए, जैसी चिंताओं तक फैल जाती है.
मानक, ब्राउज़र, और शासन
- इस पर बहस कि Web Components वास्तव में किसके लिए हैं: ऐप डेवलपर्स के लिए या ब्राउज़र/मानक इंजीनियरों के लिए।
- W3C बनाम WHATWG की भूमिकाओं पर असहमति: कुछ लोग W3C को WHATWG के de-facto स्पेसिफिकेशनों को औपचारिक रूप देने वाला मानते हैं; दूसरे तनावों को उजागर करते हैं (HTML snapshots, privacy, ऐसे spec बदलाव जो मौजूदा content को तोड़ दें)।
- चिंता कि HTML specs और उनसे जुड़े processes गड़बड़, धीमे, और कभी-कभी backward compatibility तोड़ने वाले हो गए हैं।
Web Components: लाभ और गहरी शंका
- समर्थकों को पसंद है:
- ऐसे custom elements परिभाषित करने की क्षमता जो frameworks के across और plain HTML में भी काम करें।
- Shadow DOM और ES modules के जरिए encapsulation।
- component libraries और complex apps में उपयोग (अक्सर Lit के साथ), सिद्धांततः बिना build steps के।
- आलोचकों का तर्क है:
- डिज़ाइन ने वास्तविक-विश्व framework अनुभव और userland evolution को नज़रअंदाज़ किया।
- specs जटिल, fragile हैं, और Web-Component-विशिष्ट समस्याओं को ठीक करने के लिए और specs पैदा करती हैं।
- आधुनिक frameworks के लिए मूल building blocks के रूप में खराब fit (eager rendering, कमजोर SSR story, awkward composition, Shadow DOM के surprises)।
- जिन ecosystem leaders ने कभी Web Components को आगे बढ़ाया था, वे अब उनसे दूर हो गए हैं।
- एक niche जहाँ कई लोग सहमत हैं कि ये मददगार हैं: encapsulated widgets और custom form controls, कुछ हद तक safer, छोटे iframes जैसे।
Frameworks, ecosystem churn, और compatibility
- JS frontend की complexity को लेकर तीव्र frustration: कई layers (bundlers, linting, TS, build/transpile) और बार-बार paradigm shifts (classes → hooks → server components)।
- अन्य लोग जवाब देते हैं कि सभी ecosystems evolve होते हैं, और JS विशेष रूप से खराब नहीं है, जैसे Python packaging या अन्य stacks में breaking changes।
- व्यापक चिंता कि JS libraries और tools शायद ही कभी stable, shared interfaces को प्राथमिकता देते हैं, जिससे “internal incompatibility” और painful upgrades होते हैं।
Reactivity, observables, और overlapping primitives
- इस बात पर सहमति कि “reactivity” और reconciliation वास्तविक समस्याएँ हैं, लेकिन अभी कोई consensus design नहीं है।
- Signals, observables, streams, और अन्य reactive primitives के बीच overlapping, incompatible standards का जोखिम है।
- कुछ लोग browser-level observables का स्वागत करते हैं; अन्य “changes” के बारे में सुनने के लगभग-duplicate तरीकों की proliferation से डरते हैं।
WASM, native apps, और web की भूमिका
- कुछ लोग चाहते हैं कि browsers बस native binaries चलाएँ; अन्य past plugin failures और security issues की ओर इशारा करते हैं।
- इस पर सहमति है कि DOM operations UI performance पर हावी हैं; WASM मुख्यतः भारी computation में मदद करता है, सामान्य reactive UIs में नहीं।
- WASM के लिए tooling को बेहतर माना जा रहा है लेकिन अभी भी native से inferior है; cross-compiling workflows मौजूद हैं, पर clunky लगते हैं।