Polymer 1.0

by axg • 11 years ago

56 18 11 years ago

mrisse• 11 years ago

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

trevordixon• 11 years ago

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.

spankalee5• 11 years ago

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.

spankalee5• 11 years ago

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.

rictic• 11 years ago

Getting good performance out of iOS was a major focus for v0.8 - thus the shady dom. They got >5x faster performance: https://blog.polymer-project.org/updates/2015/03/27/why-0.8/

cnbuff410• 11 years ago

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

chuckhorton• 11 years ago

Polymer 1.0 the future of app development.

cdata• 11 years ago

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__• 11 years ago

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• 11 years ago

interoperability is pretty much the whole point of Web Components.

cpr• 11 years ago

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!

spankalee5• 11 years ago

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• 11 years ago

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

michaelsbradley2• 11 years ago

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

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.

spankalee5• 11 years ago

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.

michaelsbradley2• 11 years ago

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.

nwmcsween• 11 years ago

The 'elements' section is completely unusable on a mobile

Polymer 1.0

Related Stories