alt Hacker NewsI think Google has done a great job of making Web Components seem both poorly implemented and way too complex. If Angular is the "Google blessed" way of writing Web Components and Angular makes a terrible hash of it, who can build good Web Components?
Angular and a couple other well known frameworks were targeting for far too long pre-spec Google-specific versions of Web Components and Web Components moved quickly past that and settled into cross-vendor specs with smarter defaults and simpler APIs a lot of the marketing damage was already done that Web Components were too complex and too poorly supported.
So much of the Web Components world is stuck with the quagmire of the Shadow DOM, and while there are some generalized use cases for the Shadow DOM, I have the harsh opinion that the Shadow DOM was mostly invented to be "better IFRAMES for Ad Publishers" and not much else. I don't think enough web developers yet realize that the Shadow DOM is entirely optional and its complexity is so much easier to ignore and toss than to try to utilize.
> focused on pulling in the good things from the framework world (i.e. what happened with jQuery), but they didn't.
I'm coming to the growing opinion that between Web Components and the TEMPLATE tag Browser vendors have finally caught up with some of the best ideas of the Knockout-era "Progressive Enhancement" world, assuming you ignore the Shadow DOM as mostly YAGNI.
Sure, a lot of cross-component communication and some of state management goes back to DOM APIs and DOM event management, but there used to be a lot of knowledge in those areas and maybe it past time to return to Vanilla JS ideas about some of that. In the time since jQuery and Knockout, all browsers today have much more consistent DOM APIs for event management, at least.
(Similar for routing. Vanilla routing, even "SPA" routing is easier than ever with modern APIs, even the API not fully standardized and cross-browser yet, but also the improved APIs for hash navigation. Also, Web Components seem a great reminder that MPA routing is great and brilliant, and so well tested in browsers and servers. With View Transitions now generally well supported, and getting better, many MPAs feel as good or better than SPAs even.)
(And I feel like most styling problems with Web Components are self-inflicted with and by the Shadow DOM. It's nice to embrace the cascade again, if you can.)
I was bullish on Web Components for a while, but most of my complaints have disappeared in recent months, and especially in realizing that I was very happy ignoring everything about the Shadow DOM. Sure, I'm not using Web Components without a "framework" but I'm using a far smaller "view engine" than a React or Angular, a lot more "Vanilla", and feeling a bit like it's a Revenge of Knockout sort of era.
Replies
I haven't had too much trouble with Shadow DOM so far, and I was especially surprised to learn about `<template shadowrootmode="open">` recently. It makes SSR rendering of web components with shadow DOMs viable and appears to be well supported in browsers.
TLDR: Browser vendors made Shadow DOM for themselves.
Browser implementors use Shadow DOM extensively under the hood for built-in HTML elements with internal structure like range inputs, audio and video controls, etc. These elements absolutely need to work everywhere and be consistent, so extreme encapsulation and fixed api for styling them is an absolute must.
The Shadow DOM API is the browsers exposing, to developers, a foundational piece of functionality.
If you’re thinking about whether Shadow DOM is appropriate for your use case, consider how/why the vendors use it —- when an element’s API needs to be totally locked down to guarantee it works in contexts they have no control over. Conversely, if your potential use case is scoped to a single project, the encapsulation imposed (necessarily!) by Shadow DOM is probably overkill.
Web components are a decent way to make reusable UI, but if they don’t have strong encapsulation needs, you might avoid Shadow DOM.
Angular has nothing to do with web components. It isn't even a way to write web components.
If anything is the "Google blessed" way of writing web components (Google doesn't really work that way), it's Lit: https://lit.dev/
> Sure, a lot of cross-component communication and some of state management goes back to DOM APIs and DOM event management, but there used to be a lot of knowledge in those areas and maybe it past time to return to Vanilla JS ideas about some of that.
My approach is, actually, an attempt to inject some Vanilla into front-end component development.