标签:http io 使用 ar java strong for 数据 sp
时代在进步,原本前端只是用来简单的数据显示以及提交数据到后端处理逻辑的地方,而随着SPA的发展,前端的逻辑也越来越是庞大,恰巧,今天看微博的时候,发现一个概念讨论的比较多,就是 Web Components,顺藤摸瓜,做了一些了解,发现 Polymer 这样一个或许是未来的东东,至少有一点,chrome将会原生支持。收集了一些资料,多家学习。
Polymer由以下几层组成:
其中,基础层使用了以下技术:
以上第3-5个API都是Web Components的一部分。很明显,Web Components对Polymer的重要性非同一般。
platform.js的作用在于代替浏览器提供这些API,它在经过充分压缩后仅仅31KB。而根据已公开的信息,我们还知道Polymer的目标之一就在于测试这些未标准化的HTML5 UI API。
Polymer本身非常像原生的HTML5:“attributes in, events out”。以UIwidget(widget)polymer-panels为例:
可以看出其结构非常“面向组件(component-oriented)”,所有组件都是HTML元素。有的元素本身并不提供UI,比如animations元素并不提供UI,但是你可以将它与UI元素相关联,实现动画效果。此外,Polymer的很多widget中都内建了响应式设计,也就是说,他们会依平台的不同变化成最适合的形状。
Polymer设计得像菜单一样,可以按需选择。得益于Web Components,其元素都具有非常高的互操作性。在I/O大会上我们就看到了这样的例子:Mozilla项目中的元素X-Tag(同样基于Web组件)与Polymer协同得非常好。
Polymer目前仍是一个Alpha预览版,因此不建议在公共项目中使用。但是,作为一个开源项目,你可以随时使用它的代码。
Polymer并不是为终结其它框架而生,相反,现有的这些框架也可以构建在同样的基础层之上。如果你已经尝试过Ember.js、AngularJS这样的UI框架,一定会发现很多API非常熟悉。AngularJS甚至在在Twitter上宣布:”Angular将基于Polymer开发widget,这会是一个双赢的方案。“
没有人会想要使用框架,我们只是想高效地开发Web UI而已,只不过框架恰恰满足了我们的需求。与之相反,原生HTML却缺乏这些功能:
就目前看来,各大框架仍难以互相兼容:各自使用各自的工具链、继承API、widget基础构架等等。本文中描述的开发模式,以及ECMAScript 6中的类与模块,都指明Web开发的未来应该是更高的互操作性。这对Web开发生态系统的益处显而易见。
标签:http io 使用 ar java strong for 数据 sp
原文地址:http://www.cnblogs.com/ricky52529/p/4003047.html