>> One of the really rad things about Polymer (0.5) and webcomponents is that everything is just DOM. You can pretty easily use core- and paper- components libraries inside of an (say) angular app to render out content.
This is truly the great promise of Web Components, and will be completely true when Shadow DOM is native in all browsers. However, up to now, we've only had the Shadow DOM polyfill on non-supporting browsers. The Shadow DOM polyfill is a great piece of code, but it only approximates the interoperability we crave. There are numerous cases where the polyfill falls over: it has never been fire and forget. More specifically, the Shadow DOM polyfill is extremely invasive: it wraps the majority of the DOM api in JavaScript. This is an imperfect task which leads to an interoperation mine-field, and dramatically degrades performance. Additionally, the Shadow DOM polyfill makes no attempt to simulate Shadow DOM CSS scoping, so styling fidelity vs native Shadow DOM is poor. Ultimately, we decided that providing users with a Polymer experience that was sufficiently robust for production code required a different solution that the Shadow DOM polyfill, and Shady DOM was born. Shady DOM is compatible with native Shadow DOM, has a more robust CSS scoping facility, and is dramatically more performant. We feel good suggesting that developers can build and ship products using Shady DOM, a bar we never quite surmounted with the Shadow DOM polyfill. As I mentioned at the outset, the true promise of Web Component will not be achieved until Shadow DOM is truly native across browsers. The great news is that all major browser vendors are actively working towards this goal. Go take a look at the recent discussions on public-webapps <https://lists.w3.org/Archives/Public/public-webapps/> mailing list if you want to see the sausage being made. Users interested in Web Components are encouraged to chime in and let the browser vendors know their feelings on the importance of Shadow DOM interoperation. Scott On Mon, May 18, 2015 at 5:46 PM, Eric Eslinger <[email protected]> wrote: > One of the really rad things about Polymer (0.5) and webcomponents is that > everything is just DOM. You can pretty easily use core- and paper- > components libraries inside of an (say) angular app to render out content. > Doesn't matter if you're using jQuery raw or ember or what have you- DOM is > DOM, and it mostly works (modulo some property / attribute bindings) > > The new localDom API seems to indicate that this may no longer be the > case- if I'm redistributing DOM content, I need to use the polymer dom > interface, rather than just plain parent/child/append calls on document. > > This seems to indicate that modern polymer isn't going to be compatible > with angular, or with any other library that manipulates the DOM, or is it > the case that this only matters when there's more complicated shady/light > manipulations? > > As an example, if I have content in the drawer part of a > paper-drawer-panel, and then, using jquery or some other element selector, > inject nodes inside of the already-projected menu div, will this break > things? Or is it only the case that I need to use the local DOM api when if > I'm changing the nodes that would be selected as content to project (and > not their child nodes)? > > Is there some way to shim the document-level query selectors in there or > add a mutation observer that calls distributeContent as needed? I'm > guessing it was this shimming and mutation observer that contributed to the > slowness of 0.5 in non-chrome browsers. > > I've got next week blocked out to actually work on getting angular 1.4 to > play nice with polymer 0.9 (we use angular to build the page and manage > data, and polymer for handy flexbox directives and material design ui > bindings). So I guess I'll figure it out then. > > e > > Follow Polymer on Google+: plus.google.com/107187849809354688692 > --- > You received this message because you are subscribed to the Google Groups > "Polymer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/polymer-dev/CABsi40JyUq76PSwF%2Bxx_k9CXcJtJmnXEOVXstdQu6BVRoYRc6g%40mail.gmail.com > <https://groups.google.com/d/msgid/polymer-dev/CABsi40JyUq76PSwF%2Bxx_k9CXcJtJmnXEOVXstdQu6BVRoYRc6g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAHbmOLbdqhZZ42M%3Dd42F65ntgJvnERAxNqNt7%3DtFZR9qqnBxgA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
