Material design with Polymer

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)

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.

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
    }));

    
    
    
    
    {{results.length}} results
    
      {{result.name}} - {{result.count}}