Polymer 1.0 uses "Shady DOM" instead of a full shadow DOM polyfill. According to https://www.polymer-project.org/1.0/articles/shadydom.html, "Many projects simply cannot afford the Shadow DOM Polyfill, for the reasons given above. In particular, the performance costs on platforms like mobile Safari are nearly intolerable."
"Polyfilling shadow DOM is hard, the robust polyfill is invasive and slow. Shady DOM is a super-fast shim for shadow DOM that provides tree-scoping, but has drawbacks. Most importantly, one must use the shady DOM APIs to work with scoped trees."
So it sounds like this lighter, less complete Shady DOM half-polyfill that 1.0 uses is specifically made to make performance acceptable on iOS.
There has been major progress on getting all browser vendors to agree on Shadow DOM. It sounds like the final details will be hammered out soon (this summer) and implementation will start shortly after that.
Whenever yet-another-JS-framework hits Hacker News, there is a lot of pre-emptive recoiling amongst commenters from the latest flavor of the week tool fighting for our already fraying attention.
If you are like me - you believe in the potential of the web as an application platform, but you could do without the endless framework churn - you owe it to yourself to explore the Web Components standards. Web Components are a giant leap towards interoperability between application frameworks. If you don't know anything about Web Components, Polymer is a powerful and fun way to get started with them.
I don't know about React and Angular, but Ember wants to switch entirely to components in 2.x, AFAIK from its own implementation to web components). So I got the fear that we will switch from yet-another-JS-framework to yet-another-web-component-framework.
But I have the hope that this brings at least better interoperability between those frameworks.
That's not true at all. React can replace any DOM element, and you can have multiple instances of React running on a page.
React describes itself as a UI library rather than a framework. When I reviewed it [1], that seemed fairly accurate. I found it trivial to separate my React UI code from the rest of my application.
It's true that React doesn't let you build web components. React does not use or polyfill Custom Elements or Shadow DOM.
It's also true that React is "monolithic" in the way that other frameworks are: they don't naturally interoperate, or do by cumbersome adapter libraries that require wrapping widgets and marshaling between data-binding techniques. They interfere with normal DOM usage, and tend to break if other code modifies a component's DOM (granted Shady DOM has made this trade off temporarily), and they aren't "just elements" - getting a node controlled by React out of the DOM doesn't get you the component itself, no useful API is added to the node.
You simply don't see many applications that mix and match React, Angular and Ember because of this. This Polymer difference is that it's deigned to help you create "just elements" so that they're interoperable with other frameworks, plain JavaScript or just HTML. Users of Polymer elements should never have to know that they were made with Polymer.
Needing to use Shady DOM APIs is an unfortunate exception to this, but an site can choose to use the full Shadow DOM polyfill if the performance fits their needs.
That option may have become available some time ago, but I haven't looked at Polymer in quite awhile. Two-way binding can be a great and convenient thing, but having it as the only option, in the early days of Polymer, led to many headaches (for me, at least). The reason is that two-way binding can make it practically impossible to reason deterministically about data flow when several or more bindings come into play.
I like the one-way bindings myself, but one thing I've never reconciled with the one-way is the one-true-way view is that in a one-way only world you tend to wire up more event listeners to deal with data changes and inputs, and those listeners can be all over the place with arbitrary side-effects.
A two-way binding ends up being shorthand for a specific type of event handler with a known side-effect, making them easier to find and reason about.
Maybe I'm missing some other aspect to the one-way-only view though.
Arbitrary side-effects can be a recipe for problems, definitely.
One-way flow is, to my mind, best used in conjunction with persistent data structures and some tangible mechanism to coordinate state changes under a single reference, or a small set of references.
reply