Below, you’ll see mentions of Google’s new framework, Polymer . It is built directly on top of Web Components. One of Polymer’s goals is to help refine and fully figure out that standard.
We're in early stages of designing Angular 2.0, but some of our goals are:
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).
- 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).
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.]The document is a great primer on how Web Components differ from Ember.
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.