w3ctech

[转载至图灵社区]对话《JavaScript高级程序设计》作者 Nicholas C. Zakas（中文版）

周裕波 — Wed, 16 May 2012 14:06:18 +0000

以下内容转载至图灵社区，是图灵社区根据对《JavaScript高级程序设计》作者 Nicholas C. Zakas的采访原文翻译。

很高兴收到你的邮件，而且听说我的书那么受欢迎也很开心。以下是对问题的回答。

Q1：对各种JavaScript库的优点和缺点一直存在很多争论。在您看来，开发人员应该怎么选择合适的库？

Zakas：在选择JavaScript库的时候，有几个非常重要的方面要考虑。首先，就是时间问题，也就是你的项目多长时间必须做完？如果时间很短，那最好选择你最熟悉的JavaScript库。如果时间不那么紧迫，那你可以研究一下别的库。此时，必须要回答几个问题。还有谁在使用这个JavaScript库？这个库有人在不断完善吗？这个库的文档是否完整详细？这个库的背后有没有一个社区，假如你遇到了问题，能不能获得该社区的支持？是否容易找到具有使用这个库经验的工程师？这个库能不能解决你的所有问题，还是只能解决其中一部分？所有这些都是在选择某个JavaScript库时需要考虑的重要因素。

Q2：你对HTML5的未来怎么看？现在的宣传是不是太过分了？

Zakas：HTML5对Web发展是一件好事儿。但不好的是，一些外行的非技术人员，不分青红皂白地给很多无关的东西都扣上”HTML5“的帽子，这才搞得HTML5这个概念满天飞。这与几年前“Ajax”的情况非常相似。从某种角度看，确实宣传上有点过了，仿佛HTML5会彻底改变每个人的生活。事实并非如此。HTML5的意义在于为开发人员提供了更多的工具，利用这些工具能够创建更有吸引力的用户体验。

Q3：看来，Mobile Web（移动互联网）开发会成为下一行业焦点，你觉得呢？

Zakas：移动互联网开发已经是焦点了。今天，谁不关注移动用户，谁就要被时代抛弃。移动互联网可不是昙花一现，它将是一个时代。如果你真是在开发Web应用，那么就必须考虑移动体验，否则就会让别人让抢占先机。

Q4：现在有很多基于JavaScript改进的语言，比如Dart、 CoffeeScript，等等。你认为JavaScript今后的路会朝着哪方面发展呢？是更加类似于JVM这种的中间层，还是仍然维持一个强大灵活的编程语言存在？或者说，对于专注于JavaScript的前端工程师来说，是否应该投入大精力去研究和使用CoffeeScript这种语言来简化工作，而不是纠结于JavaScript本身可能的繁复解决方案呢？

Zakas：我没觉得JavaScript有一天只会被当成一个中间层。Dart和CoffeeScript很引人关注，这说明开发人员可能更希望JavaScript能多适应一些应用场景。最终，我想JavaScript会博采众长，吸纳其他语言中更流行的范式，从而使语言核心更完善。但我不认为将来的Web开发人员会只用Dart或CoffeeScript或者其他能编译为JavaScript的语言写代码。

Q5：你觉得Node.js怎么样？它会在服务器端开发中发挥重要作用吗？将来，Web前、后端开发真能只用一种语言来做吗？

Zakas：我认为Node.js对未来Web应用的重要性难以估量。开发人员一直在寻找一个可以替代PHP的方案，以便更迅速、更容易地介入服务器端开发。而在服务器上写JavaScript代码就是一种方案。Node.js不只是一个服务器端的JavaScript引擎，它更为高性能、高扩缩的Web应用提供了一个解决方案。正因为如此，很多JavaScript爱好者可能会转型为后端开发工程师。这样一来，前、后端的沟通会更加顺畅、直接，无论是面对面沟通，还是通过代码交流。

Q6：请问用JavaScript实现一些实用算法——比如压缩ZIP格式，是否可行？

Zakas：不仅可行，而且已经有人做到了！斯图尔特•奈特利（Stuart Knightley）就创建了一个叫JSZip（http://stuartk.com/jszip/）的项目，让我们能够用JavaScript来压缩文件。我认为未来还会出现很多类似实用算法的JavaScript实现。在实现某些复杂的算法时，可以不使用JavaScript，但这种可能性是永远存在的。

Q7：是否有必要强调JavaScript编码风格的一致性？在构建一个大型B/S系统时，如何以最佳方式划分HTML、CSS和JavaScript人员的职责？

Zakas：我觉得任何语言都需要强调编码风格的一致性。只要是团队开发，每个人都以相同方式编写代码就是至关重要的。这样大家才能方便地互相看懂和维护对方的代码。在一个团队中，HTML、CSS和JavaScript的编码风格都应该保持一致。这也是我为什么要写《可维护JavaScript》（Maintainable JavaScript）这本新书的原因，这本书里就解释了作为团队一分子，应该怎么写JavaScript。不过，同样的原则也适用于任何语言。

Q8：异步、回调编程方式正被广泛使用，但很容易出现复杂的回调函数。虽然有deferred和promise这些模式，但对开发人员还是不小的挑战，请问未来是否有可能在语言层面有所改观？

Zakas：经常有人提出建议，希望添加一些语言特性来简化异步编程工作。JavaScript语言层面到底会不会增加这种特性，现在还说不好，只能拭目以待。目前，有很多人认为回调和异步编程值得提倡，但我不那么认为（这句话这样译，对否？——译者注）。如果几乎所有方法都需要一个回调，那会导致代码很难调试和维护。我确实希望不久的将来，JavaScript能在语言层面给出一些解决方案。

Q9：今天，你涉足Web开发已超过15年，你当初怎么就会选择这个行业呢？能否给中国的开发人员一些职业规划方面的建议（有朝一日也能成为像你一样的专家）？

Zakas：我进入这一行，纯属误打误撞。上大学的时候，我的专业是计算机科学，但Pascal和C语言这些课让我感觉很无聊。我讨厌整天坐在黑底白字的电脑屏幕前。当时，我想跟高中同学保持联系，有人告诉我有一种新技术，说是叫Web。于是，1996年我在AOL上建立了自己的第一个网页，然后把网址发给同学，以便他们知道我的近况。我还想知道大家希望通过这个网页了解点其他什么情况，结果维护这个网页就成了我的业余工作。我不断研究、尝试，在此期间自学了JavaScript。结果大学一毕业，我就知道自己得在互联网行业谋份差事了。

我对Web开发人员最大的建议就是：热爱你的工作。热爱跨浏览器开发带来的挑战、热爱互联网技术的种种异端，热爱业内的同行，热爱你的工具。互联网发展太快了，如果你不热爱它的话，不可能跟上它的步伐。这意味着你必须多阅读，多动手，保证自己的才能与日俱增。下了班也不能闲着，要做一些对自己有用的事儿。可以参与一些开源软件的开发，读读好书，看看牛人的博客。经常参加一些会议，看看别人都在干什么。要想让自己快速成长，有很多事儿可以去做，而且付出一定会有回报。

Q10：迄今为止，你已经写了4本JavaScript书。你怎么会想起来写这些书呢，眼下还有没有写书的计划？

