Material design with Polymer (polymer-project.org)

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

http://imgur.com/AyactvC

What OS/Browser combo?

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

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

Clearly you need a more modern phone.

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.

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

Trying to figure this out, too.

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.

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

Angular can use Polymer components.

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?

    var ajax = document.querySelector('polymer-ajax');
    ajax.addEventListener("polymer-response", function(event) {
        assert.isTrue(event.detail.response.feed.entry.length > 0);
        done();
    });

    <polymer-ajax 
      url="http://gdata.youtube.com/feeds/api/videos/"
      params='{"alt":"json", "q":"chrome"}'
      handleAs="json"
      auto
    ></polymer-ajax>

    "Best thing happend in web in a long time IMHO."

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.

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

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

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