Polymer 1.0
polymer-project.org
polymer-project.org
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.
But I have the hope that this brings at least better interoperability between those frameworks.
https://www.polymer-project.org/1.0/docs/devguide/data-bindi....
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.
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.
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.
"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.
Does anyone have direct experience with both, and can compare them from a real-world usage viewpoint?
Thanks!
Real world usage, you can import and drop a Polymer element on your page and it just works. With React, your whole app has to be React.
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.
[1] An Unconventional Review of React: http://www.letscodejavascript.com/v3/blog/2014/09/react_revi...
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.