Exciting news - the 0.6.0 version of the webcomponents.js polyfills has been released. A lot of critical fixes are in this release - highlights are described below.

Bringing modern Web standards to old browsers is always challenging, sometimes nearly impossible, but always beneficial for a graceful migrations approach.

Before his latest talk in Helsinki, Andrea managed to accomplish something unexpected and relatively simple: he manged to make his Custom Element's document.registerElement polyfill compatible with Internet Explorer 8 too, together with the already wide list of old Mobile platforms supported since the very beginning.

As result, when it's needed, and with a little extra effort, it is now possible to create components that won't break the old, even if not so good, Web platform.

The next release of Polymer, 0.8, is going to be a doozy. It's the first release on the "heading towards production" track and it's going to have some pretty massive differences from previous versions. So what exactly is new, and what's changing?

Note: This data was gathered primarily from reading the Polymer 0.8 Primer which is very, very extensive. I'm just hitting the highlights. Also note that any of this could change before the final release is cut.

ES6 introduced some goodness to JavaScript, and Weak or Set Maps are part of it. However, it is not entirely possible to polyfill these features without risking to be a bit obtrusive and not so backward compatible. When webcomponents.js initially went out, it was lacking support for older browsers and bringing in external arbitrary polyfills that were not playing so well together with few other libraries. On top of that, it was bringing features that if used on Android 2 phones or other cheap devices, where not performing so well and hence not that useful as part of the library.

In order to avoid these little obstacles and brings at least Custom Elements out of the entire Web Components family in older Mobile browsers too, Andrea Giammarchi decided to invest some time and create a document.registerElement only polyfill with the goal of supporting as many mobile platforms as possible, and in a reasonable size over decent performance.

The Ember community is no stranger to componentization. The team for this JavaScript framework has been working hard on the implementation of Ember.Components as well as integrating these seemlessly with standard Web Components.

The boundaries between Ember.Components and a Web Components are beginning to blur more and more. Making these two component models work together should be fairly easy.

It looks like custom elements, and web components in general, are beginning to break through into general developer consciousness, as I see more and more articles and talks discussing what they are, what they are good for, and how to make them.

As they’re not yet being used heavily in development, however, I think there’s a good opportunity to define best practices in the way we use them. In this post I want to propose a best practice method for writing custom elements: I’ll do that by comparing two methods for creating custom elements, along with the advantages and drawbacks of each.