如果你还不了解 NodeJS，请参照 NodeJS.org，简言之：
Node.js 是服务器端的 JavaScript 运行环境，它具有无阻塞(non-blocking)和事件驱动(event-driven)等的特色，Node.js 采用 V8 引擎，同样，Node.js 实现了类似 Apache 和 nginx 的web服务，让你可以通过它来搭建基于 JavaScript 的 Web App。
你可以通过我们前些天 team 内的一个分享来了解下 NodeJS
nodejs-kissy 项目
KISSY 是淘宝网开发的一款轻巧灵活的JS框架，如今已经是1.1.5版本，并在淘宝网广泛应用，在浏览器端给我们带来更加清新的体验，今天让我们更进一步，我们发起了nodejs-kissy 项目，你的 KISSY 程序可以无缝移植到服务器端了 ^_^
译者按：我们时常能看到不同JavaScript库/框架之间的各种比较，但这次 YUI3 架构师和 jQuery 之父的直接对话却非常难得，也是暗涌澎湃精彩至极，实在忍不住，翻译出来以飨各位读者，希望对那些有志于开发“库/框架”的同仁们有所启迪。
题目：和jQuery和Mootools相比，YUI3如何提升其影响力？
作者：John Resin(jQuery之父)
译者：拔赤
原文：http://www.quora.com/How-could-YUI3-improve-its-image-compared-to-jQuery-MooTools-etc/
外一篇：zakas的回应
YUI3 已经超越 YUI2，并向 jQuery 看齐了，那么 YUI3 如何提升其影响力呢？关于这个问题，有些回答似乎有些跑题，问题是“怎样提升 YUI 的影响力”（不错的问题），然而大部分的回答却在攻击 jQuery。
我从两方面来回答这个问题：1，YUI 应当如何改进，以便更多的人来使用，2，YUI 如何提升才能改善和 jQuery 的竞争力。
我不得不承认，和其他 JS 库相比，YUI 的确很赞，不管是代码级的工作、大量优秀的文档、demos、blog 文章、视频教程等等，真的相当出色。而其他的 JS 库则对这些方面不太用心，而且我认为这些内容是一个成功开源项目最重要的组成部分，然而 YUI 却没有更成功的占领市场，对此我一直很不解。
在这里，为了便于各位理解，我暂作几个假设：1，目前的 YUI3 版本已经“足够优秀”，2，YUI 文档和论坛也已经足够完善，足以吸引更多的用户来使用 YUI3。
基于此，我做一些简短的评价：
1，分散的域名应该合并成一个，正像别人指出的那样，维护太多站点往往会适得其反、吃力不讨好。
2，多代码库应当合并成一个代码库，不错，人们仍在使用 YUI2，YUI3 的 API 和 YUI2 却有着天壤之别，而 YUI 将来只会在 YUI3 上取得成功（YUI 团队固执的维护着 YUI2 不会帮助 YUI “更成功”的）
3，YUI 的引入方式太多，应当缩减至一种。人们应当从 YUI().use 开始接触 YUI（假设这些人真想深入使用 YUI）。首页只保留一个要点即可：应当这样来引入 YUI，<script src=”http://yuilibrary.com/yui-min.js”></script>，这样就清晰了很多。
简单讲，YUI 项目应当保留一个整体的方向性，重点太分散，则会事与愿违。
如今，如果 YUI 直接和 jQuery 进行竞争，YUI 和它的子项目的运作方式都需要做出调整。因为现在的 YUI 项目运作方式与 YAHOO 的工作方法是背道而驰的。鉴于目前的管理方式的极差的操作性，YUI 项目着实是一个不幸的牺牲品。
原文作者是我的好友，转载此文以缅怀08年集结号的缘分，以及她所带来的那些让人难忘的故事。。。
很早就想写这么一篇文章了。我离开中国雅虎已经一年有余，在中国雅虎工作的那段时光是我最珍贵的回忆之一，和以前的同事吃饭聊天的时候也经常会怀念一下中国雅虎，怀念得多了，就觉得不如写篇文章好好回顾一下。很多事情虽然已经过去，但有些话不说出来，到底意难平。
从 2008年7月份毕业之后加入了中国雅虎，到2009年9月份跟着中国雅虎工程技术部全体人员“被跳槽”到淘宝，我在中国雅虎只呆了一年多的时间。这个时间并不长，甚至可以说短得可怜，所以我或许不是写这篇文章的最佳人选。但是，中国雅虎给我的是人生第一份工作，凭着初生牛犊对社会的好奇心，我对公司的文化、技术、架构、流程包括产品设计等各个方面都有浓厚的兴趣和广泛的了解，从这个方面来说，由我来写这篇文章也是合适的。而且最重要是，我愿意把它们写出来。
在进入正文之前，先开诚布公地声明一下：众所周知，中国雅虎是阿里巴巴的一个子公司，所以文中我也不必遮遮掩掩地用“某电子商务公司”来代替。而且我对阿里巴巴这个公司有意见，不代表我对阿里巴巴的员工有意见，如果伤了某些人的感情，先说声抱歉，请您发扬一下风格，在这里也“拥抱变化”一下。
正文：
我在 2007 年底通过校园招聘拿到了中国雅虎的 offer ，但实际上在我2008年7月份入职的时候，中国雅虎的品牌虽然还在，公司却已经在7月9日和口碑网合并了，改名叫做“雅虎口碑”。尽管这样，到现在为止我还是厚着脸皮说自己原来是雅虎的，因为那里让我着迷和真心喜欢的东西全部都是紫色的，而不是橙色的。
雄厚的技术实力
中国雅虎最好的一个地方就是它和 Yahoo 全球共享同一个技术平台，那是一个有十几年历史的技术平台。Yahoo 的技术文化不如 Google 的工程师文化那么有名，但 Yahoo 在相当长的一段时间内都是互联网的旗帜，吸引了全球大量的技术牛人加入，Yahoo 的技术平台就是他们的知识、经验和心血日积月累的成果。尽管阿里巴巴收购了中国雅虎，但是在技术方面并没有对中国雅虎做出太大的改造（幸好没有改造），所以就工程师来说，每天更多接触到的还是 Yahoo 的东西，而不是阿里巴巴的东西，对我影响最大的也正是这些东西。 Read the rest of this entry »
浏览器天生不适合写游戏，因为浏览器运行效率实在太蜗牛，即便在canvas上作一些动画也非常吃力，CPU烧的厉害，js没办法编译成机器码再运行，图形编程也鲜有硬件加速，即使用hack手段兼容了一些老旧浏览器，效率始终是最大的瓶颈。在html5之中情况好一些，很多动画api已经内嵌在浏览器的骨肉之中，效率有了不少的提升，但离传统游戏的执行效率还有很大差距，不过前些日子网上盛传的基于html5的雷神之锤，让我们看到了希望，不是html5的希望，而是webGL的希望，似乎我们应该摈弃很多已经根深蒂固的观念…… 那么……
对于传统dom层面的动画，已经可以使用transitions来做，KISSY和YUI已经实现了transition，写了一个放烟花的小demo，webkit下会调用native transition api，速度明显快很多。
同样，cavans层面的动画，webkit依然把其他浏览器甩在身后，这个小demo是一个裸露的小游戏，看下100个方块以内你能命中多少。有几点需要记录下：
1，目前对于复杂动画的要求不要太高，速度远达不到我们的要求
2，canvas编程最好是基于库，我用的http://raphaeljs.com/
3，写动画还是要温习一下一些数学公式的
4，过程中要细心体会最纯粹的编程美感，没有dom的世界是如此之清静
以上
前端开发中编码的问题一向是让人头疼的，尤其是在以gbk为基础页面编码的淘宝，情况更加复杂，除了常见的页面文件的编码之外，对不同编码js/css文件的引用、meta的charset设置、表单提交的URL编码等问题的处理稍微粗心就会出问题，特别是ajax中的编码转换，始终缺乏统一方便的解决方案，今天我们就分享两个js转码的常见案例的解决。首先，我们应当了解编码相关的一些基本概念：
1，gbk和utf-8是不兼容的两种编码，unicode是万国码码表的简称
2，utf-8编码是unicode的一种实现
3，js引擎的内码是unicode
4，URL编码是将字符裸码以16进制显示出来，每个字之前冠以“%”
5，因此，URL编码的结果只唯一和字符当前存储的裸码有关，原则上转换过程不查任何码表
6，unicode码表中，中文字符的范围为4E00到9FA5
7，js所识别的unicode表示形式为“\uXXYY”
8，js中的encodeURI是对字符串进行URL编码，编码基于utf-8的裸码
9，js中的escape是对字符串进行unicode转码，转码基于unicode码表
10，form表单提交会对参数进行URL编码，编码所基于的裸码类型和页面编码有关
基于以上知识点，可以初步得出：
1，js无法直接进行基于gbk裸码的url编码
2，js无法直接进行转换为’\uXXYY’形式的unicode编码
而在ajax过程中，通过js传参经常会遇到需要gbk url编码和直接传输unicode编码的情况，尤其当通过json传数据的时候。在php中，对一个对象进行json_encode转换的时候，会自动将中文转换为unicode，这里的unicode可以直接被js识别，因此在js中是只要将json串转换为对象即可，不用解码，php代码为：
$a = array(‘a’=>11,’b'=>’淘宝’);//json
echo json_encode($a);//输出 {“a”:11,”b”:”\u6dd8\u5b9d”}
而php中进行url编码默认是以utf8的方式
//输出 %E6%B7%98%E5%AE%9D ，这里是utf8方式的URL编码
echo urlencode(‘淘宝’); Read the rest of this entry »
什么是KISSY
http://github.com/kissyteam/kissy
什么是loader
用过yui的人一定不会对yui-loader陌生，yui doc中对loader是如此描述的：
The YUI Loader Utility is a client-side JavaScript component that allows you to load specific YUI components and their dependencies into your page via script. YUI Loader can operate as a holistic solution by loading all of your necessary YUI components, or it can be used to add one or more components to a page on which some YUI content already exists.
所以，简单讲，loader就是一个处理js脚本依赖关系的加载器，实现了按需加载、延迟加载、加载相关联的js等功能，其中按需加载大大简化了开发web app的复杂度，延时加载使得domReady的时刻大大提前，飞速提升UI渲染速度，加载关联的js则使开发者不必去关注脚本排序，简化库的使用。颗粒化设计的库则必然需要loader来控制库的易用性，从yui2到yui3，这种趋势更加明显。因此，当KISSY开始走颗粒化的道路时，loader则几乎成了必须组件。
页面加载脚本的方式
如果页面中以script标签引入外部脚本，是阻塞式的加载，不管脚本加载完成先后，页面总是从上到下依次执行script脚本。如果是异步加载脚本，脚本加载完成后则立即执行脚本内容。因此，异步脚本的载入顺序和执行顺序是无关的，是和脚本载入完成的时刻有关系。而如果要处理异步脚本的依赖关系，除了要对脚本载入开始时刻进行排序，也要对载入完成后的回调进行排序。因此，脚本中的逻辑要写入回调函数中，以便排序只用。KISSY提供的简单沙箱可以模拟这种回调的包装。
多loader并存？
如果页面很复杂，我们很自然的期望每个沙箱拥有一个loader，loader之间的加载可以并行，每个loader只处理各自的依赖，这种设计是为了解决页面逻辑的解耦，页面中的每个app之间的耦合降到最低，整个页面不会因为一个app的加载障碍而影响其他app的运行，yui即是这种设计，这种设计最常用的场景是用在门户首页，页面没有固定的维护者，每个人都可以随时添加删除模块，页面最终渲染结果不受某个app的影响。因此在越复杂越变化频繁的页面中，多loader是一种先进的设计，而在普通页面中，多loader机制形同鸡肋。KISSY的设计宗旨是简单易用，因此，单loader模式基本可以满足目前国内门户的所有要求，而在配置combo的前提下，单loader的性能要远超过多loader的场景的。 Read the rest of this entry »
RT
第一种境界：了解各类框架、并熟悉甚至精通某种框架的使用，但并未看过框架代码、或者并不理解框架核心细节的实现，甚至不清楚框架的设计原理、基本思想、适用场景。这类人的编程思路始终限制在”特定框架“的范围内，尽管能使用框架写出满足需求的代码。
这种人停留在”会用“框架的阶段，他们很在乎各种框架的比较，且一定要对框架分出三六九等。这些人写代码的思路始终没有离开”功能实现“。
第二种境界：精通各类框架，熟读各类框架源码，非常了解各类框架的核心功能的细节实现，熟识各类框架的优缺点和适用场景，权衡利弊后理性选择相对适用业务逻辑的框架，并能根据业务的需要有针对性的修改框架核心代码使之更加满足可维护性和性能上的需求，但依然要基于某种框架进行业务开发，框架的范围依然停留在组织代码、第一层的抽象和组件的模块化的范围内。
这种人停留在”精通“框架的阶段。他们的特点是有能力去对框架做有针对性的二次封装，甚至有些人有能力重写框架核心代码，但依然要基于某种框架做扩展和hack。这些人写代码的思路始终在”代码管理和框架级别的抽象“。
第三种境界：异常精通各类框架，同时精通业务逻辑，娴熟的对业务逻辑进行抽象，具备传统软件工程师的基本素质，有能力设计业务框架，并根据业务逻辑的需要重写合适的底层框架。这类人的编程思路已经完全脱离“框架”的限制，达到一种真正自由超然的境界。
这种人已经达到技术方和需求方一致认可的“专家”级别，技术功底扎实、同时精通业务。他们写代码的思路已经完全脱离“框架”，并始终围绕业务逻辑，主要工作即为业务逻辑层面的抽象和接口设计。
那么，你在哪个境界？
看看jquery源码中dom部分的比重就知道dom有多么肮脏和臃肿了，说dom臃肿，到不是因为浏览器差异，而是因为dom本身就不优美，Qcon上老道也提到，天资优雅的javascript被dom污染坏了。因为标签属性类型太多，节点种类和行为又是如此多样，所以对dom的封装不是技术活，纯粹是体力活，过程中需要大量的测试，包括性能测试。所以，封装dom的时候，一定要有耐心。
今天给sandbox的dom添加了一些常规方法，attr,css,style,empty,append,copy等等，行为大都依照jquery-dom的api来做，我删掉了那些性能上的 hack，想重写性能的部分，不过这都不是难点，这些方法中，麻烦的是节点的拷贝，因为要考虑事件的拷贝，节点复制一个新的，新节点的事件不能丢。在ie 中，原生的cloneNode就可以复制事件，但有点囧。jquery源码中是这样描述事件拷贝的
// IE copies events bound via attachEvent when
// using cloneNode. Calling detachEvent on the
// clone will also remove the events from the orignal
// In order to get around this, we use innerHTML.
// Unfortunately, this means some modifications to
// attributes in IE that are actually only stored
// as properties will not be copied (such as the
// the name attribute on an input).
解决方法似乎是找出所有的问题种类一个一个hack，之前给Node的事件已经封装好，在非ie中，只需要给新生成的节点挂载一个新的”事件中心”，这个事件中心的事件依然指向旧有的节点，实际上两者公用一个回调，这个回调是存储在Sandbox._ENV.Event中的，并不会因为旧节点的删除而消失，因此，demo就是这样：
http://tbexample.googlecode.com/svn/tru … -copy.html
dom中有太多细节需要考究，并发现jquery内部各模块之间的耦合简直像胶水粘上一样，在模块组织这方面，john真的要向zakas学学了。
下一步，继续杯具的Dom
to be continue…
