Material design with Polymer

Clearly software should be written more efficiently so that his phone is still capable. The LG G2 is a two year old smartphone. It's pretty unacceptable that something doesn't run well on it, so long as the underlying software (operating system and browsers) are up to date.

k__• 12 years ago

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.

Kiro• 12 years ago

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

cletusw• 12 years ago

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.

wildpeaks• 12 years ago

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

ryanSrich• 12 years ago

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

sahat• 12 years ago

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

drcode3• 12 years ago

Trying to figure this out, too.

grayrest3• 12 years ago

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.

drcode3• 12 years ago

Is it feasible to use react.js and polymer together in an app?

I mean, is it possible to do this without sacrificing the benefits of reactjs by simply writing state-ish code in reactjs?

(At first blush, I can't think of a sensible way of doing this...)

malandrew10• 12 years ago

As much as I want to like web components, Google's behavior with this new "standard" has been very suspect. The "intent to ship" thread from February this year is something everyone should check out.

Here is Maciej Stachowiak's response to Google's irresponsibility on the intent to ship announcement:

http://lists.w3.org/Archives/Public/www-style/2014Feb/0103.h...

Shoehorning more and much junk into HTML, a markup language with only two types, strings and children, will likely result in bad juju. It may be great for setting things up declaratively, but not for controlling something with state that changes over time. It will serve to reduce what's possible instead of enabling others to explore ideas on the web that are currently only possible in native.

What we need is a low-level retain mode scene graph with a JavaScript API. DOM is a pretty inadequate replacement for a real scene graph. DOM is simply too costly to manipulate and re-arrange and I don't see what WebComponents does to fix that problem.

This might delay the crisis the web feels relative to native, but will just punt the problem a few years down the road at best.

Lastly, some required reading for anyone who wants to educate themselves on the Shadow DOM:

http://acko.net/blog/shadow-dom/

malandrew10• 12 years ago

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?

zghst2• 12 years ago

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.

malandrew10• 12 years ago

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

SneakerXZ• 12 years ago

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

Inufu• 12 years ago

Angular can use Polymer components.

lebek• 12 years ago

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

malandrew10• 12 years ago

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?

andybak• 12 years ago

I'm sure I want to defend this particular implementation without looking at it more but 'declarative' is quite a nice programming style as long as you can easily override it with 'proper' code when you hit it's limits - see Django's models, forms, admin etc.

rnnr• 12 years ago

What are you taking about? It's still javascript, javascript encapsulated in elements. You can view source code, make your own, and release it is custom elements.

Best thing happend in web in a long time IMHO.

tkps• 12 years ago

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.

rictic• 12 years ago

I'll also add that I was skeptical at first as well. It was only after playing with the actual code for a while that I started to understand, and have actually ported a couple functions over to simple elements.

One of them is an input debouncer. A lot of my UIs lately want to instantly react to the user's actions, but I don't want to fire off a request to the server for every keystroke. The solution is a debouncer, a function or component that takes the input from the user and does something only once the input hasn't changed in some period of time (e.g. there's no sense sending a search request while the user's typing because it will most likely be instantly stale).

So where before I did something like:

    onInputChanged(debouncer(function(debouncedInput) {
      // a bunch of code to fire off a request to the server
      // then render the result back onto the page
    }));

Now I'm doing:

    <input value='{{rawInput}}'>
    <my-debouncer input='{{rawInput}}' output='{{debouncedInput}}' delay='150'><my-debouncer>
    <my-server-request input='{{debouncedInput}}' output='{{results}}' error='{{error}}'></my-server-request>
    
    <div>{{results.length}} results</div>
    <template repeat='{{result in results}}'>
      <div>{{result.name}} - {{result.count}}</div>
    </template>

This is a toy example, but the long and the short of it is that I'm seeing more code reuse and a much simpler development experience.

sedachv• 12 years ago

"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• 12 years ago

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

crdblb• 12 years ago

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.

malandrew10• 12 years ago

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)

Material design with Polymer

Related Stories