最近在学习yui3

为什么选择yui3。

因为他已经脱离一个库（library），更像一个platform。包含了loader，以及重新定义的类结构。

最明显的好处，就是以后不需要在页面顶部声明一堆的script src 了。这些都可通过javascript脚本配置

来实现 (yui3 的自动加载)。我没确定sina 现在的javascript是用谁家的方案（或者自产）。但是

应用loader这个理念已经是广泛验证了。（更不用说和yahoo关系非同一般的那些标杆性网站）。

而且，loader不是只针对js的。连css也可以load。

 

多个js文件造成的并发连接过多？

 

这个问题可以分开来看，在网站的环境下，由于是互联网，可以考虑combo。在企业系统中，

暂时可忽略这个问题。毕竟大多是局域网环境；而且分散的js，浏览器也会cache。（反而combo因为

是容易产生动态url去request，可能导致浏览器不得不去下载）。这是我现在的理解。

 

组件结构

把每个独立功能用类、组件的方式分拆出来，声明依赖，是个清晰的、可复用结构。

 

 

虽然用了一阵子的yui2。但是对yui2冗余的代码结构方式不太能接受，例如一个事务的绑定，也要

用YAHOO.util.Event.addListener(ele, "click", onContextMenuTargetClick); 这么长的代码。

相比而言，现在Y.on("click",func,ele);是简洁很多了。虽说可以对yui2做个声明来转换（

如：var Y.on = YAHOO.util.Event.addListener ） 但谁也不想从头梳理这些namespace吧……

所以用YUI3的很大一部分原因，就是他的ns变得简洁一些了。之前大部分用mootools来处理

js，现在已经在准备各类基础的组件，以期一次转换。以后只需要用：

<script src="http://yui.yahooapis.com/3.1.1/build/yui/yui-min.js" type="text/javascript"></script>

 

剩下的，全都是javascript，动态的去组织了。

 

最近还做了一项工作。

将yui2-menu (2.8.1) 作为组件引入yui3了。由于yui2-menu基于Overlay 。而yui3的Overlay已经做了重新定义。

因此只能把yui2的container-core引入（当然也做了一番调整）。

整个修改下来的感觉就是，其他的引用，大多可以通过compat.js来达到。但是……有个事情变了，就是Event的

处理方式。尤其是CustomEvent。

 

最大的区别是：

//假设this 是 A

this.event1.subscribe(this.onEventFunc,obj,this); //subscribe 是仿yui2写的，compat里面有转换

 

在yui2里

onEventFunc 可以取到 this = A

而yui3里

onEventFunc取到的 this 貌似就是 Event.target 。

 

这点令我困惑（ 因为之前未解读过Yui2 Event 的原理）