Material design with Polymer

[sedachv]

"Material design with Polymer" I thought the headline was about a materials design startup, not a UI library. Can you please add more unrelated jargon and nonsensical analogies from random fields to your documentation?

[pedrow]

When they use an unqualified, lower-case 'material design' they are referring to the thing that Google announced at I/O yesterday, are they?

[malandrew]

Despite all my comments disagreeing strongly with WebComponents and the direction of putting everything in the DOM, I will say that you all did an excellent job with the design aspects of designing for the Z-plane. That's solid stuff and everyone who reads this thread should definitely take the time to read through all the design guidelines for Material, because even if you don't use Material, those ideas are really valuable and can be explored in other frameworks like Famo.us, Ember.js, Velocity.js, React.js. The web is definitely moving in the direction where designing for the Z-plane and subtle animation affordances will matter, and this is great exploration of where things can go.

For those whose experience, is mainly on the web, these are also good resources:

Meaningful Transitions: http://www.ui-transitions.com/

Capptivate: http://capptivate.co/

The Z-Axis - Designing for the Future:

http://alistapart.com/article/the-z-axis-designing-for-the-f...

[disclaimer: I work at famo.us)

[regularfry]

Not encouraging: http://imgur.com/riycCA1

[rtkwe]

Also the elements themselves don't render properly in FF24 (work mandated):

http://imgur.com/AyactvC

[riffraff]

on first load, chrome 35, snow leopard (yeah I should update) also broen

https://www.dropbox.com/s/qiqbrs0d55qgf6e/Screenshot%202014-...

[timdorr]

What OS/Browser combo?

[malandrew]

I was kind of confused as to the organization of the repos and how this is all brought together. Is there a document somewhere explaining the relationship (hierarchy) of all the repos and what role each plays in the larger polymer material project?

Specifically, where is the code that does the layout for this? I want to see how they are doing the positioning of elements in space. Is it all CSS classes or do they do positioning with javascript?

[crdblb]

It's very strange that when you click or touch down on a button, the shadow spreads out more, as though the button got further away from the underlying surface. It seems like any "press down" sort of action should, well, make it appear to move down, not up.

[lebek]

In Polymer ajax is an element: https://github.com/PolymerLabs/polymer-ajax/blob/master/test...

[malandrew]

What a strange strange choice. Instead of moving responsibilities to a imperfect but very flexible turing-complete language (javascript), they are trying to shoehorn everything into a markup language originally designed as an abstraction for documents (html).

I liked a lot of what I saw in the project, but this "ajax as an element" makes me want to facepalm, or at least scratch my head and wonder "why?!?"

Can someone from the polymer team elaborate the reasoning behind this?

[tkps]

Correction to OP: In Polymer, ajax CAN be an element. Or not. You can build whatever elements you want in Polymer (even non-visual utility elements like xhr and localStorage), but it's YOUR job (the developer) to choose the elements that fit in with the goals and architecture of your project.

Equating the fact that Polymer PROVIDES a declarative ajax element with the inevitability that any project you build will be fraught with bad code factoring and memory bloat because you MUST use it is like saying that because jQuery UI provides a Tab View, all of your jQuery UI's will be horrible because you must build them only out of Tab Views. Polymer just provides the sugar for minting your own custom elements, as well as a solid reference set of pre-built elements (core-, paper-); which ones you choose to use is up to you.

Most of this discussion largely misses the point and elegance of what Web Components generally and Polymer specifically are gunning for: The ability to create, reuse, and share well-factored, arbitrary pieces of web functionality (which may or may not include presentation) that have a well-defined imperative API (instance properties, methods) as well as a familiar, serializable declarative syntax (HTML) that can be manipulated imperatively after the fact (DOM), that will (one day, fingers crossed) be consumed natively by all browsers, without today's existing framework-based silos (React components, Angular directives, etc.). When it makes sense in your application (i.e., when you determine you get more use out of factoring it as a reusable element), then promote that functionality to an element; otherwise, you're free to embed that functionality (including ajax requests) as imperative JavaScript inside the component using the techniques you use today.

As for why you might be interested in a declarative <ajax> element: Polymer also provides declarative property binding and templating, which makes this possible (and absurdly simple, and very cool IMO):

    <select value="{{department}}">
      <option value="eng" selected>Engineering</option>
      <option value="sales">Sales</option>
      <option value="hr">Human Resources</option>
    </select>

    <core-ajax url="/{{department}}.json" handleAs="json" response="{{employees}}" auto></core-ajax>

    <template repeat="{{employee in employees}}">
      <div>{{employee.name}}</div>
      <img src="{{employee.avatar}}">
    </template>

