编写网页脚本某种程度上说，不仅仅是光光技术方面，同时需要考虑到很多非技术因素，例如使用动画带给用户体验方面的影响。

而从实际情况下看来，很多为了所谓效果而使用的动画，其实这往往会适得其反。同时，还有很多新手对于动画还保留着莫名的恐惧感。

这里推荐的这本书的名字叫 《jQuery 1.4 Animation Techniques: Beginners Guide》 。但并不要被它的书名所迷惑，总体阅读下来这本书还是需要有一定的基础。Amazon 上有读者就抱怨，‘\"beginning\" is a little bit of a misnomer’，不过这不影响这本书的所提供的营养价值。

不过还是要抱怨下，本书的后两个章节在我个人看来有些鸡肋。使用 CSS3 以及 Canvas 等「新技术」完成动画并不是什么新鲜的技术，所以加入这些内容未免有些凑数的嫌疑。

三百多页的书，所要搭载的内容显得简单直接而富有价值（看目录其实可以抽看自己感兴趣的章节，似乎并不影响对前后文的理解）。抽空阅读下本书，无论是否使用 jQuery 都会对相关的知识面会有些帮助。

PS，由于时间差以及 jQuery 版本飞快增长的关系，推荐使用 1.6 版本，因为这个版本针对动画有所优化（ 详细 ）。

-- EOF --

请原谅我取了个如此有争议的标题，原文的标题是《浏览器不是什么》。我个人觉得作者有点脱离题目，但这并不影响其想要陈述的观点。

可用性 一直是我们前端争论的焦点之一。但仔细想想，我们是否值得为那些连见都没见到过的盲人阅读器或者那些自行禁用 JavaScript 的用户投入额外的、大量的开发成本去「满足」他们？

-- Split --

原文地址： http://blog.istvan-antal.ro/2010/10/what-is-not-a-browser/ 发声 。而后过了段时期，出现了能够同时使用扬声器和声卡的应用程序。

话说回来，现在是否还有人关心自己的机子上有无声卡吗？我想恐怕已经没有。甚至我觉得人们已经遗忘了机箱中的扬声器了。

例如，我从来没有见过某款游戏因为机子上没有声卡而自动关闭其声音－－当然，如果我耳朵听不到那是另外回事情（老外的这个说法比较冷）。

说了那么多，上述故事和浏览器以及 JavaScript 的故事非常的相似。不同的是现在的开发人员，在开发应用的时候，仍然在考虑如果没有脚本支持的这一情况。

其实和当年的声卡普及情况差不多，JavaScript 发明于 1995 年（已经是 15 年前了）。当时其在浏览器中的份额不到 1%，而且当时的用户（甚至开发者）都认为这玩意是可有可无的。

我的观点是，每个 Web 应用程序应该能够尽可能的运行在不同环境中，但它并不说明无条件的迁就于某一情况，在任何情况下都表现一致。

例如，在浏览器没有 JavaScript 支持的情况下，新闻类站点仍然可以显示其主要内容（新闻），同时不保证那些依赖 JavaScript 的相册脚本，仍然还能正常工作。

我们现在称之为「浏览器」的应用程序必须为：它能理解 HTML、能使用 CSS 渲染页面、同时能驱动 JavaScript 脚本。某个应用程序只能够完成上述一项或者其中两项功能，那么这压根就无法称之为「浏览器」。

例如，搜索引擎理解 HTML（以及部分 CSS 防止作弊），我们只需要提供内容让其收录 －－ 同时它不需要过多的了解 GUI 相关的设计。

从内容方面考虑，其实我只关心两件事物：搜索引擎和浏览器。首先，我第一步需要做的就是创建具有语义的 HTML（这对于 HTML 来说并不容易），然后再使用 CSS 排版并且使其支持现代浏览器，然后再使用 JavaScript 增加针对 IE 的 CSS 规则（很明显原作者非常讨厌 IE）。

我的上述工作流程有时候会收到指责，因为这样必须让老旧的浏览器具备 JavaScript 支持才能引入针对其自身的 CSS 规则。同时情况可能变得模棱两可，我真的不认为我们称之为「浏览器」的玩意竟然不支持 JavaScript，哪怕是那些可以称之为古董的玩意（暗指 IE 吗？）。

总而言之，我们的思路应该为未来而开发，而非迁就过去（We should develop for the future not for the past.）。

我们应该为大多数（用户）而非少数服务。如果我们的用户中有 0.1% 禁用了 JavaScript，那么在我看来，我们可能不值得去耗费大量的开发时间去争取那些 0.1% 的用户。

同时另一个事实是，如果我们让用户觉得在没有使用 JavaScript 的情况下也能使用我们的应用，那么他们会毫不犹豫的禁用它（类似 noscript 插件 ）。那么这样，我们推进 Web 的前进几乎是不可能的，我们和用户都会认为 JavaScript 是额外的附属品。

最后，其实我想说明的是：在着手实际开发之前，我们首先规划那些有限的资源（例如时间、人力等）－－ 它们的计划投入和实际产出是否能符合我们的预期。

-- EOF --

面对繁杂的 JavaScript 库，其实到最后其实是 设计哲学的问题 。这篇文章将要介绍的是篇名为 KISSY 的 JavaScript 库。

渊源

前面也说过，JavaScript 库已经足够的多。可能看起来又要重新建立一套 JavaScript 库，有点重复造「轮子」的嫌疑，而 KISSY 的出现只是顺水推舟的结果。

过多的话语已经难以解释清楚 KISSY 的渊源， 这里有个详细的说明 。

风格

KISSY 的多数设计哲学源自 YUI3 ，同时也借鉴 了其他 JavaScript 库，我们可以看它的典型调用：

(function() {
    var S = KISSY, Y = YAHOO.util, Dom = Y.Dom,
        descList = S.DOM.children('#slideFocus ul.desc-list li');

    S.Slide('#slideFocus', {
        contentCls: 'pic-list',
        navCls: 'thumbs-list',
        activeTriggerCls: 'current',
        effect: 'scrollx',
        easing: YAHOO.util.Easing.easeOutStrong
    })
    .on('beforeSwitch', function(ev) {
        S.each(descList, function(desc, i) {
            desc.style.display = i === ev.toIndex ? 'block' : 'none';
        });
    });
})();

我们可以看到若隐若现的其他框架的风格，例如 jQuery 和 mootools，总之使用 KISSY 你会「重新找回书写 JavaScript 的快感」。

（来自 BlueDream ， 查看大图 ）

从框架结构上说，KISSY 是相对精简的一套库，核心（core）非常的精炼。甚至你可以考虑基于 KISSY 扩展出适合自己的框架，例如针对 iPad 等等的特定库。

未来

KISSY 是开源项目，基于 MIT 协议发布。因此，KISSY 的未来掌握在广大开发者手中。相比目前现有的成熟的框架库，KISSY 还是个初生的新儿，因此尤其需要大家的支持。

目前 KISSY 已经部署到淘宝的大部分页面（包括首页），承受着不同浏览器以及大规模访 问量的考验。有理由相信 KISSY 能部署到更多的地方，让业界一起分享我们在前端方面的 心得和经验。

如果你有任何疑问，可以 访问 KISSY 的项目主页 ；同时官方站点、文档等方面也正在筹备和编写中。KISSY 的成长离不开广大同行的支持，我们的愿景是：

小巧灵活、简洁实用，使用起来让人感到愉悦

最后，感谢 玉伯 的努力，KISSY 的成长他付出了很多。

-- EOF --