构建前端UI组件的新思路是什么？

    前端UI组件，目前流行的实现方式大多源自传统客户端的UI设计体系。无论是早期的Bindows，还是近几年兴盛的ExtJS，其UI组件都在模仿客户端软件，代码实现建立在复杂的继承体系上。
  好处是可以构建出和客户端体验一致的一整套UI组件，但弊端也很明显：组件长得都差不多，代码则继承太深，牵三挂四，不够轻便。   如何才能让前端UI组件轻便灵活起来呢？首先得意识到Web UI设计有自己的独特性。
  Web页面可分为两种：一种是以展现信息为主的Web页面（web page），另一种是以操作信息为主的Web应用（web app）。对复杂的Web应用来说，可以采用ExtJS等类库来构建类客户端体验。
    但是，越来越多的Web应用已逐步脱离模仿客户端的阶段，开始从Web 的独特性出发，将传统UI组件的功能融入到Web页面中。 举一个例子：国内的Web邮箱，无论是163还是QQ邮箱，都会让人联想起Outlook或Foxmail等客户端软件。
  这种模仿成本很高，然而带来的效果个人觉得却不是很好。  反观Gmail，整体UI设计，简明轻快，但功能一点也不逊色。在Gmail里，看不到Tree，看不到DataGrid，脱离了这些传统UI组件的框框，将功能融入到Web元素里，反而让用户更自然、更高效。
   前端UI组件的Web特性，需要我们打破传统思维，换一个角度，重新去思考UI组件的基本组成要素。  换什么角度去思考？什么角度才是合适的？这离不开具体场景。下面以一个实例来说明。
   在淘宝页面中，以下是几个常见的UI组件： 传统思路里，我们会构建三个组件来实现： Slide（轮播）组件 Tabs（标签页）组件 Carousel（旋转木马）组件 Tabs组件，我相信任何一个前端开发工程师最多半天都能搞定，而且还能把延迟触发、动态加载等特性也给实现了。
    Slide组件也不难。Carousel组件看起来稍微复杂一些，但熬上一个通宵研究研究循环的实现，也不是什么大难题。 上面是传统思路。新思路是：我们真的需要分三个组件来实现吗？ 仔细思索，我们可以提取出这三个组件的共同点： 都有一组触点（Triggers）。
   Slide的触点是数字，Tabs的触点是标签头，Carousel的触点是小图。   都有一组面板（Panels）。就是内容区域。 通过触点可以让面板切换（Switch）。
   上面的几条里有一个很重要的概念：切换。所有这些组件的共同点是可切换的。如果我们实现了一个可切换（Switchable）组件，上面三种组件就都是特例了。 根据上面的抽象，很容易实现switchable。
    js： function Switchable(container, config) { … } S。mix(Switchable。prototype, { init: function() { } switchTo: function() { } next: function() { } prev: function() { } }); 上面仅实现了基本的切换功能，我们可以进一步通过插件来实现更多功能： plugin-autoplay。
    js – 提供自动播放功能。 plugin-effect。js – 提供切换时的各种特效。 plugin-circular。js – 提供循环切换功能，比如Slide自动播放到第5张时，能无缝循环播放到第1张。
   plugin-lazyload。js – 提供数据的延迟加载功能。   插件的实现在JavaScript这种动态语言里是小菜一碟。至少有两种思路，一种是埋好钩子（hooks），插件根据钩子进行扩展： S。
  mix(Switchable。prototype, { init: function() { … S。each(Switchable。  Plugins, function(plugin) { if(S。
  isFunction(plugin。init)) { plugin。init(); } }); }, switchTo: function(index) { … this。fire(‘beforeSwitch’, {toIndex: index}); … } });。
    。