YUI 3 学习笔记：YUI Base

基于 github 上 yui 3.0 2009-06-19 version

YUI Base 包含 7 个 submodules:

展开的详细图请看：yui-base-full.png

一些好的想法

1. 基础框架非常清晰，核心代码包括 YUI 对象的构造函数 和 use 方法，配合 add 等辅助成员，实现了 Sandboxing 和 Modularity 机制。
2. YUI(config).use(...), config 参数非常丰富，win, useBrowserConsole, filter 等参数设计得很有才。
3. YUI().use('*', function(Y) {...}), Y 是 YUI 对象的一个实例，可以按需挂载不同的 modules 到 Y 上。module 可以有版本号，这使得 YUI 3 组件的不同版本可以在同一页面共存。
4. Y.log可以使用 Firebug 的 console. 跨浏览器调试代码更方便了。
5. 很喜欢Y.Array, Y.Object的 api, 不多不少，正是我想要的。
6. YUI 3 终于从底层支持 Chaining 特性，可以重拾当年使用 jQuery 的快乐了。
7. Y.UA依旧坚持采用 userAgent 探测法，和我的想法一致。

一些疑惑

1. Sandboxing 机制让 YUI 的各个实例独立，但这会造成每个 use 方法内都有一份 Y，对内存的消耗如何权衡？感觉至少可以改进为，让 yui-base 模块内的方法共享。Ext 里面有 fly 享元方式，不知道 YUI 3 Team 是如何权衡 Sandboxing 特性和性能消耗。非常想质问一句：Sandboxing 真的这么重要吗？真的会有一个页面使用同一模块不同版本的情况？如果有的话，这个页面可能已经够糟糕。需要的也许不是兼容，而是彻底更新。
2. 通过YUI.prototype.applyTo(id, method, args)，可以在 Y2 的作用域内调用 Y1 的方法。这种可能性也许有，但直觉上觉得这个 applyTo 可能会和 with 等 JavaScript 中的 Bad Parts 一样，看起来很好，实际上却会带来害处？
3. trim(s)方法为何不放在Y.String下？还有 later 方法也没必要再在 Lang 上登记。既然是重构，就没必要和 YUI 2 的 API 保持一致。也许这能减少 YUI 2 到 YUI 3 的升级成本，但感觉可以将兼容代码单独拎出去成为一个 upgrade module.
4. Sandboxing 对模块的兼容，必须以 YUI 3 Seed 的自身兼容为前提。假设 YUI 3.5 Seed 做了大调整，不兼容 YUI 3.4 Seed 了，那 Sandboxing 带来的模块兼容也就没了。感觉 YUI 3 想求得一颗解决兼容性的银弹，然而， Sandboxing 究竟是否银弹，还需要时间来淘汰或证明。

总之，YUI 3 让我很激动。