岁月如歌

HTML5 很火，忍不住也阅读了一遍 HTML5 spec, 发现除了对记忆力是个考验之外，增加的内容很少：

首先是 markup, 增加了 header, footer, section, nav 等元素，本质上和 div + class 无啥区别，考验的是记忆力和小学语文的功底。

其次增加了一堆 new APIs: Canvas/Web Storage/Drag-and-drop/Web SQL Database/Geolocation/Web Socket/Server-Sent Event 等等，这些内容的使用并无什么技术难点，翻翻规范手册，都是半天就能“精通”的。

追寻这些新技术，很容易让人有种走在技术前沿很牛逼的虚荣感。但实际上，会用 header/footer, 并不代表你就懂得了语义。就如多学了几个成语，并不意味着你的作文水平就有提高。

Geolocation 等 API, 也是如此。淘宝 UED 有几位设计达人，用的是 Photoshop 7.0. 倒是我这种半桶水，会紧跟潮流，装个英文原版的 CS4. 比喻不是很贴切，但从技能的深度上讲，有去学 Web SQL Database 的精力，不如去温习遍数据库基础教程。玩 Canvas 前，不如先去学学计算机图形学。否则永远是蜻蜓点水，以为走在前沿，其实只是凑个热闹，迟早成为舞台下的观众。

关注是可以的。有时间（我觉得大部分人其实都没时间），去尝尝鲜也是有益的。但是对于大部分营养不良的前端，推荐还是脚踏实地老老实实的去学一门传统编程语言，去把数据结构/基础算法/设计模式/数据库等等基础知识点给搞瓷实了再说。这样，等 HTML9 出来的时候，对你而言，无非就是淘汰了一些旧 API, 增加了一些新 API 而已。

对于武林高手，内功最重要。招式套路，只能街头赚个掌声。
对于程序员，真正的核心竞争力是基本功。
永远不要舍本逐末，否则你学的新东西越多，被淘汰的可能性反而越大。

这是 8 月 26 日在前端架构懒懒分会上的分享：slide@github（请用 Chrome 浏览）

掺杂了两个主要话题：一个是老生常谈的兼容性探测代码的写法，另一个是 JavaScript 比较语句中的隐性转换。

什么叫伪特性探测？看代码：

if(window.ActiveXObject) {
    // 一堆和 ActiveXObject 半毛钱关系都没有的代码
}

微探测的研究和探索精神都很值得推崇，但正式代码中尽量少用。质朴清晰更重要，能节省团队和自己未来的理解时间。

UA 不是恶魔，在大部分情况下，UA 是最可靠的。

探测代码的关键是尽量做到能自适应未来版本和自适应未知设备。针对特定版本的浏览器嗅探不会带来隐患：

if(ie < 7) {
    // 给 ie 增加 css 的 hover 支持
}

想想，上面的代码用特性探测如何写？可以把浏览器嗅探看成是打包了一堆特性的特性探测，只要这一堆特性是稳定的，不会给未来版本带来隐患，这时浏览器嗅探就是合理的，该用时就大胆用。（注意：大部分情况下，不带版本号的浏览器嗅探会给未来版本留下垃圾代码甚至隐患，要慎用。）

第二个话题是解释 a == b 的判断规律，详见 behind-a-gist.html#slide20. 弱类型动态语言，为了方便用户使用，一般都会自动进行类型的隐性转换。Douglas Crockford 认为 == 是糟粕，但实际上只要掌握了其中的转换规律，糟粕也可以成为精华。一个非常棒的应用是：

// 让 UA.ie 的默认值是 undefined, 在 ie 下，UA.ie = ie 的主版本号
// 这样，
if(UA.ie < 8) {
    // 针对 ie6 和 ie7 的代码
}

上面的 API 微设计，利用了 undefined < 8 为 false 的特性，有效避免了不少类库里的冗余写法 if(UA.ie && UA.ie < 8) { }.

探测代码 – 大道无形，道法自然。
a == b – 此中有真意，欲辩已忘言。

infinte 总是能给我们带来一些新思路新想法：更优雅的兼容

很不错的思路。不过实际操作时，并不好组织。比如：getOffset （获取 elem 相对 page 的偏移量）方法，对于高级浏览器，直接 getBoundingClientRect + win.scrollLeft/Top 即可。对于低级浏览器，比如 Safari 2, 得利用 offsetParent 不断向上回溯叠加。至此，利用文中提及的优雅兼容，可构造：

nullDriver = {};
dhtmlDriver = derive(nullDriver);
w3cDriver = derive(dhtmlDriver);

if(supportsGetBoundingClientRect) {
    w3cDriver.getOffset = function() { ... }
} else {
    dhtmlDriver.getOffset = function() { ... }
}

看起来很美妙，可是问题不这么简单。w3cDriver.getOffset 里，依旧还有浏览器差异，比如在同是 webkit, 桌面版和 ipad 版是有差异的，并且郁闷的是，这个差异不大，就那么一两行代码。传统写法：

w3cDriver.getOffset = function() {
    ...
    if(isAppleMobileWebkit) { // bug fix }
    else { // go on }
    ...
}

按照优雅思路，上面的代码很 ugly, 一个可能的重构： 阅读全文 »

看了 infinte 的这篇文章：再见，Button；你好，Command, 和我这半年的一些想法很相近，本质是对 UI Controls 的再次抽象分类。

传统的 UI 控件分类，体现的是 what is looks like, 比如 Menu, Button, Tabs, Toolbar, Dialog, Grid, Tree 等等。

近期新近的一些 UI 类库比如 jQuery EasyUI, 开始逐步抽象出 Draggable, Droppable, Resizable 等 Base 功能点，这些形容词已经逐步开始从 what to do, not what it is 层面开始抽象。虽然 EasyUI 最后体现出来的依旧是 Menu, Dialog, Tree 等传统 UI 控件，但抽象层次和代码组织等已经逐步演化。

前不久在 InfoQ 发过一篇文章：构建 UI 组件的新思路, 介绍了 KISSY 类库中，通过 Switchable 抽象，实现 Tabs, Slide, Album 等 UI 控件的思路，抽象的出发点是 what it really is, not what it is.

结合 infinte 的想法，画了一个还比较混乱的图：

或许 UI 3.0 的时代真的来临了！

比如 Autocomplete（自动补全组件）或 Suggest（搜索提示组件），可以这样实现：

    Suggest = Widget.combine(DataProvider, Overlay, Selectable);

在现实生活中，我们需要实现一个复杂实体时，经常用到的办法是将简单的实体组合起来。比如法拉利，是一堆汽车零件的组合。不同的法拉利，是选用的零件或组合方法有差异。类、继承等 OOP 概念，真的不是必须的。去掉后，世界照样清晰。

抽象、思考，思考、再抽象，多想想 what it really is, and what to do, not what it is. 我相信，未来是 UI 3.0 的世界！

infinte 的文章让我很激动，上面的想法还很不成熟，UI 3.0 是我杜撰的（当然，希望以后会说是我首创的，哈哈）。大家随意看看，极其欢迎讨论，提出你的想法与建议。

这是内部的邮件讨论，我觉得可以开放出来，让所有关心 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 时有可能导致的误用？
阅读全文 »