WebComponents-面向未来的组件标准

   2015-06-26 0
核心提示:对于前端开发者而言,W3C组织制定的HTML标准以及浏览器厂商的实现都是“鱼”而 不是“渔”,开发者在需求无法满足的情况下通过现有技术创造了各种组件,虽然短期满足了需求但是由于严重缺乏标准,导致同一个组件有成千上万的相似实现但 它们却无法相互重用,这很大程度上制约了组件化的最大价值-重用,Web Components则在组件标准化方面向前迈了一大步。

 

首先需要说明的是这不是一篇 Web Components 的科普文章,如果对此了解不多推荐先读《A Guide to Web Components》。 有句古话-“授人以鱼,不如授人以渔”,如果把组件比作“鱼”的话,对于前端开发者而言,W3C组织制定的HTML标准以及浏览器厂商的实现都是“鱼”而 不是“渔”,开发者在需求无法满足的情况下通过现有技术创造了各种组件,虽然短期满足了需求但是由于严重缺乏标准,导致同一个组件有成千上万的相似实现但 它们却无法相互重用,这很大程度上制约了组件化的最大价值-重用,Web Components则在组件标准化方面向前迈了一大步。

WebComponents-面向未来的组件标准

现状与困境

组件化给前端开发带来了极大的效率提升,组件化的UI框架也因此层出不穷,从EXTJsYUIjQuery UI ,再到 BootstrapReactRatchetIonic等等等等等等,几乎每年都有很多新的UI框架冒出来,它们或者借鉴或者颠覆其他已存在的框架。简单对比一下就会发现这些框架的很大一部分模块在功能上是重合的,但也仅仅在功能层面重合,代码层面确完全不兼容。

接下来选择 jQuery UI、KendoUI 以及 Bootstrap 中的Dialog组件从初始化、方法调用以及事件响应方面进行简单的对比。

jQuery UI

  1. // 初始化 
  2. $( "#dialog" ).dialog({ 
  3.   dialogClass: "no-close" 
  4. }); 
  5.  
  6. // 显示 
  7. $( ".selector" ).dialog({ show: { effect: "blind", duration: 800 } }); 
  8.  
  9. // 关闭事件 
  10. $( ".selector" ).on( "dialogclose",  function (e, ui) { 
  11.   // do something... 
  12. }); 

Kendo UI

  1. // 初始化 
  2. $("#dialog").kendoWindow({ 
  3.   actions: [ "Minimize""Maximize" ] 
  4. }); 
  5.  
  6. // 显示 
  7. var dialog = $("#dialog").data("kendoWindow"); 
  8. dialog.open(); 
  9.  
  10. // 关闭事件 
  11. var dialog = $("#dialog").data("kendoWindow"); 
  12. dialog.bind("close",  function (e) { 
  13.   // do something... 
  14. }); 

Bootstrap

  1. // 初始化 
  2. $('#myModal').modal({ 
  3.     keyboard: false 
  4. }); 
  5.  
  6. // 显示 
  7. $('#myModal').modal('show'); 
  8.  
  9. // 关闭事件 
  10. $('#myModal').on('hidden.bs.modal'function (e) { 
  11.   // do something... 
  12. }); 

简单对比可以发现,几乎完全相同的功能在接口层面完全不兼容,导致使用者从某个实现切换到另一个实现时需要非常高的成本,这就是目前Web组件化方面无序和缺乏标准的一个写照。

再来看目前浏览器“内置”组件的现状,由标准化组织建立 HTML4、HTML5 等各种标准,浏览器厂商按照标准实现“内置”组件并声称兼容某某标准,开发者遵循标准来使用组件,使得代码可以在不同的浏览器里通过相同的方式来使用组件。

以“内置”组件video来简单示例:

  1. // 初始化(直接写 
  2. var video = document.createElement('video'); 
  3.  
  4. // 播放 
  5. video.play(); 
  6.  
  7. // 播放事件 
  8. video.addEventListener("play"function () { 
  9.    // do something... 
  10.  }, false); 

相比使用各种组件框架来说,“内置”组件也是由不同的开发者(浏览器厂商)开发,但是由于遵循了相同的标准使得“内置”组件的使用在跨浏览器方面的成本大幅降低。

综上所述,组件框架目前无序、缺乏标准以及低效复用方面的问题需要通过组件标准化来解决,而Web Components则是标准化的一个很好的选择。

面向未来的组件标准

Web Components 的出现给组件标准化带来了很好的契机:

  • WEB组件目前仍然依靠各种类似"Hack"的方式来模拟,模拟方式也各有不同,很难统一和标准化,而 Web Components 则直接提供了标准化的组件定义方式,这是组件标准化的基石,使得未来的组件能够统一创建、方法调用、事件监听、属性访问等。
  • 基于标准化的组件定义方式,我们便可以像W3C等标准组织一样来定义组件标准,无需再依赖、等待“内置”组件,这也使得我们获得了“渔”的能力。

以上述的例子为例,未来可能会有一小撮人成立某个组件标准化组织-X,X的职责就是根据WEB组件的使用现状以及潜在的新需求来规范一个组件,包括组件的名称、方法、属性、事件。

例如《Dialog规范1.0》

  • 组件名:x-dialog
  • 属性:title
  • 方法:show hide
  • 事件:hide show

