Google’s Polymer and the future of web UI frameworks

By -
Updates:


At Google I/O 2013, Google presented a new web user interface (UI) framework called Polymer. The way it works is indicative of the future of all web UI frameworks.



Polymer



Polymer is composed of the following layers:

  • Foundation (platform.js): Foundational building blocks. Most, if not all, of these APIs will eventually become native browser APIs.

  • Core (polymer.js): Helpers complementing Foundation.

  • Elements: UI and non-UI components built on Core.



The Foundation layer (platform.js)



The Foundation layer comprises the following technologies:

  1. DOM Mutation Oberservers and Object.observe() (probably ECMAScript 7): for observing changes to DOM elements and plain JavaScript objects.

  2. Pointer Events: handle mouse and touch in the same manner, on all platforms.

  3. Shadow DOM: encapsulate structure and style inside elements (e.g. custom ones).

  4. Custom Elements: define your own HTML5 elements. The names of custom elements must contain a dash, which is a simple way of namespacing them and distinguishes them from standard elements.

  5. HTML Imports: package custom elements. Such packages include HTML, CSS and JavaScript.

  6. Model-Driven Views (MDV): Does data-binding directly in HTML. Not yet in the process of being standardized.

  7. Web Animations: API unifying several of the web’s animation approaches.


APIs 3–5 are part of Web Components, a component model for the web. Web components are the most important foundation of Polymer.


platform.js shims these APIs on browsers where they are not (yet) available. It is only 31KB (if minified and gzipped). One of the declared goals of Polymer is to field-test HTML5 UI APIs before standardizing them.

Layers: Core and Elements



Polymer itself is almost like native HTML5: “attributes in, events out”. One example of using the UI widget polymer-panels:

    <polymer-panels
        on-select="panelSelectHandler"
        selected="{{selectedPanelIndex}}">
    </polymer-panels>

Its architecture is very component-oriented, its components being HTML elements. Some of the elements don’t even have a user interfaces themselves. For example, animations are elements (you can nest them etc.), they have no user interface, but instead point to UI elements that they animate. Responsive design is built into many widgets, which means that they will transform so that they work best on a given platform (cell phone, tablet, desktop, etc.).

Interoperability



Polymer is designed to be à la carte: you pick and choose what you need. Thanks to Web Components, its elements are also highly interoperable. In one demo given at I/O, an element coming from the Mozilla project X-Tag (that is similarly based on Web Components) was shown as working inside Polymer.

When can I use it?



Polymer is still pre-alpha and thus not yet really ready for public consumption. It is, however, developed in the open and you can already play with its code.

Polymer versus other frameworks



Polymer is not the framework to end all other frameworks. Instead, existing frameworks can be based on the same foundations. In fact, the functionality of most of the APIs that were mentioned above should look familiar to you if you have already used a UI framework such as Ember.js or AngularJS. As for AngularJS, a recent tweet explains how it will evolve:

AngularJS will use Polymer for its widgets. It's win-win.


What does it all mean?



Nobody actually wants to use frameworks. We only want to build web user interfaces efficiently and frameworks help. The most important pieces missing from native HTML are:

  • A rich set of widgets. In my opinion, this is the biggest deal about Web Components (and, to a lesser degree, about Polymer). We finally get a large set of widgets that we can use anywhere.

  • User interface layout. I have high hopes for CSS Grid Layout here. Grid Layout is native HTML, so it complements Web Components quite naturally.

  • “Glue” to combine widgets (e.g. data binding).


Currently, frameworks are largely incompatible: they usually come with their own tool chain, inheritance API, widget infrastructure, etc.
The developments described in this post, along with ECMAScript 6’s classes and modules, point to a future where everything will be much more interoperable. The benefits for the web development ecosystem are obvious.

Resources



If you want to know more about Web Components and Polymer, you have the following resources at your disposal:

Comments

Post a Comment

Popular posts from this blog

Steve Lopez and the Importance of Newspapers

By -
Image
It has been one year since I cancelled my subscriptions to The New York Times and the Los Angeles Times . In that time, I continued to read both publications online. My assessment of this experiment is that reading newspapers and journalism online is vastly inferior to the hard copy thrown on my porch each morning. So I restarted my subscription to the Los Angeles Times and I have made it a point to buy The New York Times as often as I pass one of those coin boxes or my local news stand. The catalyst for this re-evaluation resulted from catching the film, The Soloist on cable last week. I liked the movie, although the scenes I found most interesting were the ones that showed columnist Steve Lopez at work. I realized the book was sitting in my “to-read” stack, so I pulled it and began reading. The book, as I expected, is better than the film. Lopez clearly addresses the revolution occurring in journalism, and worries about his future with the paper even as he researches and writes...
Keep reading

Ideas for fixing unconnected computing

By -
I traveled quite a bit recently and got exposed to a negative aspect of current technology: Things work well if you have a solid internet connection with no traffic limits and are plugged into a power outlet. Otherwise, things do not work well at all. This blog post describes the problems that arise and suggests solutions. Managing data traffic Cell phones are quite good at conserving traffic, laptops much less so. This becomes a problem when your laptop has a mobile connection (e.g., via tethering or in a hotel with data caps). I once accidentally started iTunes in such a situation and immediately used up my daily allowance of traffic. Similarly, mobile email is frugal with traffic (only the current folder is updated, attachments are only downloaded on demand, etc.), desktop email is usually not. How can this be handled better? I’d like to see three traffic modes for all operating systems: “full”, “restricted”, “minimal”: In full traffic mode , all data transfers are allowed and happe...
Keep reading

Omar to kill me

By -
Image
  The sentence “ Omar m’a tuer ” is unintelligible French, as if it had been written by an illiterate person. At first sight, Mme Ghislaine Marchal —the author of those words in blood—seems to be saying that she had been killed by Omar in her villa at Mougins (Alpes-Maritimes). But why would that dying French lady have used such poor grammar? On that flimsy evidence, in 1991, the Moroccan gardener Omar Raddad was condemned and jailed. But he persisted non-stop upon his innocence. In 1998, he was liberated, and now lives in Morocco. A recent analysis of DNA specimens from the scene of the crime provides new facts. Four males, none of whom was Omar Raddad, have left traces of their presence. Will the real murderer be identified at last?
Keep reading