html5 越来越近了，HTML5可能给我们带来很大的改变，就象新的标签可以支持视频了。看看javascript的架构师能够做什么吧。原文来自http://www.cnbeta.com/articles/109538.htm
由于当前技术仍偏向功能强化为主要思维，指令码趋向庞杂的结果，容易产生更多安全漏洞，且失去快速因应攻击调整架构的灵活性。
身 为JavaScript网路技术重要推手的雅虎（Yahoo!）架构设计师Douglas Crockford表示，现行网页开发技术思维仍偏重多媒体功能或浏览效能的提升，未来应以安全为第一优先。 Crockford 现为Yahoo!资深JavaScript架构师，负责YUI（Yahoo! User Interface）的架构设计，并且担任ECMA JavaScript 2.0技术委员会成员，为JavaScript开发社群大师级人物，此次受邀来台参加OSDC（Open Source Developer's Conference Taiwan）进行专题演讲，向国内开发者介绍ECMA JavaScript的发展。
Crockford向媒体阐述网络技术发展时指出，当前的网络技术仍然不脱过去的思维，网页开发技术仍以功能强化、浏览网页效能提升为主，虽然强 化了网络开发的丰富性，但未将网络安全列为开发优先考虑因素的结果，致使网络安全事件层出不穷。
延续过去网络开发思维的结果，现今网络技 术强调强大的互动、多媒体功能，但也让一些攻击手法兴起，以XSS（Cross-Site Scripting）为例，由于内嵌多个不同来源的脚本，容易让黑客借指令集趁虚而入，窃取用户端计算机的数据。
虽然也有新的技术，如 Google推动的Caja，用以防范XSS跨站攻击手法，但整体技术发展方向仍是朝功能、效能提升前进。
以HTML 5技术为例，Crockford表示，虽然HTML5增加了许多功能，但让整个脚本变得更为庞大且复杂，容易产生漏洞遭到攻击；另外，支持存取使用者电 脑、手机的终端数据，将数据被窃的安全风险扩大至手机上，而过于庞大复杂的结果，不容易因应日新月异的攻击手法改变，长期而言易形成安全风险。
对 于当前浏览器业者形成速度竞赛，纷纷强化JavaScript引擎加速网页浏览速度，号称最快的浏览速度，他认为，浏览器加速网页浏览速度虽是好事，但这 样改善方式有限，只在5至10%的终端浏览器部份加速，若能同时改善服务器端，加速的效果更大。
对于制定中的新标准ECMA Script 5，他乐观预期未来将成为主要的网络开发标准，虽然Apple、Chrome还不明确，但包括IE、FireFox、Opera都倾向ECMA Script 5，今年应会看到新的浏览器应用。
--EOF--
HTML5已经被越来越多的浏览器所支持，IE还能挺多久？是否又会创造出什么新标准？从IE4开始，多少网页设计师为了兼容所有的浏览器而痛苦？以后又会怎么样？IE6还有这么多用户，怎么办？这一些都让人迷惘啊。HTML5来了，对于前端工程师的压力就要更大一点了。代码没写好，很可能就直接被人利用了。以前的XSS漏洞可能会被更加扩大、放大。还是需要多学一点安全了
这是cssrain站长翻译的一篇文章，事实上，在PHP中，已经不太建议使用switch-case了。
特别是在面向OO的代码中，你几乎也看不到这样的代码出现
不是说这个方式不好。而是，它的可扩展性不强。所以在大多数情况下，都放弃采用这种方式。
以下是翻译内容，来源于：http://www.cssrain.cn/article.asp?id=1384：
我很年轻，还没有做过很长的编程。所以我对使用switch-case 语法没有什么很深刻的印象，至少在我的记忆中是这样。或许你认为这是一件坏事情。你甚至会怀疑我为什么不使用它们。我真的不知道为什么，似乎我天生就不喜欢使用它，如下所示：
JavaScript代码
- switch (something) {
- case 1:
- doX();
- break;
- case 2:
- doY();
- break;
- case 3:
- doN();
- break;
-
- }
显然，虚构此代码的作者不够了解使用其他JavaScript方法来构建此功能。其实有很多种方式更适合这种情况，而不是一个丑陋的switch. 有许多许多更轻松，更优雅的方式来实现这种功能。
switch-case组合肯定是非常有用的，当你有一个变量并且依靠它的值的不同来做不同的事情。使用多个if-else不太恰当，所以人们通常使用switch-case来代替多个if-else.我敢肯定你也是.
上面的例子依赖于 something 判断 ，然后根据条件运行doX ， doY或doN 。在JavaScript中，同样的逻辑可以表示一个简单的查找表的形式————对象，如下所示：
JavaScript代码
- var cases = {
- 1: doX,
- 2: doY,
- 3: doN
- };
- if (cases[something]) {
- cases[something]();
- }
这不仅简洁，而且也可以重复使用和修改条件。所有条件都是对象的一部分，因此，如果您需要改变某些条件那就非常简单了。
所以，我想说的是：请不要使用switch-case，除非绝对必要的。 为什么？ 因为有更好的替代品，比它更简单！
关于“ switch-case”的语法，请浏览：http://en.wikipedia.org/wiki/Switch_statement
如果想阅读原文，请点击这里：http://james.padolsey.com/javascript/how-to-avoid-switch-case-syndrome/
提示:译文跟原文有出入，请看原文。
jquery 1.3刚刚出来没几天，shawphy的中文API就基本出炉了，有时候真的挺佩服他们，当我们在娱乐的时候，他们还在努力的为我们这些人造福。我没有什么其他能力，只能做到代为传播了。同时也是希望有更多的人参与，可以让我们这些使用者也能够更加方便。
网址：http://shawphy.com/2009/01/release-jquery-doc-cn-1-3.html
原文如下：
jQuery 1.3自从2008年1月14日发布后，后引来了各界的关注。我们也随即投入到翻译文档的工作中来。经过4天的努力，终于完工了。这个版本更新了不少东西
changelog:
2009-01-18 16:06:52 +0800
* triggerHandler 进一步说明
* trigger 进一步说明
2009-01-17 22:37:11 +0800
* live() - 与bind()不同的是，live()一次只能绑定一个事件。
* [attribute!=value] jQuery 1.3中意义改变
* load 的data参数在jQuery 1.3中也可以接受String
+ ajax的error回调的第二个参数可能值”timeout”, “error”, “notmodified” 和 “parsererror”
+ ajax参数xhr
* animate 的duration为0的问题
* show, hide, toggle, slideDown, slideUp, slideToggle 在jQuery 1.3中，padding和margin也会有动画，效果更流畅。
* jQuery(html,[ownerDocument])等效于$(document.createElement(”span”)
* is支持复杂表达式
2009-01-17 18:31:10 +0800
+ jQuery.support.scriptEval
+ 原 Dimension 插件功能（1.2.6版加入jQuery核心）
2009-01-16 19:11:10 +0800
+ jQuery.fx.off
+ toggleClass( class, switch )
+ toggle( switch )
+ toggle(speed,[callback])
* 修改queue和dequeue方法的参数和说明
2009-01-15 22:31:02 +0800
* jQuery(html,[ownerDocument])
+ jQuery.selector
+ jQuery.context
* 效果下的queue和dequeue搬到核心下
+ live()
+ die()
+ closest()
* stop( [clearQueue], [gotoEnd]) 增加两个参数
+ jQuery.support
+ jQuery.isArray( obj )
感谢Cloudream的热情帮忙。还要感谢一揪制作chm版。这个版本还加入了检查更新的功能。如果有需要的同学可轻松查看是否有更新的中文文档(chm版中的检查更新也将同步升级)。
在线查看 下载离线版 bug提交
转载这篇文章的原因是它解释了setTimeout和setInterval之间的区别，对于这篇文章，博客园有位朋友进行了翻译，网址如下：http://www.cnblogs.com/rainman/archive/2008/12/26/1363321.html
翻译内容为：
How JavaScript Timers Work
从基础的层面来讲，理解JavaScript的定时器是如何工作的是非常重要的。计时器的执行常常和我们的直观想象不同，那是因为JavaScript引擎是单线程的。我们先来认识一下下面三个函数是如何控制计时器的。
var id = setTimeout(fn, delay); - 初始化一个计时器，然后在指定的时间间隔后执行。该函数返回一个唯一的标志ID（Number类型），我们可以使用它来取消计时器。var id = setInterval(fn, delay); - 和setTimeout有些类似，但它是连续调用一个函数（时间间隔是delay参数）直到它被取消。clearInterval(id);, clearTimeout(id); - 使用计时器ID（setTimeout 和 setInterval的返回值）来取消计时器回调的发生
为了理解计时器的内在执行原理，有一个重要的概念需要加以探讨：计时器的延迟(delay)是无法得到保障的。由于所有JavaScript代码是在一个线程里执行的，所有异步事件（例如，鼠标点击和计时器）只有拥有执行机会时才会执行。用一个很好的图表加以说明：
(点击查看大图)
在这个图表中有许多信息需要理解，如果完全理解了它们，你会对JavaScript引擎如何实现异步事件有一个很好的认识。这是一个一维的图标：垂 直方向表示时间，蓝色的区块表示JavaScript代码执行块。例如第一个JavaScript代码执行块需要大约18ms，鼠标点击所触发的代码执行 块需要11ms，等等。
由于JavaScript引擎同一时间只执行一条代码（这是由于JavaScript单线程的性质），所以每一个JavaScript代码执行块会 “阻塞”其它异步事件的执行。这就意味着当一个异步事件发生（例如，鼠标点击，计时器被触发，或者Ajax异步请求）后，这些事件的回调函数将排在执行队 列的最后等待执行（实际上，排队的方式根据浏览器的不同而不同，所以这里只是一个简化）；
从第一个JavaScript执行块开始研究，在第一个执行块中两个计时器被初始化：一个10ms的setTimeout()和一个10ms的setInterval()。 依据何时何地计时器被初始化(计时器初始化完毕后就会开始计时)，计时器实际上会在第一个代码块执行完毕前被触发。但是，计时器上绑定的函数不会立即执行 （不被立即执行的原因是JavaScript是单线程的）。实际上，被延迟的函数将依次排在执行队列的最后，等待下一次恰当的时间再执行。
此外，在第一个JavaScript执行块中我们看到了一个“鼠标点击”事件发生了。一个JavaScript回调函数绑定在这个异步事件上了（我 们从来不知道用户什么时候执行这个（点击）事件，因此认为它是异步的），这个函数不会被立即执行，和上面的计时器一样，它将排在执行队列的最后，等待下一 次恰当的时候执行。
当第一个JavaScript执行块执行完毕后，浏览器会立即问一个问题：哪个函数（语句）在等待被执行？在这时，一个“鼠标点击事件处理函数”和 一个“计时器回调函数”都在等待执行。浏览器会选择一个（实际上选择了“鼠标点击事件的处理函数”，因为由图可知它是先进队的）立即执行。而“计时器回调 函数”将等待下次适合的时间执行。
注意，当“鼠标点击事件处理函数”执行的时候，setInterval的回调函数第一次被触发了。和setTimeout的回调函数一样，它将排到执行队列的最后等待执行。但是，一定要注意这一点：当setInterval回调函数第二次被触发时（此时setTimeout函数仍在执行）setTimeout的第一次触发将被抛弃掉。当一个很长的代码块在执行时，可能把所有的setInterval回调函数都排在执行队列的后面，代码块执行完之后，结果便会是一大串的setInterval回调函数等待执行，并且这些函数之间没有间隔，直到全部完成。所以，浏览器倾向于的当没有更多interval的处理函数在排队时再将下一个处理函数排到队尾(这是由于间隔的问题)。
我们能够发现，当第三个setInterval回调函数被触发时，之前的setInterval回调函数仍在执行。这就说明了一个很重要的事实：setInterval不会考虑当前正在执行什么，而把所有的堵塞的函数排到队列尾部。这意味着两次setInterval回调函数之间的时间间隔会被牺牲掉（缩减）。
最后，当第二个setInterval回调函数执行完毕后，我们可以看到没有任何程序等待JavaScript引擎执行了。这就意味着浏览器现在在等待一个新的异步事件的发生。在50ms时一个新的setInterval回调函数再次被触发，这时，没有任何的执行块阻塞它的执行了。所以它会立刻被执行。
让我们用一个例子来阐明setTimeout和setInterval之间的区别：
setTimeout(function(){
/* Some long block of code... */
setTimeout(arguments.callee, 10);
}, 10);
setInterval(function(){
/* Some long block of code... */
}, 10);
这两句代码乍一看没什么差别，但是它们是不同的。setTimeout回调函数的执行和上一次执行之间的间隔至少有10ms（可能会更多，但不会少于10ms），而setInterval的回调函数将尝试每隔10ms执行一次，不论上次是否执行完毕。
在这里我们学到了很多知识，总结一下：
- JavaScript引擎是单线程的，强制所有的异步事件排队等待执行
setTimeout 和 setInterval 在执行异步代码的时候有着根本的不同- 如果一个计时器被阻塞而不能立即执行，它将延迟执行直到下一次可能执行的时间点才被执行（比期望的时间间隔要长些）
- 如果
setInterval回调函数的执行时间将足够长（比指定的时间间隔长），它们将连续执行并且彼此之间没有时间间隔。
上述这些知识点都是非常重要的。了解了JavaScript引擎是如何工作的，尤其是大量的异步事件（连续）发生时，才能为构建高级应用程序打好基础。
英文原文如下：
At a fundamental level it's important to understand how JavaScript timers work. Often times they behave unintuitively because of the single thread which they are in. Let's start by examining the three functions to which we have access that can construct and manipulate timers.
var id = setTimeout(fn, delay); - Initiates a single timer which will call the specified function after the delay. The function returns a unique ID with which the timer can be canceled at a later time.var id = setInterval(fn, delay); - Similar to setTimeout but continually calls the function (with a delay every time) until it is canceled.clearInterval(id);, clearTimeout(id); - Accepts a timer ID (returned by either of the aforementioned functions) and stops the timer callback from occurring.
In order to understand how the timers work internally there's one important concept that needs to be explored: timer delay is not guaranteed. Since all JavaScript in a browser executes on a single thread asynchronous events (such as mouse clicks and timers) are only run when there's been an opening in the execution. This is best demonstrated with a diagram, like in the following:
There's a lot of information in this figure to digest but understanding it completely will give you a better realization of how asynchronous JavaScript execution works. This diagram is one dimensional: vertically we have the (wall clock) time, in milliseconds. The blue boxes represent portions of JavaScript being executed. For example the first block of JavaScript executes for approximately 18ms, the mouse click block for approximately 11ms, and so on.
Since JavaScript can only ever execute one piece of code at a time (due to its single-threaded nature) each of these blocks of code are "blocking" the progress of other asynchronous events. This means that when an asynchronous event occurs (like a mouse click, a timer firing, or an XMLHttpRequest completing) it gets queued up to be executed later (how this queueing actually occurs surely varies from browser-to-browser, so consider this to be a simplification).
To start with, within the first block of JavaScript, two timers are initiated: a 10ms setTimeout and a 10ms setInterval. Due to where and when the timer was started it actually fires before we actually complete the first block of code. Note, however, that it does not execute immediately (it is incapable of doing that, because of the threading). Instead that delayed function is queued in order to be executed at the next available moment.
Additionally, within this first JavaScript block we see a mouse click occur. The JavaScript callbacks associated with this asynchronous event (we never know when a user may perform an action, thus it's consider to be asynchronous) are unable to be executed immediately thus, like the initial timer, it is queued to be executed later.
After the initial block of JavaScript finishes executing the browser immediately asks the question: What is waiting to be executed? In this case both a mouse click handler and a timer callback are waiting. The browser then picks one (the mouse click callback) and executes it immediately. The timer will wait until the next possible time, in order to execute.
Note that while mouse click handler is executing the first interval callback executes. As with the timer its handler is queued for later execution. However, note that when the interval is fired again (when the timer handler is executing) this time that handler execution is dropped. If you were to queue up all interval callbacks when a large block of code is executing the result would be a bunch of intervals executing with no delay between them, upon completion. Instead browsers tend to simply wait until no more interval handlers are queued (for the interval in question) before queuing more.
We can, in fact, see that this is the case when a third interval callback fires while the interval, itself, is executing. This shows us an important fact: Intervals don't care about what is currently executing, they will queue indiscriminately, even if it means that the time between callbacks will be sacrificed.
Finally, after the second interval callback is finished executing, we can see that there's nothing left for the JavaScript engine to execute. This means that the browser now waits for a new asynchronous event to occur. We get this at the 50ms mark when the interval fires again. This time, however, there is nothing blocking its execution, so it fires immediately.
Let's take a look at an example to better illustrate the differences between setTimeout and setInterval.
setTimeout(function(){
/* Some long block of code... */
setTimeout(arguments.callee, 10);
}, 10);
setInterval(function(){
/* Some long block of code... */
}, 10);
These two pieces of code may appear to be functionally equivalent, at first glance, but they are not. Notably the setTimeout code will always have at least a 10ms delay after the previous callback execution (it may end up being more, but never less) whereas the setInterval will attempt to execute a callback every 10ms regardless of when the last callback was executed.
There's a lot that we've learned here, let's recap:
- JavaScript engines only have a single thread, forcing asynchronous events to queue waiting for execution.
setTimeout and setInterval are fundamentally different in how they execute asynchronous code.- If a timer is blocked from immediately executing it will be delayed until the next possible point of execution (which will be longer than the desired delay).
- Intervals may execute back-to-back with no delay if they take long enough to execute (longer than the specified delay).
All of this is incredibly important knowledge to build off of. Knowing how a JavaScript engine works, especially with the large number of asynchronous events that typically occur, makes for a great foundation when building an advanced piece of application code.
