Times in progress, the original front-end is only used for simple data display and submit data to the back-end processing logic, and with the development of the SPA, the logic of the front end is more and more huge, coincidentally, today, when looking at Weibo, found a more conceptual discussion, is the WEB components, clues, Have done some understanding, found polymer such a may be the future east, at least a little, chrome will be native support. Collected some information, a number of learning.
1. Polymer
The polymer consists of the following layers:
- Base Layer (Foundation)--platform.js: basic building blocks, most of which will eventually become native browser APIs.
- Core tier (CORE)--polymer.js: an auxiliary tool for the implementation of the base layer.
- Element Layer (Elements): Includes UI and non-UI components built on top of the core layer.
1.1 Base Layer (platform.js)
Among them, the base layer uses the following technologies:
- Dom Mutation Oberservers and Object.observe (): Used to monitor changes in DOM elements and simple JavaScript objects. This feature may be formally standardized in ECMAScript 7.
- Pointer Events: Handles mouse and touch operations in the same way on all platforms.
- Shadow DOM: Encapsulates structures and styles within an element (such as a custom element).
- Custom Elements: Define your own HTML5 element. The name of a custom element must include a dash that acts like a namespace in order to differentiate it from standard elements.
- HTML Imports: Encapsulates custom elements, including HTML, CSS, and JavaScript elements in the package.
- Model-driven Views (MDV): Data binding is implemented directly in HTML. There are still no standardized plans.
- Web animations: Unified Web Animation Implementation API.
The above 第3-5个 APIs are part of the Web Component. Obviously, the importance of WEB components to polymer is unusually important.
The role of Platform.js is to provide these APIs instead of browsers, which are only 31KB after being fully compressed. And based on the information that has been disclosed, we also know that one of polymer's goals is to test these non-standardized HTML5 UI APIs.
1.2 Core layer and element layer
The polymer itself is very much like the native HTML5: "Attributes in, events out." Take Uiwidget (widget) Polymer-panels as an example:
[HTML]View Plaincopy
- <polymer-panels
- on-select="Panelselecthandler"
- selected="{{selectedpanelindex}}">
- </polymer-panels>
It can be seen that its structure is very "component-oriented (component-oriented)" and that all components are HTML elements. Some elements themselves do not provide a UI, such as the animations element does not provide a UI, but you can associate it with a UI element for animation. In addition, many of polymer's widgets are built with responsive design, that is, they will change depending on the platform to the most suitable shape.
1.3 Interoperability
The polymer is designed like a menu and can be selected on demand. Thanks to Web Components, its elements are highly interoperable. At the I/O conference we saw an example: the element X-tag in the Mozilla project (also based on Web Components) works very well with polymer.
1.4 When can I use polymer?
Polymer is still an alpha preview, so it is not recommended for use in public projects. However, as an open source project, you can always use its code.
How does the 1.5 polymer compare to other web frameworks?
Polymer is not intended to end other frameworks, but the existing frameworks can also be built on the same base layer. If you've tried a UI framework like Ember.js and Angularjs, you'll find a lot of APIs familiar. Angularjs even announced on Twitter: "Angular will be based on the polymer development widget, which will be a win to the solution." “
2. What exactly does polymer mean?
No one would want to use the framework, we just want to develop the Web UI efficiently, but the framework satisfies our needs. In contrast, native HTML lacks these features:
- A rich set of widgets. In my opinion, the most important thing about WEB components is this. Thanks to the Web Components, we will be able to easily access a large number of widgets, free to use.
- User interface layout. I have great hopes for CSS grid layout, which is native HTML, and naturally it works well with the Web component.
- A "binder" between widgets (such as data binding).
For the time being, the frameworks are still difficult to be compatible with each other: using their own toolchain, inheriting APIs, widget infrastructure, and so on. The development patterns described in this article, and the classes and modules in ECMAScript 6, indicate that the future of web development should be higher interoperability. The benefits to the Web development ecosystem are obvious.
Google polymer and the Web UI framework