3 ms·

If you are using the shady dom (web components lite, rather than the low perf full polyfill), the library requires you to do dom manipulation through the polyme

by pfooti 10y ago

If you are using the shady dom (web components lite, rather than the low perf full polyfill), the library requires you to do dom manipulation through the polymer local DOM API. [0] That means without shimming other libraries, polymer is incompatible with any other libraries you might use to manipulate the DOM. For example, you can't easily mix angular, react, or ember templates with some polymer elements, because (e.g.,) angular's ng-if directive doesn't use polymer.dom to inject created nodes. This is currently my biggest beef with polymer. Someday, webcomponents will be great, principally due to composability and portability. Just plug the one component you need in to your extant work. But for now, that promise is not quite realized. [0]: https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#dom-api https://www.polymer-project.org/1.0/docs/devguide/local-dom....

spankalee 10y ago
I'm on the Polymer team. Shady DOM is probably the biggest beef that we have with the project, but it was a very necessary tradeoff given that the Shadow DOM polyfill was just too slow. Polymer can seamlessly switch between Shadow DOM and Shady DOM (though your own elements needs to be tested under both). You can still use the Shadow DOM polyfill is compatibility is a higher concern than raw performance. Safari and Chrome will have native Shadow DOM v1 implementations by the end of the year, and quite possibly Firefox. If we have enough resources, we may decided to make an IE/Edge specific Shadow DOM polyfill that'll be much faster because it'll path DOM prototypes rather than wrap DOM nodes. Wrapping is necessary because Safari doesn't properly let you patch Node prototypes. If this happens, we'll have fast and compatible DOM APIs.
- pfooti 10y ago
  Yes, I'm definitely looking forward to the Real Shadow DOM being browser-supported. I was unable to use the full webcomponents polyfill in my own application, as it introduced gamebreakers with contenteditable-based rich text editors [0]. Putting polymer anywhere on my page meant my rich text editor (quilljs fwiw) broke on non-chrome browsers, even through I wasn't doing anything polymeresque with the editor. It was just the polyfill interacting poorly with the browser's range implementation. In my case (my application also heavily leaned on angular for routing and page-level templating), I couldn't mix-and-match angular and polymer and also maintain cross-browser support of the text editor. But I still am _super_ excited about the future of the webcomponents world. I mean, if nothing else, having well-namespaced element ids (if I have two editor components on the page, I can't just grab "#dateinput") will be great. I love the idea of directly attaching properties to DOM nodes, encapsulating templates, and projecting content into viewports. It's seriously rad. I am 100% on board with the notion, it's just the polyfill in the meantime that's problematical. https://github.com/webcomponents/webcomponentsjs/issues/212 https://github.com/webcomponents/webcomponentsjs/issues/212

by pfooti 10y ago

spankalee 10y ago

I'm on the Polymer team. Shady DOM is probably the biggest beef that we have with the project, but it was a very necessary tradeoff given that the Shadow DOM polyfill was just too slow. Polymer can seamlessly switch between Shadow DOM and Shady DOM (though your own elements needs to be tested under both). You can still use the Shadow DOM polyfill is compatibility is a higher concern than raw performance. Safari and Chrome will have native Shadow DOM v1 implementations by the end of the year, and quite possibly Firefox. If we have enough resources, we may decided to make an IE/Edge specific Shadow DOM polyfill that'll be much faster because it'll path DOM prototypes rather than wrap DOM nodes. Wrapping is necessary because Safari doesn't properly let you patch Node prototypes. If this happens, we'll have fast and compatible DOM APIs.

pfooti 10y ago
Yes, I'm definitely looking forward to the Real Shadow DOM being browser-supported. I was unable to use the full webcomponents polyfill in my own application, as it introduced gamebreakers with contenteditable-based rich text editors [0]. Putting polymer anywhere on my page meant my rich text editor (quilljs fwiw) broke on non-chrome browsers, even through I wasn't doing anything polymeresque with the editor. It was just the polyfill interacting poorly with the browser's range implementation. In my case (my application also heavily leaned on angular for routing and page-level templating), I couldn't mix-and-match angular and polymer and also maintain cross-browser support of the text editor. But I still am _super_ excited about the future of the webcomponents world. I mean, if nothing else, having well-namespaced element ids (if I have two editor components on the page, I can't just grab "#dateinput") will be great. I love the idea of directly attaching properties to DOM nodes, encapsulating templates, and projecting content into viewports. It's seriously rad. I am 100% on board with the notion, it's just the polyfill in the meantime that's problematical. https://github.com/webcomponents/webcomponentsjs/issues/212 https://github.com/webcomponents/webcomponentsjs/issues/212