Zakas：我从来没有真正有过写书计划。我第一份工作只干了8个月就下岗了（因为公司散伙了）。这就是我当时的处境，大学毕业才8个月，而且又失了业。我感觉真正的学习才刚刚开始。于是我就给自己找事儿做，也就是把以前做过的事儿都写出来。写一篇，就在我的网站（http://nczonline.net）上贴一篇。然后告诉以前的同事都来看。一个朋友回信说：“嘿，你写得非常好，为什么不给杂志投稿呢？“于是，我就上网找到几个征稿的在线杂志。第一篇文章发表在DevX，后来又有几篇投给了WebReference。我的文章很受好评，因此我也非常乐意接着写下去。后来有一天，我看了WebReference的一篇文章，说有另一位作者，她把自己写过的文章集合起来出了一本书。我心想：“等一下，把文章集合在一块就可以出一本书？这事儿我也能干呐！”于是，我就给自己定了一个目标，坚持写，写本书出来。这就是后来的《JavaScript高级程序设计》（Professional JavaScript for Web Developers）。

写另外三本书则隔了很久。《Ajax高级程序设计》（Professional Ajax）实际上是Wrox的编辑策划的一个选题，因为我出版过一本书，所以他就找到了我。一开始我拒绝了，因为觉得可写的东西还不够多。但他坚持让我写，我最终还是应承下来。我很高兴又写了这本书，因为它后来也非常受欢迎。《高性能JavaScript》（High Performance JavaScript）是通过雅虎出版的，当时是雅虎内部人员联系我写的。显然，另外一些人也希望写点相关的东西放在书里，但当时大家都没有时间动笔。所以，我就在他们已有成果的基础上做些修改，改到自己觉得舒服为止。后来又找了几位合著者，共同完成了这本书。

《可维护JavaScript》（Maintainable JavaScript）是我最近才出版的一本书，内容源于6年前的一次演讲。我一直都认为这个主题很值得写，写成一本书都没问题，但就是不知道从何写起。去年12月的一个周六，我一觉醒来，突然觉得才思泉涌，满脑子都是写这本书的想法。我干脆起床，在电脑前坐了一整天，终于把脑子里的想法都落实成了文字。那一天，我写了大约45页。12月份剩下的时间我都花在了写书上，结果不到一个月就写完了这本书。

目前，我还没有再写书的计划。我准备先搁笔一段时间，因为最近我一直都在写，都连续写了一年多了。确实有几个主题值得写书，但在此之前，我得等待灵感爆发的那一刻。

Q11：能否谈谈你的公司Nicholas C. Zakas Consulting？很多中国程序员也有创业的梦想，能分享一下你的经验吗？

Zakas：我的咨询公司实际上只有我一个人。我依靠自己的经验为互联网公司提供前端技术建议，包括性能评估、架构设计与评审、推行最佳实践等专业Web开发公司可能需要的各方面帮助。这为我积累了宝贵的经验，让我得以接触各式各样的公司，结识他们的团队，了解他们正在做哪些激动人心的事情。

对于想自己开公司的人，我可以给出的最好建议，就是要有自知之明。你必须得知道一些事儿，比如自己开公司没有工资，有时候一连几个月可能都没有收入。自己开公司要应对很多风险，如果你后面有家人支持，可能风险会小得多。我创业的时机很好，因为我还没有成家，也没有其他经济负担，所以我可以承受创业不成功再回头找工作的风险。但并不是所有人都像我一样。如果你真心喜欢做点什么，坚信朝哪个方向努力一定成功，觉得自己能承受得了风险，那就不要犹豫。

Q12：你经常上哪些在线社区？请给中国读者推荐一些有用的在线资源。

Zakas：我最近没怎么上网上社区，我是Twitter控，关注那些能告诉我Web技术发展走向的人。我很愿意多花时间在线下跟人交流，比如在公司里，或者在会场上，这样可以了解到最前沿的东西。

我泡GitHub的时间非常多，有时候是看别人的项目，有时候是弄自己的。我在上面经常看到有人讨论代码该怎么写，这样写是为什么之类的讨论，都非常精彩。而通过看别人的代码真的能学习到很多东西。在碰巧遇见自己有感觉的项目，而又认为自己可以提供一些不同思路时，我甚至会为这些项目贡献一些代码。

图灵社区原文地址：http://www.ituring.com.cn/article/1791

最多留言文章

webapp 开发进阶

qbaty — Mon, 07 May 2012 02:35:41 +0000

App 图标
苹果从IOS4.2开始mobile safari就开始支持把网页保存至主屏，从而使得用户可以方便的从主屏的快捷方式进入webapp，而通过苹果提供给我们的API我们可以使得 webapp 像原生app 一样拥有自己的icon。

对于多设备的多分辨率，苹果提供了sizes这个属性。如果不指定这个属性，默认 sizes 会是57 * 57。
对应 apple-touch-icon 苹果还有另外一个属性 apple-touch-icon-precomposed ，他们的不同之处在于使用 apple-touch-icon-precomposed 属性的时候，苹果不会给桌面图标加一个高光效果。

App StartUp Image
苹果 IOS 3.0以后就支持 Startup Image 属性，webapp 在苹果手机上可以给网页指定StartUp Image，使得当webapp从主屏打开时，设为StartUp的封面图片会首先出现，类似原生app。但是苹果对于指定的图片有些限制，必须满足大小。对于 iphone 和 itouch 图片的尺寸只能是 320 x 460 ，其他大小的都无效。但是你可以通过sizes 来进行多设备适配。

隐藏地址栏
IOS 下想要进入全屏模式，并且不再出现地址栏和屏幕底下的操作菜单，可以通过 apple-mobile-web-app-capable 属性来实现

目前以上和保存到主屏相关的大多属性都是iPhone only，如果你感兴趣这里有更详细的说明。

Display 显示
为了适应网页在设备屏幕上的显示,需要通过设置 viewport 的大小来使得网页更适应在设备上阅读。如果仅仅是适应阅读，下列代码第一条就能满足，如果要防止用户在使用webapp时的放大手势操作和缩小手势则需要通过设置user-scalable、其初始化的放大倍数、最大放大倍数和最小缩小倍数来实现。

CSS 渲染
在IOS 或是 andriod上系统自带的都是webkit内核的浏览器，比起在web端饱受微软IE6之苦的程序员来说，webapp确实看似美好了许多。然而毕竟手机端不比PC端，许多渲染小细节不注意，往往会导致这个页面的顿挫感甚至crash。有几个CSS属性值得注意：

-webkit-box-shadow
-webkit-border-radius
-webkit-gradient

在webapp 上，虽说button渐变色，圆角，阴影不再难实现，但是对于CSS渲染来说，这些属性都是高耗品。在项目中对大片的元素使用圆角，和大片元素使用阴影能够明显的感觉到页面滚动的顿挫感。然而过于重度使用绝对定位或是相对定位也会使得浏览器不堪重负而崩溃。这点在mobile safari 上体现的非常明显，所以也尽量少使用绝对定位来完成布局。

position:absolute;
position:relative;