Note from the above example: - Completely declarative (no imperative JS required) - No boilerplate querySelectors required - No boilerplate addEventListeners required - Good points for readability and understanding author intent - Are there times where you may need to dynamically create and throw away XHR's based on complex heuristics that don't readily fit into a declarative model like above, or when the maintainability benefits of doing so don't justify whatever (hopefully small) cost there is to instantiating an element and holding it in the DOM while the view is in use vs. using the xhr API imperatively? (rhetorical question: survey says...?) - In those cases, Polymer doesn't force it's opinion on you that in a lot of cases declarative elements can be good. In those cases, make your xhr calls imperatively like you do today, and apply the component model in the vast majority of other cases where it does make sense.

Time will tell how developers apply this new component model, and Polymer is doing a lot of experimentation in the open to try and push those boundaries and see what sticks.

[zghst]

On one hand, I worry that Google is monopolizing the future of the web, but on another, I'm glad because they are effective at producing the features that us developers want.

I have mixed feelings about Polymer, currently its high browser requirements make it too radical to use at work (IE, Firefox & Safari be broken yo), but forward enough to get me experimenting with it on my personal projects. At the workplace, I'll continue to stick to React.

[malandrew]

I love the look and feel that went into the design of Material here, but with respect to web components, we should be worried that Google is monopolizing the future of the web. See my comment below: https://news.ycombinator.com/item?id=7947119

It bugs me that Polymer is being marketed as "polyfills", since the term polyfill generally tends to connote something that fills in for an already agreed upon w3c standard that will appear in all user agents eventually. Whereas web components and shadow dom is still very much in the proposal/experimentation stage and has a ways to go before reaching standardization. There are still some disagreements to be resolved by all those that contribute code to the major user agents.

Calling polymer a polyfills library is misleading and an abuse of the intent of the term polyfill [0].

Also related: "Apple Removes Shadow DOM from Safari"[1][2]

[0] http://remysharp.com/2010/10/08/what-is-a-polyfill/

[1] http://trac.webkit.org/changeset/164131

[2] https://news.ycombinator.com/item?id=7243122

[Kiro]

What is Polymer? I thought it was a polyfill for Web Components but this seems like a UI library or something.

[cletusw]

It's both. This is a slightly outdated image, but it describes it pretty well: http://4.bp.blogspot.com/-rPbEdmEpHWA/UeW4Xqmg0oI/AAAAAAAAAx...

Basically, there's a layer of polyfills called the Platform that will disappear as browsers implement key web platform features natively. On top of that is the main Polymer library, which is a small sugaring library that makes using the individual Platform polyfills together a lot easier. On top of that are a couple different sets of both UI and non-UI web components built using Polymer, namely core-elements and paper-elements.

[kyriakos]

Looks good but runs extremely slow on my phone (LG G2)

[programminggeek]

Clearly you need a more modern phone.

[wildpeaks]

I like that they keep developing Polymer, but the IE10+ requirement makes it a hard sell for customer projects :/

[ryanSrich]

Considering that this is mostly aimed at creating mobile sites and apps I don't see that requirement as a deterrent.

[SneakerXZ]

So Polymer is like Bootstrap with Angular? How is Polymer related to Angular or React?

[Inufu]

Angular can use Polymer components.

[sahat]

Where does Polymer stand in relation to React.js from Facebook?

[grayrest]

They're only similar in that they're both for building component based DOM UI.

Polymer is tied into the WebComponents standardization effort (also driven by google-related people). Pieces of the DOM are managed by relatively small, contained objects that maintain their own internal state and keep the DOM in sync. It achieves component state synchronization via data binding like Angular or Ember and some sort of KVO mechanism (eventually Object.observe if they're not using that already, I haven't looked at their code in a couple months).

When you write code for React, on the other hand, you basically pretend the DOM is stateless and write your code as if you're writing server side templating code and rendering the entire page from scratch. The framework takes the data structure that the render process builds and efficiently forces the DOM to match what was rendered. At least that's the central concept. There are plenty of caveats.

If anybody has more specific questions, I'm happy to answer them.

[drcode]

Trying to figure this out, too.

[k__]

I liked the idea of polymer much more than the stuff react and angular did.

But the boilerplate of this system is just too much for me.