Plans for supporting Web Components in AngularJS and Ember.js

Web Components [1] are an upcoming standard for custom HTML5 user interface elements. Those UI elements will eventually become interchangeable between frameworks. Now the people behind AngularJS and Ember.js have described their plans for supporting Web Components.

Below, you’ll see mentions of Google’s new framework, Polymer [1]. It is built directly on top of Web Components. One of Polymer’s goals is to help refine and fully figure out that standard.

AngularJS

In an entry on Google Groups, AngularJS co-creator Miško Hevery writes:

We're in early stages of designing Angular 2.0, but some of our goals are:

• Angular will use the underlying web platform features available to it (e.g. Node.bind, template integration, Custom Elements, etc...)
• Web Components (Polymer, Ember, or any other framework/library) will work seamlessly within Angular apps and directives.
• Components written in Angular will export to Web Components (to be used by Polymer, Ember, or any other framework/library).

We're working actively with the MDV, Web Components, and Polymer teams to make sure that our approaches remain compatible as all these projects evolve (and they will still evolve).

Ember.js

Yehuda Katz, one of Ember‘s creators, has written a Gist with the title “Ember and Web Components”:

The goal of this document is to describe how Ember could adopt semantics similar to web components and MDV. It relies on the HTMLBars templating engine, which allows Ember to directly control how templates are parsed and converted into DOM. [HTMLBars uses the same Handlebar syntax as current Ember, but compiles it to code that constructs DOM nodes instead of code that concatenates strings. That leads to the above mentioned increase in control.]

It builds on the work of Rafael Weinstein and the Polymer team, and attempts to harmonize that work with Ember's architecture.

Ember's scope is much wider than components, and is mostly focused on application architecture and URL-driven design. Today, we need a system to manage the lifecycle of data-binding and custom views, so we include such a system alongside our architectural tools.

Once the web provides its own tools for managing components, and eventually data bindings, Ember will embrace them and transition away from our Ember-specific solution. This document is how we get from here to there, continuing to build ambitious and stable applications in the meantime.

[...]

The document is a great primer on how Web Components differ from Ember.

Reference

1. Google’s Polymer and the future of web UI frameworks [describes both Web Components and Polymer]