CSS3 动画
webapp 相比传统wap2.0 页面，多媒体和交互上面都有着传统wap远不能及的表现力。native app 虽然在这点上表现十分抢眼，却不如webapp的多平台性。为了迎合这一趋势 CSS3 动画都被各大浏览器厂商支持的很好。例如 transform 和transition，使用这些CSS属性做动画时，值得我们注意的是应该尽量利用3D模式，使得浏览器能够通过启用硬件加速使得动画变得更加流畅。而在项目过程中偶尔碰到动画过程中的动画闪白可以通过设置backface-visibility 来解决。

-webkit-transform-style: preserve-3d;
-webkit-backface-visibility: hidden;

Touch Event 触摸事件
在web端，前端开发绑定点击事件固然是click事件，而手机端系统也为我们提供了一些事件来表示手机的操作事件分别是touchstart、touchmove、touchend，这些个事件有点类似web的mousedown、mousemove、mouseup,可惜的是成熟的web端已经有click来代表这三个事件的组合，而mobile端没有，加之手机端使用click 有一个莫名的300ms 等待时间。于是乎，很多聪明的开发者都开始使用自定义的 tap 事件。简单的封装逻辑无非就是以下这些：1、监听touchstart事件；2、在touchstart事件发生时，监听touchmove事件。2、根据touchmove 事件是否产生来断定是否在touchend的时候执行事件指定的回调函数。如果你觉得这样太麻烦了，没有关系，可以不用重复造轮子，试试 mike brook 的thumbs.js也不错。还有一点值得我们注意的是在手机上，a 标签被点击时会有一个难看的点击阴影（在andriod上尤其难看）这个阴影可以通过改变CSS 属性 -webkit-tap-highlight 来去掉。

-webkit-tap-highlight:rgba(0,0,0,0);

Localstorage 本地存储
对于 webapp 来说，本地存储可以配合appCache使得webapp和native app一样具有离线浏览的功能，如何利用好本地存储也确实是一件非常值得研究的事情。而目前浏览器的本地存储都只支持字符串的直接存储，虽然也是key/value性质，但是总会觉得有些不便。项目过程中如果使用localstorage，能像用永久变量一样方便自如,还是需要开发者自行封装，虽然很多浏览器以及提供了JSON对象的stringfy和parse，单仍有少数浏览器不支持，如android 2.1。可以试试lawnchair，一个简单的json 存储器，大小只有5k，项目地址http://westcoastlogic.com/lawnchair/

缓存
单独拿出来说缓存其实没有什么意义，但对于把用户群瞄准为高端iPhone用户的开发者还是应该了解，在iPhone的 mobile safari中，缓存是有限制的，在IOS 3.X 版本mobile safari不能缓存超过15KB的单个文件，在IOS4中这个限制是25KB。如果想最大利用缓存的同学可能要权衡一下单个文件的大小还是 HTTP 请求数了。相比之下android的限制要小得多, android 单个文件的缓存限制为2MB。

Iscroll 4
滚动组件，虽然IOS5 已经支持

position:fixed;
overflow:scroll;
-webkit-overflow-scrolling: touch;

但是对于andriod 还遥遥无期的样子，而Iscroll 4目前是很多固定滚动的良好解决方案，连microsoft metro的演示demo和apple官方都在使用Iscroll 4。

JS类库
jquery大名鼎鼎，做前端应该都听过，而在mobile 端再用会显得有些太重了，一大堆兼容IE的代码。虽然使用方便，但是仍然是不推荐的。其实mobile js library设计时有不少都受到了jquery的影响，他们提供的接口几乎一致，比如zepto、xuijs、jqmobi 这些都是基础类库，不带ui组件。如果希望有ui组件的同学可以看看jqtouch 和 sencha touch。我推荐的这些类库有些是只对webkit核心浏览器设计的，毕竟目前这些(andriod 和iPhone)在智能手机里占得比重比较大。

zepto：https://github.com/madrobby/zepto
sxuijs：http://xuijs.com/
jqmobi: http://www.jqmobi.com/

参考：
苹果官方开发者网站关于webapp的配置
 debugging-mobile
mobile-browser-cache-limits

前端代码库JSLab新版发布

解码jQuery系列5 – OOP与jQuery

石川 — Mon, 07 May 2012 01:54:50 +0000

译者注：本系列文章由石川创作，李松峰翻译，w3ctech.com首发，图灵社区转载。

“OOP与jQuery”是“解码jQuery”系列中的一个子系列，主要讨论 jQuery 的内部构成及相关的OOP（Object Oriented Programming，面向对象编程）概念。

在这篇文章中，我们会讨论工厂设计模式，也是jQuery核心中使用的一种设计模式。

1.创建对象

“四人帮”的名著Design Patterns: Elements of Reusable Object-Oriented Software（《设计模式》，http://en.wikipedia.org/wiki/Design_Patterns）把设计模式分为三类：

创建模式：创建对象的各种方式；
结构模式：组合各种对象以实现新的功能；
行为模式：对象之间互操作的方式。

工厂模式属于创建模式，顾名思义，工厂就是创建对象的。

我们先来看一看创建对象的最常见模式。好，以下代码创建了一个包含几个方法的对象。

var taskManager = {};
taskManager.update = function() {
console.log("update");
}
taskManager.read = function() {
console.log("read");
}

如果想通过taskManager创建一个新的任务对象，而且是基于不同的类型分别调用update和read方法，那可以这样做：

var type = "update";
var task;
if (type === 'update') {
task = new taskManager.update();
}

if (type === 'read') {
task = new taskManager.read();
}

可是，如果有10种不同的任务，这样做就太麻烦了。因此，就产生了工厂方法模式。

2.工厂方法模式

为了简化创建对象的工作，可以在taskManager中创建一个工厂方法：

taskManager.factory = function (typeType) {
return new taskManager[typeType];
}

有了这个方法，就可以像下面这样创建对象了：

task = new taskManager[type];

3.jQuery中的工厂方法

在jQuery的core.js中，就有一个类似的创建对象的工厂方法：

var jQuery = function( selector, context ) {
// jQuery对象实际上就是一个“增强版的”init构造函数
return new jQuery.fn.init( selector, context, rootjQuery );
}