随后出现的UI框架宣称支持《Dialog规范》,但在实现上完全没有制约,可以是完全不同的实现方式、或者更好的性能、更炫的UI,而对于开发者而言,只需要写如下代码即可:

  1. // 初始化(或者如下代码) 
  2. var dialog = document.createElement('x-dialog'); 
  3.  
  4. // 获取和设置title 
  5. var title = dialog.title; 
  6. dialog.title = title + '-_-'
  7.  
  8. // 显示 
  9. dialog.show(); 
  10.  
  11. // 关闭事件 
  12. dialog.addEventListener('hide'function( e ) { 
  13.     // do something... 
  14. }, false); 

当用户不满意某个 Dialog 的实现而需要切换到其他实现版本时只需要引入不同的实现库,而不再需要重构代码。

跨端的组件标准

集鹄在跨端组件实践 - 移动时代的前端一文中提到了跨端组件的概念。

跨端组件的实现同样面临着标准化的问题,Web Components 的标准化只规范接口,而底层的实现是完全自由的,自由到你可以使用 Web 技术来实现也可以使用 Native技术。

同样以 Dialog 为例,开发者可以在 Android 中用 Java 或者在 iOS 中用 Objective C 来开发声称兼容 《Dialog规范1.0》的组件,此时,Web 开发者的那段调用 Dialog 的代码不仅仅在 浏览器环境有效,在 Native 依然有效,而且调用的是 Native 实现,能够获得更为出色的性能。

总结

回顾浏览器的发展历史,也曾经历混乱和无序,随着W3C标准化组织的出现这一局面有了翻天覆地的变化,而对于Web组件而言,Web Components 的出现才仅仅是这一变化的开始,随着更为复杂的多端环境的出现,组件标准化还有着更大的想象空间。

 
反对 0举报 0 评论 0
 

免责声明:本文仅代表作者个人观点,与乐学笔记(本网)无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
    本网站有部分内容均转载自其它媒体,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责,若因作品内容、知识产权、版权和其他问题,请及时提供相关证明等材料并与我们留言联系,本网站将在规定时间内给予删除等相关处理.

  • Handlebars模板引擎介绍和开发指南
    Handlebars是一个Javascript模板引擎,能让你轻松高效的编写语义化模板,它是Mustache模板引擎的一个扩展,Handlebars和Mustache都是弱逻辑的模板引擎,能将Web前端的视图和代码分离,降低两者之间耦合。
    06-26
  • KendoUI2014移动调查报告:HTML5vs原生之辩
    KendoUI2014移动调查报告:HTML5vs原生之辩
    Telerik Kendo UI一直比较关心移动开发领域的使用情况,在最新的2014 HTML5全球开发者调查中,Kendo UI面向3500+个开发者,从普通程序员到CIO/CTO,从大型企业到小型企业,对他们的移动开发偏好展开了调查。
    06-26
  • AppCan:HybridApp技术已经成熟
    AppCan:HybridApp技术已经成熟
    在移动开发技术里,Native App和Web App之争一直没有停息,而介于Native和Web之间的Hybrid混合App异军突起,以其接近Web App开发简单、跨平台能力,以及接近Native App功能和性能表现逐渐为开发者们所接受,那么,现在Hybrid App发展到了什么程度呢?正益无线技术支持总监邱革节在接受51CTO记者采访时表示,Hybrid App技术已经成熟。
    06-26
  • 什么是ShadowDom?
    什么是ShadowDom?
    如果我需要把每个自定义的按钮都放到iframe里,你是什么感觉,会不会疯掉?所以,我们需要一些更好的东西。事实上,大部分的浏览器已经变相地提供了一种强大技术去隐藏一些实现细节。这个技术就是所谓的“shadow DOM”。
    06-26
  • 使用ShadowDOM创建Web组件
    使用ShadowDOM创建Web组件
    Web Components(组件)标准是一系列最新推出的标准,它可以被用来创建可被复用的Web部件,当页面中所使用的Web部件被更新为新版本时不必修改 页面中其他任何代码。这里所说的部件,是一种可实现与用户之间的交互的可视化组件,开发者可以使用HTML代码与JavaScript脚本代码来开发这些 部件。Web Componnts标准定义如何开发这些部件。
    06-26
  • GooglePolymer以及WebUI框架的未来
    开发者Axel Rauschmayer在自己的博客上详解了Google Polymer的设计理念与组成架构,深得Polymer开发者的认同。他认为Polymer这样高互操作性的设计才应该是Web开发的未来。
    06-26
  • WebComponents实例:移动UI组件库GMU介绍
    GMU(Global Mobile UI)是百度前端通用组开发的移动端组件库,具有代码体积小、简单、易用等特点,组件内部处理了很多移动端的bug,覆盖机型广,能大大减少开发交互型组件的工作量,非常适合移动端网站项目。
    06-26
  • 移动应用新趋势:离线WebApp
    移动业界已经最终放弃了不分时间、不分地点为用户提供互联网连接服务的幻想。我们也看到了一系列新型产品与服务,它们的兴起标志着我们将以更为灵活的方式在无法接入网络时继续享受功能与便利。
    06-26
  • 2014年Web开发的7个转变方向
    2014年Web开发的7个转变方向
    很多读者喜欢预测网页设计趋势,让自己能够在网页设计、甚至网络发展中保持先机。找准每一年的发展趋势很重要。那么,2014年会有怎样的发展?我们一起来分析。
    06-26
  • 移动WebApp开发必备知识
    移动WebApp开发必备知识
    移动设备的用户越来越多,每天android手机的激活量都已经超过130万台,所以我们面向移动终端的WebAPP也开始跟进了。本文主要介绍webapp的开发与调试的相关知识和经验,以及给出几种可选的解决方案。
    06-26
点击排行