我一直在为Jscex寻找好用的JavaScript解析器，之前我用的是Narcissus，也写过相关文章。不过可惜的是，Narcissus使用了SpiderMonkey的扩展，因此它并不是用ECMAScript 3实现的，无法在IE 8等浏览器中使用。目前Jscex使用的是NarrativeJS中旧版的Narcissus，但是我并不喜欢它输出的AST结构，使用中也发现高级功能里的一些bug，有些食之无味弃之可惜的感觉，而改写新版Narcissus又必须大动干戈。最近我接触到了UglifyJS，发现它的解析器相当不错，性能也比Narcissus高出许多，在此介绍给大家。
UglifyJS是个JavaScript压缩器，效果和Google Closure Compiler相比有过之而无不及。对于现代化的JavaScript压缩器来说，简单的去除空白和压缩局部变量是远远不够的，同时需要理解代码的语义，将其替换成提及更小的形式(Uglify的说明页上有许多描述)。这显然需要一个JavaScript解析器。UglifyJS基于NodeJS开发，不过可以在各种支持CommonJS模块系统的JavaScript引擎/平台上运行。如果没有CommonJS，也只需将exports相关的代码去掉即可。
JavaScript解析器的作用自然是将JavaScript代码分解成AST，然后根据AST便可以做到许多有趣的事情。相同的AST可以在内存中有不同的表现形式，例如之前提到我不太喜欢Jscex目前使用的旧版Narcissus，一个重要的原因便是它的AST结构不够友好(***的Narcissus倒不错)。此外，虽然它提供了一些高级功能，例如标注了每个元素在源代码中的位置，这样使用者就可以直接根据getSource方法获得它对应的源代码——只可惜经试验这个功能有bug，这迫使我还得遍历完整的AST。
UglifyJS的JavaScript分词器和解析器存放在源代码的parse-js.js文件中，移植于parse-js项目，后者是一个用Common Lisp实现的类库。现在您应该可以猜到它输出的AST是什么表现形式了吧。没错，就是个“表”，用JavaScript来表示，就是个数组套数组。我写了点简单的代码对其进行格式化输出，您可以在这里简单尝试一下UglifyJS的解析器。这个输出虽然简单，但对于Jscex来说也已经完全够用了。
使用
打开parse-js.js文件，您会看到这样一些代码：
- /* -----[ Tokenizer (constants) ]----- */
- var KEYWORDS = array_to_hash([
- ...
- ]);
- var RESERVED_WORDS = array_to_hash([
- ...
- ]);
- ...
- function parse($TEXT, exigent_mode, embed_tokens) {
- ...
- }
- /* -----[ Exports ]----- */
- exports.tokenizer = tokenizer;
- exports.parse = parse;
- exports.slice = slice;
- exports.curry = curry;
- exports.member = member;
- exports.array_to_hash = array_to_hash;
- exports.PRECEDENCE = PRECEDENCE;
- exports.KEYWORDS_ATOM = KEYWORDS_ATOM;
- exports.RESERVED_WORDS = RESERVED_WORDS;
- exports.KEYWORDS = KEYWORDS;
- exports.ATOMIC_START_TOKEN = ATOMIC_START_TOKEN;
- exports.OPERATORS = OPERATORS;
- exports.is_alphanumeric_char = is_alphanumeric_char;
- exports.set_logger = function(logger) {
- warn = logger;
- };
UglifyJS是基于CommonJS模块机制编写的，这一个文件其实就是个模块，它对外的方法通过exports暴露出来。如果我们将其作为普通的JavaScript文件引入到浏览器中，显然会报“export未定义”异常。理论上说，如果定义一个exports对象，甚至去除和exports有关的代码就能正常使用parse方法了。不过这么做也有个严重的问题，那就是对根对象的“污染”实在是太严重了，例如在浏览器中所有的函数，定义都出现在window上，再引入一些其他类库，造成冲突的可能性相当高。
因此，我们必须对代码进行一些修改。幸运的是，在JavaScript中解决这类“作用域”问题十分容易，例如我这样将parse-js.js的代码包围了起来：
- var UglifyJS = {};
- (function (exports) {
- /* original code here */
- })(UglifyJS);
这样就解决了作用域问题，如今我们就能访问UglifyJS对象上的KEYWORDS集合以及parse等成员了。
性能
然后再说说性能。JavaScript一直被认为是一门执行效率低下的语言——这其实是个错误的观点。其实从语言设计上说，JavaScript比Python和Ruby都要快，只不过由于历史原因各大浏览器对它都不太重视而已。不过如今情况早就有所改变，在V8的带领下，现代的JavaScript引擎执行速度都已经超过了目前最快的Python和Ruby实现。话不多说，现在我们就来比较一下UglifyJS的解析器与Narcissus在各浏览器下的表现吧。
测试页面在此（http://files.zhaojie.me/demos/js-parsers/benchmark.html），您也可以自行尝试，测试场景是使用两者分别解析十次Narcissus的实现——大约1500行未压缩的JavaScript代码(值得一提的是，我试了许多压缩后的代码，如jquery-min.js，它们用UgilifyJS可以正常解析，而Narcissus却解析失败)。我使用两台公司配置的标准工作机，测试了IE、Chrome和Firefox各两个版本共6种浏览器。每个浏览器我都会运行多遍测试，去处偏差大的结果，取中游数值。遗憾的是，由于条件所限，两台机器的操作系统有所不同，虽然我认为并不会对结果有什么影响，但如果您足够顶真，也不妨再自行评测一把。
首先我在Win 7下测试了Chrome 10、FireFox 3和IE9，结果如下：
对于UglifyJS来说，Chrome 10的表现***，IE 9相比略慢少许，而Firefox 3耗时则是前两者的数倍。对于Narcissus来说，则是IE 9表现***，仅为Chrome 10的五分之一，和Firefox 3相比更是数量级上的领先。有趣的是，Chrome 10和Firefox 3下两个解析器的耗时都是一比十左右，而IE 9下则相差无几。
然后是Win XP下Chromium 12、Firefox 4及IE 8，结果如下：
对于UglifyJS来说，Chromium 12的表现依旧抢眼，胜过Firefox 4不少，不过使用Narcissus的情况则正好相反。同样可以看出，IE 8在JavaScript引擎的性能方面已经落后于这个时代了，不过它和IE 9、Firefox 4(以及后文的Safari)的情况类似，即UglifyJS和Narcissus的耗时并没有太大差别。
为了便于观察，我将两次测试的结果放在一起(除了非正式版本的Chromium 12)：
总体而言，Chrome 10、IE 9和Firefox 4为***军团。IE 9在UglifyJS上小负于Chrome 10，但在Narcissus上优势明显;Chrome 10在UglifyJS上表现***，但在Narcissus却落后较多;Firefox 4虽然都不是“***”，但差距也并不太大。至于IE 8和Firefox 3，在JavaScript的执行效率方面的确已经落后于这个时代了。必须承认，如今的浏览器大战的确大大提高了各方的质量。
此外我还测试了公司iMac上的Chrome 10、Firefox 3以及Safari 5，在此列出结果：
虽然浏览器的表现各有高低，差距也有所不同，但可以确定的是，UglifyJS解析器的性能的确比Narcissus要高。因此，我打算在接下来几天里用UglifyJS替换掉目前Jscex里使用的Narcissus。
总结
由于前端开发和JavaScirpt的流行，越来越多的人开始用JavaScript做一些有趣的事情。我很不喜欢如今许多所谓的前端实践，纠缠于大量的hack以及各种浏览器的表现，甚至是JavaScript里某种特定写法的性能更高——例如，居然有消息称，对于字符串连接操作来说，a += b的性能比a = a + b要高(或反之)。在我看来这些东西是最无用的，知道了又如何?随着浏览器更新换代，这些“经验”瞬间就毫无作用了。
这也是我为什么喜欢玩JavaScript，却死也不愿去做前端开发，尤其是HTML、CSS。同样，如IE 6这种浏览器在我眼中也是必须消灭的东西。
原文链接：http://blog.zhaojie.me/2011/04/uglifyjs-has-a-good-javascript-parser.html
【编辑推荐】
