I was reluctant to use Web Components in any personal project and shoo'ed my coworkers away from using it on commercial projects because the uptake by browser vendors seemed so lackadaisical. I'm thankful to Mozilla for explaining the reasons why -- it's complicated! noone agrees!
I am loathe to polyfill modern browsers adding completely needless overhead trying to chase some panacea. At least Chrome and Firefox need to agree on (and be in the process of implementing) a feature for me to consider using it and polyfilling it.
The Web Components thing seemed overengineered and too much work for component developers to get wide adoption outside of widget toolkits. All that behind-the-scenes offsetTop confusion tells me that the way Google envisioned makes it a bad fit for the DOM/CSS/JavaScript hodgepodge cruft-pile that has built up over the years. The fact that there are so many open proposals out there for the various features should be a signal to architects to run the other way on Web Components.
So, into this vendor mess strides React, (and to a much lesser extent Angular and Ember due to ocean-boiling), which gives us a fancy component model atop standard DOM and JS. And at just the right time -- web apps are far too big this decade to be coded monolithically. I mean, everyone knows that, but what could you do about it before a decent UI component framework appeared?
Being able to compose your app in terms of nested components is the way build large, high-quality, well-tested web apps because it lets us reason about parts of the UI rather than the whole. And the DOM performance with React ain't too bad neither. And being able to render the same React component statically on the server and dynamically on the client solves a lot more problems too.
None of the frameworks you have mentioned support proper sandboxing of component internals. They are leaky [1] and incompatible with each other abstractions. We need at least some basic native shadow DOM support in order to hide implementation details and avoid naming clashes.
Agreed, most libraries and frameworks have nasty leaky abstractions; that is part of the cost of choosing to add those packages in your architecture. And heck, the browser itself is a clown car full of leaky abstractions, we deal with the problem everywhere.
I think successful open source projects have a pretty good track record managing leaky abstractions since they have so many users. JQuery did a good job in this area over time, papering over many of the leaky abstractions present in the DOM across browsers. Looking at the bug tracker for React, I think they are doing okay too after a rocky start. Haven't really tracked Angular, but I hear Ember is a pretty well run project too.
Shadow DOM does sound pretty good, but not essential to componentization if you're managing your ID's carefully. Honestly, I don't care if a framework or the browser manages my component scopes, I just want it taken care of.
I always thought scoped stylesheets would be more important to non-leaky UI component development, but it seems like that is yet another dead-end experiment that didn't catch on. http://caniuse.com/#feat=style-scoped So we fall back to tooling again, and get something like SASS to manage and build our monolithic stylesheets.
ID prefixing won't prevent component internals from leaking to event listeners, querySelector results, TreeWalkers/NodeIterators, innerHTML, and many other APIs.
Native shadow DOM allows me to write components with strict encapsulation on pair with the built-ins such as <button> or <input>, neither framework comes even close to that.
Styles defined inside shadow DOM are always scoped to the local shadow tree, so there is really no need for style[scoped]. Chrome and Opera (and maybe Firefox) support CSS encapsulation inside shadow DOM making the CSS preprocessors less needed.
Shadow DOM does sound pretty cool, I wish its design allowed it to fit in better with existing DOM.
I think react components give you pretty good isolation. You don't spend any time querying by selector or innerHtml, you just update your model, it re-renders the component tree, and then a diff of the DOM yields the mutations it will do on your behalf. Event binding is similarly abstracted. It's a different paradigm than what you're describing, and I think it works well for a lot more use cases than just "componentize the DOM".
I'd love to be able to combine shadow DOM and react somehow (assuming wide browser support emerges). I bet a lot of performance optimizations could be derived in the browser from native Shadow DOM.
I am loathe to polyfill modern browsers adding completely needless overhead trying to chase some panacea. At least Chrome and Firefox need to agree on (and be in the process of implementing) a feature for me to consider using it and polyfilling it.
The Web Components thing seemed overengineered and too much work for component developers to get wide adoption outside of widget toolkits. All that behind-the-scenes offsetTop confusion tells me that the way Google envisioned makes it a bad fit for the DOM/CSS/JavaScript hodgepodge cruft-pile that has built up over the years. The fact that there are so many open proposals out there for the various features should be a signal to architects to run the other way on Web Components.
So, into this vendor mess strides React, (and to a much lesser extent Angular and Ember due to ocean-boiling), which gives us a fancy component model atop standard DOM and JS. And at just the right time -- web apps are far too big this decade to be coded monolithically. I mean, everyone knows that, but what could you do about it before a decent UI component framework appeared?
Being able to compose your app in terms of nested components is the way build large, high-quality, well-tested web apps because it lets us reason about parts of the UI rather than the whole. And the DOM performance with React ain't too bad neither. And being able to render the same React component statically on the server and dynamically on the client solves a lot more problems too.