Material design with Polymer
polymer-project.org
polymer-project.org
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)
https://www.dropbox.com/s/qiqbrs0d55qgf6e/Screenshot%202014-...
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?
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?
It's not even clear from this example, what is done with the JSON data fetched here. It's not assigned to a variable or returned by a callback. The script below the element in fact uses globals to access the code, since that is basically what `document.querySelector` does. Putting stuff in the DOM is the equivalent of saving all your variables on the window object and then accessing them with `window.myDomElement`, but in a more verbose, indirect and non-performant way.
var ajax = document.querySelector('polymer-ajax');
ajax.addEventListener("polymer-response", function(event) {
assert.isTrue(event.detail.response.feed.entry.length > 0);
done();
});
Best thing happend in web in a long time IMHO.
<polymer-ajax
url="http://gdata.youtube.com/feeds/api/videos/"
params='{"alt":"json", "q":"chrome"}'
handleAs="json"
auto
></polymer-ajax>
Furthermore, it involves putting data in the DOM (e.g. the `params` property above), where getters and setters now need to go through the inefficient steps of serializing plain old javascript objects when setting a property and parsing a string as a JSON object when getting a JSON property.
"Best thing happend in web in a long time IMHO."
The simple fact that the DOM is the only thing that is not accessible to web workers should be a massive red flag. DOM is popular with noobs because it represents global state, which is easy to work on when you're starting out or working on small projects, but simply does not scale. This approach is effectively paving a cowpath that has a sign next to it that reads "hic sunt dracones".
If I instantiate a new XHR request in a function scope, the XHR request object gets allocated on the heap. I then typically bind callbacks to the events I care about within the same scope. Again, all are added to the heap because that's how mutable objects are allocated in JavaScript. That function scope eventually returns freeing the variable reference to that XHR object on the stack for that function scope. This XHR object will eventually be available to be garbage collected once all the bound events are fired and the callbacks execute and return. At this point the results have been passed on to their destination and no references should (ideally) remain pointing to the instantiated XHR object. The next time the GC sweeps, it can (theoretically) de-allocate the memory assigned for the XHR request and the memory for the event-bounded callbacks.
With the approach above however, the XHR request is instantiated via a web component and a reference is held indefinitely until either the window is terminated/refreshed or the `polymer-ajax` element is removed from the DOM. I suspect that not only will the memory for the XHR object never be freed, but neither will the memory allocated to the anonymous or named functions bound to the events, since internally the XHR object may still hold a reference to these callbacks (unless the implementation of XHR in question specifically nullifies the reference to callbacks that will never be called again).
We're basically now back at having developers unknowingly performing malloc() in a declarative XML-based syntax, and they are now required to perform free() manually via the removeChild() method on the parent DOM element if they want to get that memory back.
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>
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.
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
}));
<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>
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.
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/
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.
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 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...)
[1] http://www.polymer-project.org/docs/polymer/polymer.html#lif...
That said, I don't expect it to be common since you'd basically be building a React component with a Polymer shim and getting almost no leverage out of Polymer. I suppose you could write some code to parse out the html template and turn it into React.DOM equivalents but that seems like a lot of effort.
All React integrations I've seen are the result of introducing React into a legacy codebase or they're using React on a component that's rendering a very large DOM subtree and taking advantage of React's O(N_view) instead of O(N_model) scaling and batched updates for perf wins over current KVO techniques.
You could do the polymer look and feel with the react update model via famo.us (disclaimer: I work for famo.us). Famo.us also plays pretty nicely with Ember.js (tutorials coming soon) and React.js.
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:
But the boilerplate of this system is just too much for me.