这是内部的邮件讨论，我觉得可以开放出来，让所有关心 KISSY 的前端都参与进来，集思广益。

―――――――――――――――――――――-
From: 射雕 [lifesinger@gmail.com]
Date: 2010/7/7

先说一下近期更新，主要是在完善 ks-core, 变化如下：

1. ks-core 原来只包含 kissy-dom-event, 近期借鉴 ext-core / jquery / mootools, 觉得 core 的概念可以扩大，目前 ks-core 已调整为包含以下组件：

kissy,  dom, event, node, cookie, json, ajax, anim

大家讨论下，这样是否妥当？比如 cookie 究竟应不应该放在 core 里？ks-core 究竟应该包含哪些组件？

2. node 模块已经完善好，提供了：

S.one  -  根据 css selector, 返回 Node 对象
S.all  -  根据 css selector, 返回 NodeList 对象

上面两个方法，和 S.get / S.query 是遥相呼应的，唯一的不同是，get/query 返回的是原生 DOM Node/NodeList. 详细可以参考 node docs

KISSY.Node/NodeList 类似 jQuery 全局对象，但只包含 DOM/Event 等方法，我们可以这样写代码：

S.one('#test').parent().next().html('<p>').on('click', function() { /* ... */ });

基本上和 jQuery 的语法风格是一样的，甚至 api 也是一样的。

对 node 模块，大家给给建议，目前 KISSY 的 api 方式是否合适？是否有更好的组织方式？
另外，虽然 api 和 jQuery 类似，但并不全同。如何避免 jQuery 熟手在使用 KISSY 时有可能导致的误用？

3. dom, node 中，有许多方法都是集 getter 和 setter 于一身，比如：

DOM.attr(elem, 'title');  <--  getter
DOM.attr(elem, 'title', 'ok');   <-- setter

还有 css/html/text/val 等等一系列方法。目前 KISSY 的一个 api 设计原则：Get First, Set All. 意思是：

DOM.css('.test', 'color', 'red');  <-- 基于 set all 原则，这句会给所有 class 为 test 的元素添加 color: red 样式
DOM.css('.test', 'color');         <-- 基于 get first 原则，这句只会返回第一个 class 为 test 的元素的 style color 值

jQuery 的 api 也有类似的处理，但未统一。YUI3 里是 Set All + Get All, YUI3.DOM.getStyle('.test', 'color') 会返回数组，包含所有值。

对于 Get First, Set All 的 api 设计，大家是怎么看的？从严谨和完备上看，YUI3 的方式很不错，但从实现和实用的角度来看，jQuery 的大部分 get first 的 api 非常好用。毕竟，操作 DOM 属性时，我们什么时候需要去获取一个数组呢？

希望大家能集思广益，都说说自己的看法。对于 KISSY 来说，现在修改 public api 成本还比较低，等以后一旦正式发布了，public api 就覆水难收，修改成本很大了。

-----------------------------------------------------------------
From: 射雕 [lifesinger@gmail.com]
Date: 2010/7/8

总结一下，主要讨论点：

1. ks-core 应该包含哪些组件？主要有两种观点：
a. 保持精简，只包含 kissy-dom-event
b. 和 jQuery/ext-core 类似，包含常用组件（kissy, dom, event, node, ajax, anim 等）

2. node 的问题：
a. 链式风格对 YUI2 代码风格的冲击
b. 性能问题

3. API 和 Get-First-Set-All 设计的讨论：
a. 精简短小的 jQuery 形式命名 vs. 传统的 getXXX/setXXX 风格
b. Get First vs. Get All

4. KISSY 与 TB 的关系

我的一些想法：

1. ks-core 的问题。我倾向包含 kissy, dom, event, node, ajax, cookie, json, anim, 主要考虑点是和 jQuery/Ext-Core 对 core 的理解保持保持一致：core 包含的是常用组件。因此，问题转换为：哪些组件是经常被大量调用的？我想到的是上面这些组件。除了 cookie 组件有点犹豫，其它组件对于 UI 类库来说，都是标配了。

2. node 的问题。jQuery 有很多亮点，链式风格是其中最亮的一点。这种风格已经被所有流行前端类库采纳，无论是 YUI3 还是 Ext, 都内置了对链式风格的支持。目前在和后台开发的接触中了解到，不少开发对 jQuery 都或多或少有了解，也很容易能接受链式风格。我们担心的两种风格的冲突，可能根本就不是问题。就如一个男孩，可能会同时喜欢上多种 style 的女孩一样。

node 的性能问题。KISSY 目前采用的是类 jQuery 的原生 push 机制，性能基本上不是问题，函数层级之间的调用也不多。这一点尽可放心，目前测试下来，node 的性能问题不是问题。大家可以看下 src/node/node-attatch.js 的实现，就明白了。

3. api 采用 xxx 还是 getXXX/setXXX. 这是令人非常纠结的问题。但就如 OO 一样，我越来越觉得 getXXX/setXXX 是传统 OO 强加给 JS 的。我们不妨来看看 w3c_core.html 里，setXXX/getXXX 只有很少几个方法，这是为何呢？根源在于原生方法大部分用内置的 setter/getter 转换成属性来实现了，比如：

var id = elem.id;
elem.id = 'value';

对于以上代码，是因为内部自动处理了 getter/setter, 目前因为 JavaScript 的 getter/setter 还未被广泛支持，所以各大前端类库无奈下用下面的方式来提供 api:

function getId(elem) { return elem.id;  }
function setId(elem, id) { elem.id= id; }

上面的代码其实是一种无奈。在 JavaScript 新版本里，我们可以写成：

      S.Node.prototype = {
        get id(){
            return this._id;
        },
        set id(val){
            this._id = id;
        }
      };

最后暴露给用户的就是直接操作 id 属性。

等浏览器都支持后，我相信类库 API 面临一次洗牌。

jQuery 目前的做法是最接近完美的：采用 xxx，将 getXXX/setXXX 合二为一。在我看来，这是非常睿智的面向未来的一种 api 设计。因此 KISSY 也借鉴了 jQuery 的 api 命名风格。

Get-First 还是 Get-All 的问题，这可能是以上问题里面最让人纠结的。我简直不愿意谈，感觉这很可能会成为 KISSY API 里的老鼠屎。问题是，为何 jQuery 一直坚持？近期和 John Resig 的邮件里，Resig 从未对这一点后悔过，坚持 Get-First 是非常合理的。站在使用者角度，大部分情况下，我自己的使用经验也是如此：DOM 操作的 getter, 获取属性等值时，很少需要去获取一个数组。但目前我还未无法完全说服自己接受 Get-First 的设计原则。

4. KISSY 与 TB 的关系。这个已经很明了，TB 是基于 KISSY 的一个应用，翻译成代码是：

KISSY.app('TB');

具体可以参考：app docs
淘宝的前端架构也变得更简单清晰：

KISSY -> 业务通用类库 -> 页面具体模块

TB 和 TShop, Hitao 等从代码组织是同级的，只是 TShop 等应用可以调用 TB 的方法，TB 相当于其它淘宝业务模块的通用 Util.

欢迎大家继续各抒己见，碰撞才能产生火花！

建议继续学习：

1. 构建前端 DSL    (阅读：2693)
2. 用 CSS3 Transitions 实现动画    (阅读：2346)
3. 行进中的前端类库：KISSY    (阅读：2207)
4. 将你的 KISSY 程序移植到服务器端    (阅读：2081)
5. 微博适合讨论什么？    (阅读：1890)
6. What really it is, not what it is    (阅读：1696)