作者：kun10
发布时间：December 11, 2010
分类：牛人之整理
jiang博士的演讲主要讲解了facebook页面优化的三大技术
我写了一些自己的理解，你可以对着幻灯自己理解一下。
一、quickling
（对页面的刷新使用ajax的方法来模拟，以消除以一些例如顶部导航等不太变动的资源的反复调用，中间需要模拟浏览器重载页面的事件）
个人理解：
最简单的实现可以理解为，用js写一个事件委派，对所有的链接的click事件做捕获，如果链接是新开窗口的，就用ajax的方法去向服务器请求相应的这个页面的html，返回回来替换掉现存页面的内容部分，注意不是替换页面的全部。这样可以请求的时候的资源就小了一些。
quickling遇到的一个问题是，ajax回来的css加载的多了之后客户端会变得缓慢（尤其是低版本的ie），此时可以对quickling设定一个预值，比如当一个页面使用了10次quickling之后就不再使用quickling而重新刷一遍页面，以此循环。
2、pagecache
（对常用的页面的dom缓存于JavaScript中，在重新载入这个页面的时候从客户端调用）
个人理解：
例如facebook的个人主页是被经常的调用的，这时候就对此页面使用pagecache技术，对页面的dom缓存于JavaScript变量中，当用户再次使用这个页面的时候就从JavaScript变量中调用之前缓存的页面dom。这样拼装页面都是在客户端进行的，当然也遇到一些的问题，页面的dom是在载入之后被缓存的，因此用户在页面载入后向服务器做的一些数据的请求导致页面内容的变化将不被记入在原来缓存的变量中，这样下次载入的时候用户会看不到上一次自己对主页做的操作，对此facebook做的工作是记录用户对页面的操作（比如记录下用户的ajax的请求），在下一次使用pagecache的时候像放录像一样的，还原用户之前一次的操作。
3、bigpipe
（页面分为多个pagelet的小区域，通过bigpipe的js，单独的从服务器请求每个pagelet）
个人理解：
原来的页面从服务器到客户端要经历服务器拼装html、网络传输、客户端渲染页面三步。
每一步都需要等待前面的步骤完成才进行
使用bigpipe就是把页面拆分成了很多小的单独的模块（pagelet），通过ajax的方式单独的拼装、传输和渲染这些模块
这样一个页面的多个模块都是单独的进行渲染的，并且这些模块的渲染都不受其他模块是否载入完成的影响，多个模块的载入是并行的。这样一方面可以加速页面的渲染，让页面尽早的展现在用户的面前，另一方面可以自己控制哪一部分先展示，是重要的模块先展示给用户。
作者：kun10
发布时间：March 14, 2010
分类：牛人之整理
JavaScript 可算是世界上最流行的编程语言，它曾被 Web 开发设计师贴上噩梦的标签，虽然真正的噩梦其实是 DOM API，这个被大量的开发与设计师随手拈来增强他们的 Web 前端的脚本语言，如今越来越被重视，虽则如此，JavaScript 仍然拥有很多让人费解的东西。
1. 它以 Java 命名，但并不是 Java
它最初叫 Mocha， 接着改名为 LiveScript，最后才确定命名为 JavaScript，根据历史记录，Java 的命名与 Netscape 和 Sun 之间的合作有关，作为交换条件，Netscape 在他们备受欢迎的浏览器中创建了 Java 运行时。值得一提的是，这个名字的出台几近一个玩笑，要知道，LiveScript 和 Java 在客户端脚本方面存在敌对关系。
不管怎么说，人们后来不得不一再澄清的一件事就是，JavaScript 和 Java 毫无关系。
2. Null 是个对象？
看看这段代码，它返回的是 object。
console.log(typeof null); // object
这实在令人费解，假如 null 表示空值，它怎么可以是对象？简单说，它是 JavaScript 最初版本的错误，这个错误甚至被微软的 JScript 直接借用。
3. NaN !== NaN
NaN，表示一个非数字的值，然而问题是，NaN不等于任何东西，甚至不等于它自己。
console.log(NaN === NaN); // false
这显然不对，事实上，如果要判断一个值确实是 NaN，你需要用 isNaN() 函数。
4. 全局变量
对全局变量的依赖一直被视为 JavaScript 最坏的部分（ECMA 的 JavaScript 5 已经去掉了全局变量，请参阅 ECMA 推出 JavaScript 5 - 译者注）。对简单的页面，这无所谓，但复杂的页面，如果包含大量 JavaScript 脚本，你很难知道某个全局变量是在哪里声明的，如果几个全局变量不小心重名，就会引发错误。
“The problem with JavaScript isn’t just that it allows them (global variables), it requires them.” – Crockford
5. 那些统统被探测为 Mozilla User-Agent 的浏览器
必须承认，事实上，这不是 JavaScript 的错，是各个浏览器有意为之。比如，以下是用 JavaScript 探测 Safari 时得到的结果：
console.log(navigator.userAgent);
// Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10
是否注意到其中的第一个单词 Mozilla/5.0，为什么 Safari 会被探测为 Mozilla，尽管 Safari 后来已经纠正这一问题，但仍然不能解释为什么它们要这样误导开发者。事实上，你会发现，绝大多数浏览器把他们的 User Agent 设置为 Mozilla，答案要回到10年前，这更多是一种策略。
User Agent 是一段用来标识当前浏览器身份的字符串，世界上第一个浏览器 Mosaic， 曾这样标志自己：
Mosaic/0.9 // browser name / version number
这很合理，因此当 Netscape 出来的时候，它保留了 Mosaic 这个传统，还在后面添加了一个加密方式部分。
Mozilla/2.02 [en] (Win95; I) // browser name / version / encryption
到目前为止，一切安好，直到 IE3 发布，当 IE3 发布的时候，Netscape 正如日中天，那时，很多服务器和程序已经部署了客户端探测机制，以便认出 Netscape，虽然现在看来，这很值得争议，但当时并没什么。当 IE 初次推出它们的 User Agent 标志的时候，是这个样子：
MSIE/3.0 (Win95; U)
这让 IE 很被动，因为 Netscape 已经能被很多服务器识别，因此，开发者们干脆希望 IE 被误认为 Mozilla，然后，再单独加一个 IE 的标签。
Mozilla/2.0 (compatible; MSIE 3.0; Windows 95)
如今，几乎所有浏览器都步 IE 后尘，将自己标识为 Mozilla，这大概是一种连锁反应。
6. 不一致的函数范围
参看以下代码：
// Create a function that will call a function with the name equal to parameter fn.
function foo(fn) {
if (typeof fn === "function") {
fn();
}
}
// Create an object with a property and a method.
var bar = {
barbar : "Hello, World!",
method : function() {
alert(this.barbar);
}
};
bar.method(); // Alerts Hello, World!
foo(bar.method); // If we call the foo function add pass the "bar.method" method, it somehow alerts "undefined."
foo(function() { bar.method(); }); // alerts Hello, World, after
foo(bar.method) 返回结果不同原因是，method 函数是被当作 windows 对象，而不是 bar 下的对象调用的。要解决这个问题，我们必须从传递的匿名函数中调用 bar.method() 。
7. 位操作符
JavaScript 和 Java 有不少共同之处，如位操作。
- and
| - or
^ - xor
~ - not
- signed right shift
??? - unsigned right shift
- left shift
看看第一个 操作符，使用 应该更有效，因为 JavaScript 和 Java 不一样，JavaScript 没有整数，需要来回转换，因此，转换操作花的时间更长。
8. 太多的空值类型
诸如 null, false, undefined 一类的值几乎表示同样的意思，它们之间的不同又让人很迷惑。
!!(0); // false
!!(false); // false
!!(''); // false
!!(null); // false
!!(undefined); // false
!!(NaN); // false
9. 算术问题
虽然 JavaScript 包含很多算术操作，但你不妨运行一下下面的算式，".2+.4" 应该等于 ".6" 是不是，然而返回的确是 "0.6000000000000001"。JavaScript 在小数计算访问存在一些小问题。
console.log(.2 + .4); // 0.6000000000000001
为什么会这样？简单说，因为 JavaScript 使用 IEEE 标准进行二进制浮点运算，不过，对整数计算是没问题的。
10. 莫名其妙的代码错误
看看以下两段代码：
// braces on the right
return {
foo : bar
};
// braces on their own line
return
{
foo : bar
};
它们应该是一样的，只是 { 位置不同而已，是吧。然而我们再看下面的代码：
如果我们把其中的
var foo = function() {
return {
a : 'b'
};
}();
alert(foo.a); // b
换成
return
{
a : 'b'
};
就会引发错误，这是因为 JavaScript 有一个功能，会纠正它认为错误的代码书写，它会自作聪明地在 return 这个词后面插入一个 ";" ，错误因此而生。
return; // JS incorrectly adds this semicolon.
{
a : 'b'; // It'll add a semicolon here as well, because it doesn't realize that this is an object.
};
本文来源：http://net.tutsplus.com/tutorials/javascript-ajax/top-10-things-that-javascript-got-wrong/
作者：kun10
发布时间：March 9, 2010
分类：牛人之整理
看玉伯的blog有更新，才看了第一句就引发了疑问了~~~
于是找了下面的资料
Script中的Defer属性
如果你是一个对系统性能比较关心和在意的人，我想你应该会对Script脚本中的defer属性感兴趣的。
script中的defer属性默认情况下是false的。按照DHTML编程宝典中的描述，对于Defer属性是这样写的：
Using the attribute at design time can improve the download performance of a page because the browser does not need to parse and execute the script and can continue downloading and parsing the page instead.
也就是说：如果是编写脚本的时候加入defer属性，那么浏览器在下载脚本的时候就不必立即对其进行处理，而是继续对页面进行下载和解析，这样会提高下载的性能。
这样的情况有很多种。比如你定义了很多javascript变量，或者在引用文件（.inc）中写了很多的脚本需要处理，那不妨在这些脚本中加入defer属性，对性能的提高肯定有所帮助。
举例如下：
<script language="javascript" defer>
var object = new Object();
....
</script>
因为defer属性默认是为false的，那么在这里
<script language="javascript" defer>
显式声明defer属性后等同于
<script language="javascript" defer=true>
声明了defer属性之后，需要判断是否有别的变量引用了defer脚本块中的变量，否则的话会导致脚本错误的产生。
引用
DEFER是脚本程序强大功能中的一个“无名英雄”。你可能从没有使用过它，但是看完这里的介绍后，相信你就离不开它。它告诉浏览器Script段包含了无需立即执行的代码，并且，与SRC属性联合使用，它还可以使这些脚本在后台被下载，前台的内容则正常显示给用户。
最后请注意两点：
1、不要在defer型的脚本程序段中调用document.write命令，因为document.write将产生直接输出效果。
2、而且，不要在defer型脚本程序段中包括任何立即执行脚本要使用的全局变量或者函数。
加上 defer 等于在页面完全在入后再执行，相当于 window.onload ，但应用上比 window.onload 更灵活！
比较下面的3个例子:
<button id="myButton" onclick="alert('ok')">test</button>
<script>
myButton.click();
</script>
<script defer>
myButton.click();
</script>
<button id="myButton" onclick="alert('ok')">test</button>
<script>
myButton.click();
</script>
<button id="myButton" onclick="alert('ok')">test</button>
---------------- 从w3school上面看到-------------
只有 Internet Explorer 支持 defer 属性。
---------------- -------------------------------
---------------- 从《high perfomance javascript》上面看到-------------
只有 Internet Explorer4+和firefox 3.5+ 支持 defer 属性。
---------------- -------------------------------
作者：kun10
发布时间：March 2, 2010
分类：牛人之整理
昨天，我负责了Yahoo!公司组织的一次面试活动，感触颇深的是其中的应聘者提问环节。我得说自己对应聘者们提出的大多数问题都相当失望。我希望听到一些对在Yahoo！工作充满激情的问题。在昨天的应聘者中，只有一个人的问题是我认为最好的，那个人问我：你觉得怎么才能成为优秀的前端工程师？我觉得很有必要把这个问题从面试房间里拿出来讨论一下。
首先，前端工程师必须得掌握HTML、CSS和JavaScript。只懂其中一个或两个还不行，你必须对这三门语言都很熟悉。也不是说必须对这三门语言都非常精通，但你至少要能够运用它们完成大多数任务，而无需地频繁地寻求别人的帮助。
优秀的前端工程师应该具备快速学习能力。推动Web发展的技术并不是静止不动的，没错吧？我甚至可以说这些技术几乎每天都在变化，如果没有快速学习能力，你就跟不上Web发展的步伐。你必须不断提升自己，不断学习新技术、新模式；仅仅依靠今天的知识无法适应未来。Web的明天与今天必将有天壤之别，而你的工作就是要搞清楚如何通过自己的Web应用程序来体现这种翻天覆地的变化。
计算机科学这个大门类下面的许多分支在人们眼中实际上都不外乎科学。但是，我们所说的前端不是什么科学，而是艺术。艺术家不仅要掌握谋生的技术，还要懂得如何运用。对同一个问题的解决方案在这种情况适用，在另一种情况下可能就不适用。对Web应用程序的前端而言，解决同一问题的方案经常会有很多。没有哪个方案是错的，但其中确实有一些是更合适的。优秀的前端工程师应该知道在什么情况下使用哪种方案更合适，而在什么情况下应该重新选择。
优秀的前端工程师需要具备良好的沟通能力，因为你的工作与很多人的工作息息相关。在任何情况下，前端工程师至少都要满足下列四类客户的需求。
产品经理这些是负责策划应用程序的一群人。他们能够想象出怎样通过应用程序来满足用户需求，以及怎样通过他们设计的模式赚到钱（但愿如此）。一般来说，这些人追求的是丰富的功能。
UI设计师这些人负责应用程序的视觉设计和交互模拟。他们关心的是用户对什么敏感、交互的一贯性以及整体的好用性。他们热衷于流畅靓丽但并不容易实现的用户界面。
项目经理这些人负责实际地运行和维护应用程序。项目管理的主要关注点，无外乎正常运行时间（uptime）应用程序始终正常可用的时间、性能和截止日期。项目经理追求的目标往往是尽量保持事情的简单化，以及不在升级更新时引入新问题。
最终用户当然是应用程序的主要消费者。尽管我们不会经常与最终用户打交道，但他们的反馈意见至关重要；没人想用的应用程序毫无价值。最终用户要求最多的就是对个人有用的功能，以及竞争性产品所具备的功能。
那么，前端工程师应该最关注哪些人的意见呢？答案是所有这四类人。优秀的前端工程师必须知道如何平衡这四类人的需求和预期，然后在此基础上拿出最佳解决方案。由于前端工程师处于与这四类人沟通的交汇点上，因此其沟通能力的重要性不言而喻。如果一个非常酷的新功能因为会影响前端性能，必须删繁就简，你怎么跟产品经理解释？再比如，假设某个设计如果不改回原方案可能会给应用程序造成负面影响，你怎么才能说服UI设计师？作为前端工程师，你必须了解每一类人的想法从何而来，必须能拿出所有各方都能接受的解决方案。从某种意义上说，优秀的前端工程师就像是一位大使，需要时刻抱着外交官的心态来应对每一天的工作。
我告诫新来的前端工程师最多的一句话，就是不要在没有作出评估之前就随便接受某项任务。你必须始终记住，一定先搞清楚别人到底想让你干什么，不能简单地接受这个功能有问题之类的大概其的说法。而且，你还要确切地知道这个功能或设计的真正意图何在。加一个按钮之类的任务并不总意味着你最后会加一个按钮。还可能意味着你会找产品经理，问一问这个按钮有什么用处，然后再找UI设计师一块探讨按钮是不是最佳的交互手段。要成为优秀的前端工程师，这种沟通至关重要。
无论从哪个方面讲，我都觉得前端工程师是计算机科学职业领域中最复杂的一个工种。绝大多数传统的编程思想已经不适用了，为了在多种平台中使用，多种技术都借鉴了大量软科学的知识和理念。成为优秀前端工程师所要具备的专业技术，涉及到广阔而复杂的领域，这些领域又会因为你最终必须服务的各方的介入而变得更加复杂。专业技术可能会引领你进入成为前端工程师的大门，但只有运用该技术创造的应用程序以及你跟他人并肩协同的能力，才会真正让你变得优秀。
英文原文：What makes a good front end engineer?
本文转自phpchina
