back
2 comments
Yes.

Shadow DOM is a key part of web components: http://www.w3.org/TR/components-intro/#shadow-dom-section

It's a common misconception that Shadow DOM is required to create a "web component". What it brings to the table is style and dom encapsulation. Not using it means components won't have those benefit (by default), but there's nothing stopping people from creating custom elements that are not encapsulated.

An analogy can be made to requestAnimation. raF isn't required to create animations, but it's highly useful in that context. raF can also be used for other use cases outside of animations (scroll effects, etc). Shadow DOM is the same IMO. It's a useful standalone technology, but when used in the context of web components, it really shines.

That is what I thought, so dead the tech is dead in the water.
Well, it isn't even a standard yet. Google wants to push it just to have it for Angular.
Adding powerful new APIs to the web platform benefits more than just Angular, no? The set of evolving standards-based technologies behind "web components" (templates, Shadow DOM, HTMLImports, custom elements) can be utilized by any framework. More tools in our toolbox.
>Adding powerful new APIs to the web platform benefits more than just Angular, no?

Maybe, but that doesn't mean Google cares about enpowering the web platform in general.

If they did they wouldn't have removed other standard code (css regions), and they wouldn't have pushed for their, non-standard, Shadow DOM implementation.

That might be a bit of an exaggeration, although on the Angular side, we'd certainly like to have it pref'd on by default this summer (as unlikely as that may be).

Anyways, I really think people are sort of attributing malice to Glazkov's remarks where none really ever existed, WRT shipping the shadow DOM in its current state.

Yes, but the question is whether Web Components is needed.
Needed for a document-based web? maybe not.

Needed to turn the web into a solid application platform with good support for composition and code reuse? I'm going to say yes (or if not Web Components then something that facilitates better scoping of code and CSS).

Of course, not everyone wants to see the web-application model become too powerful...

>Of course, not everyone wants to see the web-application model become too powerful...

Is that directed at Apple? Because they have had the most powerful mobile web engine for years -- and they continue evolve their desktop one. Heck, the gave us stuff like Canvas and CSS animations.

That was to kill flash. Now they have video and animations sorted they don't want to eat into their native platform.
>That was to kill flash

Nope, they never supported flash in mobile in the first place. And they continue to do so today, years after Flash has been dead and burried.

They needed to have an alternative to flash to make not implementing it viable...

If they hadn't added canvas/video etc to HTML and there was no way to do half the things flash did, it would have been trumped by Android and their mobile flash player.

>Of course, not everyone wants to see the web-application model become too powerful...

That's funny, since when the iPhone first came out, Apple claimed there wasn't gonna be a native SDK, and developers would just write all their apps in HTML.

Try Reactjs. Does all that at 60 fps without the Shadow DOM on all modern browsers.