This is interesting stuff, but I'm going to go on record with the controversial opinion that it's the wrong approach.
https://front-end.social/@keithjgrant/110254602040846682
Shadow DOM already provides style scoping today along with a *ton* of other really key features. Doesn't quite do it for you? Then let's iterate on improvements to *that* spec, rather than this new one which IMO may lead to bad coding habits.
I'm all in on Declarative Shadow DOM this year and will promote that as a comprehensive solution.
I tried once to use the Shadow DOM and found it unpractical for my regular use; it seems a bit, I don't know, a bit low level for me. So I keep using Vue. I have a project where transpiling is not appropriate, so I use a BEM-like scheme for my CSS. And this new feature seems like a perfect fit for that.
Having choice is good when it doesn't break anything.
I see your point: giving unexperienced people a perfect way to harm themselves is a bad thing. But I think that boat sailed a long time ago. Web development has always had a long list of features seemingly tailored to shoot your own foot. And every year gets us at least a new one.
Maybe that's the reason of HTML5 success. No matter how awful your choices are, you can always follow them 🙈
@jgg What aspects of shadow DOM were unpractical for you? Granted, it's not something to pick up on a dime and noodle with for a little bit. It really requires a huge mindset shift around the difference between content markup and component internals. Again, I would file that under feature not bug.
I totally agree that, if I were to try it again, maybe I would change my mind. But, since you ask...
My impression was it is intended more for widget library creators than for whole web app creators. I found it too cumbersome to make a MainPage component in a SPA, but perfect to make a reusable calendar widget.
On a typical app, once I have to use Vue for the MainPage, it is only natural to use it for the small widgets. Avoiding cognitive overload is very important, specially when you have coworkers who are not so skilled.
New spec developments tend to kill old libraries.
Shadow DOM will need to get more developer friendly, or get new libraries for that, in order to kill current frameworks.
Or maybe there is a place for both worlds. Time will tell. There are still a lot of people using jQuery after all.
@jgg Definitely, I'm sure we'll see parallel evolution for some time to come.
Probably the most popular library on the sdom side to date: https://lit.dev
I didn't knew it; I will take a look. Thank you.
@jgg That's a fair point. The challenge here perhaps is deciding which component model you're going to prioritize. I like Vue a lot, but there's nothing about Vue's design which *encourages* shadow DOM (likely the opposite in fact). That's because Vue predates this spec.
DSD shifts the conversation a bit because now, in theory, you could even attach shadow DOM to `<body>` purely in HTML if you wanted to. Fer realz! Content vs. internals is now a legit question throughout the entire page tree.