
Polymer 1.0 - axg
https://www.polymer-project.org/1.0/
======
cdata
Disclosure: I am a contributor to this project.

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.

~~~
k__
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.

~~~
omeid2
interoperability is pretty much the whole point of Web Components.

------
michaelsbradley
I'm very happy to see that one-way binding is now supported within templates,
with syntax that sets it apart from two-way binding:

[https://www.polymer-project.org/1.0/docs/devguide/data-
bindi...](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.

~~~
spankalee
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.

~~~
michaelsbradley
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.

------
mrisse
Do web components have a chance when a polyfills are required for iOS? Does
anyone have any experience w/ Polymer performance on iOS?

~~~
trevordixon
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](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.

~~~
spankalee
Exactly. Performance under iOS is great with Shady DOM, at the expense of
needing to use its APIs to get the effects of DOM scoping and composition.

------
cpr
So, IIUC, Polymer and FB React are competing visions of how to build web
components.

Does anyone have direct experience with both, and can compare them from a
real-world usage viewpoint?

Thanks!

~~~
spankalee
React does not let you build Web Components, it's a monolithic framework in
the same vein as Angular, Ember, etc.

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.

~~~
jdlshore
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.

[1] An Unconventional Review of React:
[http://www.letscodejavascript.com/v3/blog/2014/09/react_revi...](http://www.letscodejavascript.com/v3/blog/2014/09/react_review)

~~~
spankalee
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.

------
cnbuff410
The performance improvement brought by 1.0 is significant. It's finally time
to try Polymer in production environment. Congratulations to the team.

------
chuckhorton
Polymer 1.0 the future of app development.

------
nwmcsween
The 'elements' section is completely unusable on a mobile

