时代在进步，原本前端只是用来简单的数据显示以及提交数据到后端处理逻辑的地方，而随着SPA的发展，前端的逻辑也越来越是庞大，恰巧，今天看微博的时候，发现一个概念讨论的比较多，就是 Web Components，顺藤摸瓜，做了一些了解，发现 Polymer 这样一个或许是未来的东东，至少有一点，chrome将会原生支持。收集了一些资料，多家学习。

1. Polymer

Polymer由以下几层组成：

• 基础层（Foundation）——platform.js：基本构建块，其中大部分API最终将成为原生浏览器API。
• 核心层（Core）——polymer.js：基础层实现的辅助工具。
• 元素层（Elements）：包括构建于核心层之上的UI以及非UI组件。

1.1 基础层（platform.js）

其中，基础层使用了以下技术：

1. DOM Mutation Oberservers和 Object.observe()：用于监视DOM元素和简单JavaScript对象的改变。该功能可能会在ECMAScript 7中正式标准化。
2.  Pointer Events ：在所有的平台上以同样的方式处理鼠标和触摸操作。
3. Shadow DOM：将结构和样式封装在元素内（比如定制元素）。
4. Custom Elements：定义自己的HTML5元素。自定义元素的名字中必须包括一个破折号，它的作用类似于命名空间，为了将其与标准元素区分开来。
5. HTML Imports：封装自定义元素，包中包括HTML、CSS、JavaScript元素。
6. Model-Driven Views（MDV）：直接在HTML中实现数据绑定。仍没有标准化的计划。
7. Web Animations：统一Web动画实现API。

以上第3-5个API都是Web Components的一部分。很明显，Web Components对Polymer的重要性非同一般。

platform.js的作用在于代替浏览器提供这些API，它在经过充分压缩后仅仅31KB。而根据已公开的信息，我们还知道Polymer的目标之一就在于测试这些未标准化的HTML5 UI API。

1.2 核心层和元素层

Polymer本身非常像原生的HTML5：“attributes in, events out”。以UIwidget（widget）polymer-panels为例：

可以看出其结构非常“面向组件（component-oriented）”，所有组件都是HTML元素。有的元素本身并不提供UI，比如animations元素并不提供UI，但是你可以将它与UI元素相关联，实现动画效果。此外，Polymer的很多widget中都内建了响应式设计，也就是说，他们会依平台的不同变化成最适合的形状。

1.3 互操作性

Polymer设计得像菜单一样，可以按需选择。得益于Web Components，其元素都具有非常高的互操作性。在I/O大会上我们就看到了这样的例子：Mozilla项目中的元素X-Tag（同样基于Web组件）与Polymer协同得非常好。

1.4 什么时候可以使用Polymer？

Polymer目前仍是一个Alpha预览版，因此不建议在公共项目中使用。但是，作为一个开源项目，你可以随时使用它的代码。

1.5 Polymer与其它Web框架相比如何？

Polymer并不是为终结其它框架而生，相反，现有的这些框架也可以构建在同样的基础层之上。如果你已经尝试过Ember.js、AngularJS这样的UI框架，一定会发现很多API非常熟悉。AngularJS甚至在在Twitter上宣布：”Angular将基于Polymer开发widget，这会是一个双赢的方案。“

2. Polymer究竟意味着什么？

没有人会想要使用框架，我们只是想高效地开发Web UI而已，只不过框架恰恰满足了我们的需求。与之相反，原生HTML却缺乏这些功能：

• 丰富的widget集。在我看来，Web Components最大的意义莫过于此。得益于Web Components，我们将能轻易获得众多widget，随意使用。
• 用户界面布局。我对 CSS Grid Layout寄予了厚望，Grid Layout是原生的HTML，自然它也能与Web Component很好地协同工作。
• widget间的“粘合剂”（比如数据绑定）。

就目前看来，各大框架仍难以互相兼容：各自使用各自的工具链、继承API、widget基础构架等等。本文中描述的开发模式，以及ECMAScript 6中的类与模块，都指明Web开发的未来应该是更高的互操作性。这对Web开发生态系统的益处显而易见。

Google Polymer以及Web UI框架