使用这种方法的原因很简单，jQuery不知道用户会传入什么样的选择符，或许是标签名，如$(‘p’)；ID，如 $(‘#main’) ，或者类，如 $(‘.item’)。因此，这个方法适合创建类似但事先又不知其具体类型的对象。

这里有一篇文章，叫Essential JavaScript Design Patterns For Beginners, Volume 1（http://addyosmani.com/resources/essentialjsdesignpatterns/book/），讨论了什么时候该用工厂模式，什么时候不该用工厂模式。

系列其他文章

最多留言文章

动态修改script标签中的src属性存在的问题

goddyzhao — Fri, 27 Apr 2012 13:45:25 +0000

今天某个同事遇到一个诡异的问题，问题描述如下：

需求：通过脚本动态修改script标签的src来载入一段外部脚本并执行
实现方式(#1)：

url2的内容如下：

alert('I am dynamic');

结果：

Chrome: 什么事都没发生（没有请求url2）
Firefox: 什么事都没发生（没有请求url2）
IE9：什么事都没发生（请求url2但不执行url2的脚本）
IE(6,7,8): I am dynamic(请求并执行了url2的脚本)

注意实现方式中，第一段的script标签中间是有内容的（空格、换行符以及回车符）。

如何来解释这个问题呢？要解释这个问题，我们来看两个变种的例子，第一个例子（明确内联内容)，如下所示（#2）：

结果如下：

Chrome: I am inline（没有请求url2）
Firefox: I am inline（没有请求url2）
IE9：I am inline（请求url2但不执行url2的脚本）
IE(6,7,8): I am inline I am dynamic(请求并执行了url2的脚本)

再来看看第二个变种的例子(#3)：

其中url1的内容如下：

alert('I am url1');

结果如下：

Chrome: I am url1（没有请求url2）
Firefox: I am url1（没有请求url2）
IE9：I am url1（请求url2但不执行url2的脚本）
IE(6,7,8): I am url1 I am dynamic(请求并执行了url2的脚本)

首先这里肯定的是src属性是修改成功的，可以通过看dom的变化看到src已经设置进去了。这个时候我们比对这三个例子，思考几十秒。分析下这三个例子，其实#2和#1是一样的，这里用#2是为了说明#1中的空格、换行符以及回车符会被浏览器认为是内联的脚本。通过比对#2和#3，是不是会让你想到什么？没错，我们第一个会想到的就是：当script标签既有src属性又有内联脚本的时候浏览器该如何处理？ ，先来解释这个问题。

一谈到浏览器应该怎样处理，就不得不翻出各种宝典，这次不再是葵花宝典了，而是九阴真经(W3C的HTML4标准)，标准中关于script标签的src部分有如下一段话：

If the src attribute is not set, user agents must interpret the contents of the element as the script. If the src has a URI value, user agents must ignore the element’s contents and retrieve the script via the URI

上面这段话的意思就是说：如果src没有设置，那么就执行内联脚本，如果src设置了浏览器就必须忽略内敛脚本而要去请求src指定的url的内容

这解释了为什么#3中标准浏览器（甚至IE6，7，8）都没有执行内联脚本（因为src设置了url1）。

搞清楚了这个基础问题之后，接下来问题就定位到了动态修改script的src属性的时候浏览器如何处理？ ，从结果来看，标准的浏览器都没有去请求url2（更改src无效），这回IE6，7，8终于犯傻了。当然了，咱们也不能随随便便说人家犯傻，要拿出证据，这个时候继续拿出九阴真经W3C的HTML5标准，其中有这样一句话：

Changing the src, type, charset, async, and defer attributes dynamically has no direct effect; these attribute are only used at specific times described below.

意思就是说：修改src是没用的，对src的处理只会在特定的时候进行（个人猜测就是第一次看到这个属性的时候浏览器会去做相应处理，之后就无视它了）。

好了，这下真相大白了：这解释了为啥#3和#1中除了IE6，7，8之外其他浏览器都没有去请求url2（IE9请求了，但没执行），而且实验发现IE6，7，8对动态修改src都会做请求执行处理。

最后，这个故事至少告诉我们：写script标签的时候千万别手贱打回车。

参考文档：

Qatrix，国产超轻量级高性能的JavaScript框架

qatrix — Wed, 25 Apr 2012 03:01:15 +0000

Qatrix是一个简单易用，代码优美，同时专注于高性能应用开发的超轻量级JavaScript框架。这是在社交网站Catfan喵友成立两周年之际发布的一个开源新项目。是由其创始人黎言卓在开发Catfan和Mu6过程中，经过知识不断积累和研究，独立设计和开源出来的项目。

Qatrix具有以下几个特点：

硬件加速的动画效果
动画效果基于CSS3 transition，使用native code处理，并具备硬件加速特性，比以往单纯基于JavaScript处理的框架更加流畅，显著提升页面的视觉效果。这也是目前首个支持这种特性的完整JavaScript框架。

高性能代码
支持CSS3和HTML5的特性，专为高性能做前提而优化和设计，执行效率平均比其它JavaScript框架高50%以上。

易学易用
命名规则简单，多数和jQuery类似，开发者不需要记忆和理解太多新的概念就能轻松上手。

麻雀虽小五脏俱全
只有4.7KB的文件大小（gzipped），包含了多种元素选择器，DOM，AJAX，Cookie，基于硬件加速的动画处理，事件处理，缓存系统等足够满足大部分应用开发的需要的60+个功能。不会显著增加页面载入的时间。

良好的兼容性
兼容IE6-IE10，Chrome，Firefox，Safari，Opera等大部分主流浏览器。

基于最宽松的MIT开源协议，任何人都可以免费使用。

Qatrix项目之前已经吸引了一批国外开发者的关注和讨论，经过社区反馈和多次版本的频繁改进和修复后，目前公开发布出首个稳定版本。目前在GitHub的关注数也在不断上升中。

Qatrix目前托管在GitHub上http://github.com/qatrix/Qatrix
官方网站：http://qatrix.com
API文档：http://qatrix.com/doc
性能测试：http://qatrix.com/benchmark

记“3月24日上海站交流会”

周裕波 — Tue, 27 Mar 2012 14:56:25 +0000

2012年3月24日，阳光明媚，40多人聚集在盛大在线的会议室一起听着来自百度的张立理的《异步编程及浏览器执行模型》的分享，聊着自己心中的疑惑及自己的对未来的展望。这就是web标准化交流会第29期上海站的现场。
这次来参加交流会的人数比平常多，和平常还有不一样的地方就是这次大家比以前肯说，肯问了，很多人以前不敢说出自己心中的疑惑，而且这次也体现出了其实前端圈子里的同学们也是很热心的。说了这么多没有用的话以后，我们来还是来回顾回顾当天交流会的情况吧。
张立理在做完自我介绍以后，谈到了他的PPT是标注有时间的，为什么会在PPT上标注时间呢？原因是因为由于前端发展得太快，所以PPT上的信息不一定是最准确的，他并且强调，如果当你在实际测试的时候发现与PPT不符时，以你实际测试为准。所以这一点是值得学习的。

所谈到的内容有异步的概念，浏览器中什么情况下会碰到异步，浏览器如何处理异步及浏览器的响应，还有具体的一些实践。
什么是异步：举了一个例子，就是如果你是老板，你让你的秘书帮你写一份稿子，你安排完这个任务以后，你继续喝茶干别的事情，等到下午你的秘书来找你，告诉你稿子写完了。这个过程就是异步。
在整个演讲过程中提到了setTimeout的响应时间问题，还有AJAX的问题，同时使用了jquery的AJAX的架构图进行了举例，更多需要了解的内容可以观看视频：

在张立理分享完以后，大家进行了交流与讨论，一些同学提出了在工作中遇到的问题，也有一些同学问到了提升自己的能力。现场的同学们也相互谈了自己对这些问题的建议和意见。有一位同学多次问到如何提升，张立理还有教主他们都提到了想提高自己的能力需要多练习。但是他好像找不到合适的项目进行练习，有一位设计师MM就说到，我现在在学CSS，但是感觉有难度，我有一个朋友是产品经理，我是设计师，我们想做一个东西，你来和我们一起做吧。其实像这样也是挺好的，既有了搭档，又可以提升自己，还可以相互帮助，真好。
整个交流会在最后一位同学提出了一个特别的需求中结束，非常感谢大家对交流会的支持与帮助！

本次交流会更多内容的总结请见：http:/w3ctech.com/event/2。

最多留言文章

更加直观地了解hasLayout和BFC

吴天豪 — Tue, 20 Mar 2012 06:13:28 +0000

网络上有很多关于hasLayout和BFC相关的文章，但是大部分都显得有些晦涩难懂。所以想用一些比较直观的例子来说明hasLayout和BFC给平时的布局带来的影响。

基础知识

在讲hasLayout和BFC之前，先简单地过一下元素布局的一些基本知识。

元素本身的布局方式可以从display上表现出来

block，对应块级元素
inline，对应行内元素
inline-block
none

当然，还有更多的一些属性，我们只提及主要部分。

块级元素，在浏览器中通常是垂直布局，然后可以用margin来控制块级元素之间的间距，并列和嵌套的块级元素都存在外边距，也就是margin合并的问题。

而行内元素是以水平的方式布局，垂直方向的margin，padding都是无效的，并且设置的宽高也是无效的。

BFC的全名是block formatting context，转成中文就是块级元素格式上下文，听起来有些别扭，字面上的意思大概就是一个元素的布局上下文类型。

而大家应该对hasLayout已经很熟悉了，更多可能是因为IE5.5/6/7上一些奇怪的bug（还有处于quirks模式下的IE8）。

BFC和hasLayout是作为元素的一种隐藏属性存在，~~并且一旦触发之后就不可逆转~~。他们之间有很多共同点。（注：没有办法设置hasLayout=false，除非把一开始那些触发hasLayout的CSS属性去除，此处是我没有表达好，谢谢@貘吃馍香指正）

共同点

1.不和浮动元素重叠

如果一个浮动元素后面跟着一个非浮动的元素，那么就会产生一个覆盖的现象，很多自适应的两栏布局就是这么做的。

这里我们使用msdn上的一个例子，来说明haslayout和BFC对这个情况的影响。

 123

     The quick brown fox jumped over the lazy dog's back.
     The quick brown fox jumped over the lazy dog's back. 
     The quick brown fox jumped over the lazy dog's back.
     The quick brown fox jumped over the lazy dog's back. 
     The quick brown fox jumped over the lazy dog's back.

我们可以看到，文字环绕着浮动元素进行布局。

但是如果我们用overflow:hidden和zoom:1，分别触发BFC和hasLayout，那么，结果会是如何呢？

加上触发条件的代码如下

 123

     The quick brown fox jumped over the lazy dog's back.
     The quick brown fox jumped over the lazy dog's back. 
     The quick brown fox jumped over the lazy dog's back.
     The quick brown fox jumped over the lazy dog's back. 
     The quick brown fox jumped over the lazy dog's back.

结果如下图，点此查看demo

那么，实际开发中，这个特性可以用于解决什么问题呢？

比如百度知道（http://zhidao.baidu.com/）首页右栏有一个本周知道之星

结构也很简单，就是


 天涯魔鬼训练营
 大将军 十八级

他给img和div分别加了float:left来解决左右栏排版的问题。

但是，假设（仅仅是假设）描述部分多了几个字，就变成了这样

实际情况中不应该存在那么高的等级，但是至少，我们有办法提供布局的容错性。

那么，如果我们将img设置float，div不设置float，效果就变成了这样：

我多加了几个字，显得有些夸张，很明显，结果依然不是我们想要的。

我们想要的结果应该是这样。

怎么样才能在文字长度不可控的情况下，保证布局的稳定性呢？

再回到之前讲的共同点1，你应该知道怎么解决这个问题了。

点此查看demo

当然，还有更多应用的场景

例如一个简单的三栏布局，左右两栏定宽，中间部分自适应，点此查看demo

2.清除元素内部浮动

点此查看示例

在示例中，我们可以看到outer元素在设置overflow:hidden和zoom:1之后，元素内部浮动对外部的影响被清除。也就是我们最常用的清除浮动在IE5.5/6/7上生效的原理。

.k2-fix-float:after{
 content:"\0020";
 display:block;
 height:0;
 clear:both;
}
.k2-fix-float{
 *zoom:1;
}

3.嵌套元素边距折叠问题的解决

点此查看demo

不同点

1.hasLayout的元素被限制为一个矩形

触发haslayout的元素是可以设置宽高的，而触发BFC的元素不一定可以设置宽高，比如一个行内元素，设置float或者设置overflow都可以触发BFC，但是前者可以设置宽高，后者却不能，但是仔细考虑一下，给一个行内元素设置overflow:hidden还是一见比较扯蛋的事情。

点此查看demo

2.hasLayout的元素设置display:inline后与inline-block行为类似

该特性在IE6/7下解决inline-block问题时也有遇到

.k2-inline-block{
 display:-moz-inline-stack;
 display:inline-block;
 *display:inline;
 *zoom:1;
 vertical-align:middle;
 position:relative;/* 解决因为父容器{display:inline;}问题导致Firefox中li里面的链接不可点的bug */
 _position:static;/* 解决因为IE6中因为上一行代码带来在{position:relative}容器中移位在bug */
}

这个状态下的元素和普通文字一样在水平方向连续排列，受vertical-align的影响，并且可以按照容器大小自适应调整。

参考资料

本文所用到的CSS解决方案来自口碑网K2框架，详细可以访问https://github.com/f2e/k2，K2框架改进自YUI3，作为口碑网前端、前后端的解决方案。

最多留言文章

2月25日第28期web标准化交流会北京站总结

周裕波 — Tue, 20 Mar 2012 05:43:10 +0000

Web标准交流会北京站第28期已于2012年2月25日在盛大创新院北京成功举办。本次交流会的主题为PhoneGap开发，邀请了来自Adobe的技术布道师董龙飞和新浪的前端工程师董玉伟到现场为大家分享跨平台移动开发工具PhoneGap。

董龙飞对PhoneGap的来龙去脉做了总体的介绍，很多开发者已经使用HTML5、CSS3等最新技术做Web应用开发，也有不少开发者涉足移动开发，包括Android的Java编程、iOS的Obejct-C编程等。在2008年，旧金山，针对iPhone的开发者会议上，几位与会者希望通过JavaScript调用iPhone的本地特性，就在一天之内做了一个最基本的PhoneGap想法原型，并逐渐获得的社区的认可，扩展到了其他移动平台，如Android。后来，PhoneGap被Adobe收购，并被贡献给了Apache基金会，开始名为“CallBack”,后来改为“Cordova”，但两者不完全一样。Cordova是其中最核心的一部分，PhoneGap还包括了外部工具等。

借助PhoneGap，Web开发者可以把已有的Web应用打包成移动平台上的本地应用或者应用商店里的App，让用户直接下载安装，甚至支持BlackBerry、Windows Phone等应用格式。在开发移动应用时，开发者经常需要利用平台本身的一些特性，比如需要访问手机通讯录，或者GPS传感器信息等，PhoneGap提供了一些方便的JavaScript接口，帮助开发者直接调用移动平台的本地特性。不同的移动设备支持的特性并不相同，或者有时会遇到CPU密集性的技术需求，此时JavasSript代码并不合适，开发者可能想用本地的编程语言来写程序，然后再用JavaScript来调用，提高整个应用的性能。PhoneGap支持插件机制，开发者可以使用本地语言来编写程序，然后通过Javascript集成，由PhoneGap打包成App。总的来说，PhoneGap的特性包括：将HTML/JavaScript代码打包成本地App，帮助开发者部署到各种平台上，并提供了访问移动应用本地特性的接口，同时支持多语言混合的插件机制。

但PhoneGap不是JavaScript框架，开发者需要借助其他JS框架，Phone不提供IDE环境，由开发者自己选择。

如果想把Web应用打包成各种移动平台的App，开发者可以利用在线的PhoneGap Build，自动生成各种应用格式，并发布到移动平台的网上商店中。Phone Build针对开源免费的Web应用也是免费的。董龙飞还举例详细介绍了PhoneGap的内部实现机制和应用的调用方式。

新浪高级工程师董玉伟则探讨了PhoneGap插件扩展机制，他先后介绍了PhoneGap的插件实现原理、编程技巧等。

插件之间的通信通过postMessage和onMessage接口来显示，在调用系统接口，设计到用户隐私数据时应该请求用户授权。

他还分享了自己的移动开发经验，包括：启动时不要加载渲染大量html（使用JS渲染大数据更快）；谨慎使用Scroll，等系统进化到支持Fixed定位。

PhoneGap现已完全支持Windows Phone 7所有的原生功能，其支持力度达到了iOS与Android的水平。

目前，PhoneGap API支持的功能包括：

Accelerometer——加速计是检测设备在当前方向上所做相对运动变化（增、减量）的运动传感器。加速计可以检测沿X、Y和Z轴的三维运动。加速度数据通过accelerometerSuccess回调函数返回。
Camera——选择使用摄像头拍照，或从设备相册中获取一张照片。图片以base64编码的字符串或图片URI形式返回。
Compass——罗盘是一个检测设备方向或朝向的传感器，使用度作为衡量单位，取值范围从0度到359.99度。通过compassSuccess回调函数返回罗盘朝向数据。
Connection——Connection对象提供对设备的蜂窝及WiFi连接信息的访问。
Contacts——提供对设备通讯录数据库的访问。
Geolocation——Geolocation提供设备的位置信息，例如经度和纬度。位置信息的常见来源包括全球定位系统（GPS），以及通过诸如IP地址、RFID、WiFi和蓝牙的MAC地址、和GSM/CDMA手机ID的网络信号所做的推断。不能保证该API返回的是设备的真实位置信息。这个API是基于W3C Geo location API Specification实现的。有些设备已经提供了对该规范的实现，对于这些设备采用内置实现而非使用PhoneGap的实现。对于没有地理位置支持的设备，PhoneGap的实现应该是完全兼容W3C规范。
Storage——提供对设备的存储选项的访问。此API基于W3C WEB SQL Database Specification和W3C Web Storage API Specification。有些设备已经提供了对该规范的实现，对于这些设备采用内置实现而非使用PhoneGap的实现。对于没有存储支持的设备，PhoneGap的实现应该是完全兼容W3C规范。

感谢崔康为本次交流会提供总结。
崔康：热情的技术探索者，资深软件工程师，InfoQ编辑，从事企业级Web应用的相关工作，关注性能优化、Web技术、浏览器等领域。

最多留言文章

【译】在现阶段使用HTML5语义标签

吴天豪 — Thu, 15 Mar 2012 11:49:58 +0000

原文地址：http://www.nczonline.net/blog/2011/03/22/using-html5-semantic-elements-today/

存在的问题

现阶段使用HTML5标签可能遇到的最大问题就是如何在不支持新标签的浏览器中做恰当的处理。当我们在页面中使用HTML5元素时，可能会得到三种不同的结果。

结果1：标签被当作错误处理并被忽略。那么DOM构建的时候，就会当作这个标签不存在。

结果2：标签会被当作错误处理，并在DOM构建的时候依然会按照预期的代码进行创建，并且HTML标签会被构造成行内元素（也就是说虽然不能识别，但是代码里section标签依然会在dom中创建一个对应section节点，但是属于行内元素）。

结果3：标签被识别为HTML5标签，然后用DOM节点对其进行替换。DOM在构建的时候和预想的一致，并且合适的样式会应用到标签上（大部分情况下是块级元素）。

有一个具体的例子，思考如下的代码：


 
 title
 text

很多浏览器（比如Firefox 3.6和Safari4）解析的时候都会将div作为最外层的元素，然后div里面是一个识别不了的元素（section），它会在DOM中创建，并被作为一个行内元素存在。h1和p元素都是作为section元素的子节点。因为section在DOM中真实存在，所以也可以修改其样式。这种情况对应结果2。

IE9之前的版本会认为section标签是一个错误，并直接将其忽略，那么h1和p标签会被解析，然后成为div标签的子节点。也会被认为是一个错误并直接跳过。在这些浏览器中实际有效的代码是这样的：


 title
 text

那么，旧版本的IE浏览器除了生成的DOM结构和其他浏览器不一样，其对不可识别标签的容错能力还是很棒的。因为section节点没有在DOM树中构建，所以也就不能给其增加样式。这种情况对应结果1。

当然，支持HTML5的浏览器比如IE9，Firefox4+，Safari5+会创建正确的DOM结构，然后这些标签会默认附带HTML5规范中定义的默认样式。

那么，我们所面临的最大问题就是同样的代码在不同的浏览器中形成了不同的DOM结构，并且含有不同的样式。

解决方案

人们想出了很多在现阶段页面中使用HTML5元素的解决方案。每一个解决方案为了做到兼容都会遇到一些特定的问题。

JavaScript解决方案

JavaScript解决方案目的是解决在旧版本的IE中样式应用的问题。老版本的IE不会识别不明元素已经是一个耳熟能详的特性，而如果这些元素已经通过document.createElement()创建，那么浏览器就可以识别这些标签，并可以将其在DOM树中构建，然后允许开发者对其应用样式。

这个方法可以确保HTML5标签能在旧版本IE中对应创建DOM节点，然后可以对其应用样式。这个方法将HTML5块级元素设置成display:block，从而可以在各个浏览器中做到兼容。

我不喜欢这个解决方案，因为它破坏了我最主要的web应用开发原则：我们不应该使用JavaScript来控制布局。不仅仅是因为这个做法给那些禁用脚本的用户带来了糟糕的用户体验，更重要的是，如果我们希望我们的web应用代码是面向未来，并且维护性高的，那么必须将视图相关部分分离出来。这个方案对在跨浏览器中构建相同的DOM结构很有帮助，也可以确保你的JavaScript和CSS在各个地方运行结果相同，但是这个优势并不能改变我对这个方法的不认同。

Namespace hack

永远不要缺乏使用hack解决问题的能力，在IE中还有其他技术来让浏览器识别不明的标签。这个来自Elco Klingen日志的方法一开始引起了广泛的关注。该技术包含了一个XML形式的命名空间，并使用了含有namespace前缀的元素。例如：

前缀html5是纯粹是用于这个例子而且也不是官方支持的，你甚至可以用”foo”作为前缀，结果还是一样。有了前缀之后，IE会识别新的元素，从而可以应用样式。在其他浏览器中一样有效，那么最后，你就成功地在各个浏览器中构建了一样的元素和一样的样式。

这个方法的缺陷很明显：你必须在HTML文档中使用XML格式的命名空间，同样，你也需要在css中这么做:

html5\:section {
 display: block;
}

这并不是我期望Web开发者编写代码的方式。这是一个非常杰出的解决方案，但是这让应用变得不自然。我不希望看到文件中充满了带命名空间的元素。

Bulletproof技术（防弹衣技术）

我在YUIConf2010上第一次接触到这个技术，当时是Tantek Çelik在做一个名为《HTML5: Right Here, Right Now》的分享。Tantek建议在所有新的HTML5块级元素中增加一个内部的div元素，然后包含一个CSS class，用这个元素来替代HTML元素（类似在里面穿了一件防弹衣），例如：

在应用样式的时候，Tantek推荐直接给div增加样式，而不是给新元素增加样式

推荐使用：

.section {
 color: blue;
}

而不是：

section {
 color: blue;
}

这个方案的原理是用简单的方式将原来的样式应用方式转移到一个代表了HTML5标签的元素上。由于我一般情况下不会将样式通过标签名的方式应用到元素上，所以我并不支持他的建议。

这个方案的缺陷是不同的浏览器构建了不同的DOM结构，那么你必须在编写JavaScript和CSS的时候格外小心。获取子节点或者父节点的时候，不同的浏览器返回的结果可能会不一样。特别是在下面的代码中：

反向的bulletproof技术

还有一些文章，比如Thierry Koblentz写的《HTML elements and surrogate DIVs》，尝试使用和Tanteck方案相反的技术，也就是把HTML5元素放在div元素内部，例如：

这个方案唯一的不同是HTML5元素的位置，其他都一样。喜欢这个技术的支持者认为他的一致性很好（适用于所有的元素，包括

）。但是DOM结构的不同让这个方案意义变得不大。他的主要优势是技术上的一致性。

我的方案

我的主要目标是确保我只需要修改HTML部分。这就意味着不需要修改CSS和JavaScript。为什么会有这样的需求？需要修改的Web应用视图越多，你越有可能制造bug。将改变限制到一个视图也就限制了bug的出现，即使出现了bug，也可以减少你查找错误的范围。如果一个视图破相了，我可以知道这是因为我增加了一个section元素，而不是考虑是不是CSS文件修改来带的影响。

在研究了所有这些解决方案，并进行一些尝试和设计之后，我回到了Tantek的方案。这是唯一一个只需要修改HTML而不用动CSS和HTML的方案。现在，我在他的方案基础上做了一些改进，来达到我想要的结果。

首先，我不会给那些代表HTML5元素的class增加样式（所以我不会使用.section这样的选择器）。我保留了div元素，然后再增加一个带语义的class来应用样式，并作为进行JavaScript操作的钩子。例如，这样的代码：

经过改进后：

这样的修改完成后，我依然使用.content作为样式和脚本的入口。这也意味着我不需要修改CSS和JavaScript。

然后，为了避免hgroup标签这样的情况，我选择不使用这个标签。我在我已有的所有页面中没有找到任何一个使用了这个标签的。由于hgroup标签只能包含标题元素，如果你确实想要使用这个标签，那么使用hrgoup来包含本身是非常安全的（假设它没有包含其他的块级元素）。

我花了很多时间来测试比较bulletproof和反向的bulletproof哪个更好一些。我做选择时最主要的决定因素就是反向的bulletproof需要我去增加CSS代码。在那些为HTML5标签创建了DOM节点但是没有应用默认样式的元素来说，div元素里包含了一个HTML5块级元素在很多情况下都会搅乱我的布局，因为创建的DOM节点是行内元素。我不得不明确增加CSS规则来让这个节点变成块级元素从而可以正常布局，这也就违反了我不修改CSS文件的初衷。

论证

在与这个知识点相关的讨论中，有一件事让我觉得很沮丧，人们怎么可以这么快就否定一个解决方案，仅仅因为发现这个方案至少在一种情况下不管用。我在这里展示的所有方案都不是完美的。他们也肯定没有覆盖所有你可能遇到的情况。在你给我展示任何一项技术的时候，我基本上可以保证找到一种情况，在这种情况下你所展示的技术是没有用处的。但是这样并不能让这个技术失去价值，它可以让你了解技术上的限制从而做出更好的选择。

在我的研究中，我使用了多个页面，然后在这些页面上使用修改过后的bulletproof技术。我分别在简单和复杂的布局中，含有和不含有JavaScript交互进行测试。在每一个例子中，我只需要修改HTML就可以让页面表现正确（不修改JavaScript和CSS）。那么，子节点和父节点的问题怎么办？有趣的事情是我在测试中并没有遇到这样的问题。

但是，理由很简单，因为我对代码苛刻的态度。我认真地做了第二遍检查：

标签名和ID不会用于应用样式（只是用class）
尽量选择常用的CSS选择器并且尽量减少选择器的使用
JavaScript代码不依赖于特定的DOM结构
标签名不用于操作DOM

我注意到另一个有趣的事情是我使用了HTML5元素作为容器。而这些新的元素仅仅是作为功能性模块的边界。你应该花费你的大部分时间为内部的元素编写样式和脚本而不是处理各个模块间的样式和脚本。由于我的JavaScript和CSS标签都应用在容器的内部，所以一切都显得很顺利。我想这才是一个真正的代码质量高的网站。

总结

我最后决定并推荐大家使用的是Tantek的bulletproof技术的改进版。很明显，在CSS和JavaScript领域里，这个名字显得有些不太恰当，但是在我的实验里，它确实允许我仅仅改变页面的HTML部分的同时还能保证页面正常工作。我确信关于这个主题的辩论仍然会持续在公司和网络上，而我希望的是这些文章能够帮助你做出明智的选择。

最多留言文章

通过什么途径能够深入了解JavaScript引擎是如何工作的？

goddyzhao — Thu, 01 Mar 2012 16:30:17 +0000

昨天收到一封来自深圳的一位前端童鞋的邮件，邮件内容如下（很抱歉，未经过他的允许，公开邮件内容，不过我相信其他人肯定也有同样的问题，所以，直接把问题原文抛出来）：

“读了你的几篇关于JS（变量对象、作用域、上下文、执行代码）的文章，我个人觉得有点抽象，难以深刻理解。我想请教下通过什么途径能够深入点的了解javascript解析引擎在执行代码前后是怎么工作的，ecma英文版实在看不下去呵呵。”

其实这个问题个人觉得太笼统了，直接回答很难回答，所以，我打算先把他的问题拆解成如下几个子问题，并对其表达个人的观点，希望对有同样困惑的童鞋能够有所帮助。

1. 什么是JavaScript解析引擎？

简单地说，JavaScript解析引擎就是能够“读懂”JavaScript代码，并准确地给出代码运行结果的一段程序。比方说，当你写了 var a = 1 + 1; 这样一段代码，JavaScript引擎做的事情就是看懂（解析）你这段代码，并且将a的值变为2。

学过编译原理的人都知道，对于静态语言来说（如Java、C++、C），处理上述这些事情的叫编译器（Compiler），相应地对于JavaScript这样的动态语言则叫解释器（Interpreter）。这两者的区别用一句话来概括就是：编译器是将源代码编译为另外一种代码（比如机器码，或者字节码），而解释器是直接解析并将代码运行结果输出。比方说，firebug的console就是一个JavaScript的解释器。

但是，现在很难去界定说，JavaScript引擎它到底算是个解释器还是个编译器，因为，比如像V8（Chrome的JS引擎），它其实为了提高JS的运行性能，在运行之前会先将JS编译为本地的机器码（native machine code），然后再去执行机器码（这样速度就快很多），相信大家对JIT（Just In Time Compilation）一定不陌生吧。

我个人认为，不需要过分去强调JavaScript解析引擎到底是什么，了解它究竟做了什么事情我个人认为就可以了。对于编译器或者解释器究竟是如何看懂代码的，翻出大学编译课的教材就可以了。

这里还要强调的就是，JavaScript引擎本身也是程序，代码编写而成。比如V8就是用C/C++写的。

2. JavaScript解析引擎与ECMAScript是什么关系？

JavaScript引擎是一段程序，我们写的JavaScript代码也是程序，如何让程序去读懂程序呢？这就需要定义规则。比如，之前提到的var a = 1 + 1;，它表示：

左边var代表了这是申明（declaration）,它申明了a这个变量
右边的+表示要将1和1做加法
中间的等号表示了这是个赋值语句
最后的分号表示这句语句结束了

上述这些就是规则，有了它就等于有了衡量的标准，JavaScript引擎就可以根据这个标准去解析JavaScript代码了。那么这里的ECMAScript就是定义了这些规则。其中ECMAScript 262这份文档，就是对JavaScript这门语言定义了一整套完整的标准。其中包括：

var，if，else，break，continue等是JavaScript的关键词
abstract，int，long等是JavaScript保留词
怎么样算是数字、怎么样算是字符串等等
定义了操作符（+，-，>，<等）
定义了JavaScript的语法
定义了对表达式，语句等标准的处理算法，比如遇到==该如何处理
⋯⋯

标准的JavaScript引擎就会根据这套文档去实现，注意这里强调了标准，因为也有不按照标准来实现的，比如IE的JS引擎。这也是为什么JavaScript会有兼容性的问题。至于为什么IE的JS引擎不按照标准来实现，就要说到浏览器大战了，这里就不赘述了，自行Google之。

所以，简单的说，ECMAScript定义了语言的标准，JavaScript引擎根据它来实现，这就是两者的关系。

3. JavaScript解析引擎与浏览器又是什么关系？

简单地说，JavaScript引擎是浏览器的组成部分之一。因为浏览器还要做很多别的事情，比如解析页面、渲染页面、Cookie管理、历史记录等等。那么，既然是组成部分，因此一般情况下JavaScript引擎都是浏览器开发商自行开发的。比如：IE9的Chakra、Firefox的TraceMonkey、Chrome的V8等等。

从而也看出，不同浏览器都采用了不同的JavaScript引擎。因此，我们只能说要深入了解哪个JavaScript引擎。

4. 深入了解其内部原理的途径有哪些？

搞清楚了前面三个问题，那这个问题就好回答了。个人认为，主要途径有如下几种（依次由浅入深）：

看讲JavaScript引擎工作原理的书
这种方式最方便，不过我个人了解到的这样的书几乎没有，但是Dmitry A.Soshnikov博客上的文章真的是非常的赞，建议直接看英文，实在英文看起来吃力的，可以看我翻译的译本
看ECMAScript的标准文档
这种方式相对直接，原汁原味，因为引擎就是根据标准来实现的。目前来说，可以看第五版和第三版，不过要看懂也是不容易的。
看JS引擎源代码
这种方式最直接，当然也最难了。因为还牵涉到了如何实现词法分析器，语法分析器等等更加底层的东西了，而且并非所有的引擎代码都是开源的。

5. 以上几种方式中第一种都很难看明白怎么办？

其实第一种方式中的文章，作者已经将文档中内容提炼出来，用通俗易懂的方式阐述出来了。如果，看起来还觉得吃力，那说明还缺少两块的东西：

对JavaScript本身还理解的不够深入
如果你刚刚接触JavaScript，或者说以前甚至都没有接触过。那一下子就想要去理解内部工作原理，的确是很吃力的。首先应该多看看书，多实践实践，从知识和实践的方式来了解JavaScript预言特性。这种情况下，你只需要了解现象。比方说，(function(){})() 这样可以直接调用该匿名函数、用闭包可以解决循环中的延迟操作的变量值获取问题等等。要了解这些，都是需要多汲取和实践的。实践这里就不多说了，而知识汲取方面可以多看看书和博客。这个层面的书就相对比较多了，《Professional JavaScript for Web Developers》就是本很好的书（中文版请自行寻找）。
缺乏相应的领域知识
当JavaScript也达到一定深度了，但是，还是看不大明白，或者没法很深入到内部去一探究竟。那就意味着缺少对应的领域知识。这里明显的就是编译原理相关的知识。不过，其实对这块了解个大概基本看起来就没问题了。要再继续深入，那需要对编译原理了解的很深入，比如说词法分析采用什么算法，一般怎么处理。会有什么问题，如何解决，AST生成算法一般有哪几种等等。那要看编译原理方面的书，也有基本经典的书，比如《Compilers: Principles, Techniques, and Tools》这本也是传说中的龙书，还有非常著名的《SICP》和《PLAI》。不过其实根据个人经验，对于Dmitry的文章，要看懂它，只要你对JavaScript有一定深度的了解，同时你大学计算机的课程都能大致掌握了（尤其是操作系统），也就是说基础不错，理解起来应该没问题。因为这些文章基本没有涉及底层编译相关的，只是在解释文档的内容，并且其中很多东西都是相通的，比如：context的切换与CPU的进程切换、函数相关的的局部变量的栈存储、函数退出的操作等等都是一致的。

以上就是个人对这个问题的看法，除此之外，我觉得，学习任何技术都不能操之过急，要把基础打扎实了，这样学什么都会很快。

w3ctech

[转载至图灵社区]对话《JavaScript高级程序设计》作者 Nicholas C. Zakas（中文版）

最多留言文章

webapp 开发进阶

相关文章

解码jQuery系列5 – OOP与jQuery

系列其他文章

最多留言文章

动态修改script标签中的src属性存在的问题

相关文章

Qatrix，国产超轻量级高性能的JavaScript框架

相关文章

记“3月24日上海站交流会”

最多留言文章

更加直观地了解hasLayout和BFC

基础知识

共同点

1.不和浮动元素重叠

天涯魔鬼训练营

2.清除元素内部浮动

3.嵌套元素边距折叠问题的解决

不同点

1.hasLayout的元素被限制为一个矩形

2.hasLayout的元素设置display:inline后与inline-block行为类似

更多补充

参考资料

最多留言文章

2月25日第28期web标准化交流会北京站总结

最多留言文章

【译】在现阶段使用HTML5语义标签

存在的问题

title

title

解决方案

JavaScript解决方案

Namespace hack

Bulletproof技术（防弹衣技术）

反向的bulletproof技术

我的方案

论证

总结

最多留言文章

通过什么途径能够深入了解JavaScript引擎是如何工作的？

1. 什么是JavaScript解析引擎？

2. JavaScript解析引擎与ECMAScript是什么关系？

3. JavaScript解析引擎与浏览器又是什么关系？

4. 深入了解其内部原理的途径有哪些？

5. 以上几种方式中第一种都很难看明白怎么办？

最多留言文章