Uglifyjs has a fantastic JavaScript parser.

I've been looking for a good JavaScript parser for Jscex, before I used Narcissus, and I wrote related articles. Unfortunately, Narcissus uses SpiderMonkey extensions, so it is not implemented with ECMAScript 3 and cannot be used in browsers such as IE 8. At present, Jscex is using the Narrativejs in the old version of the Narcissus, but I do not like its output of the AST structure, use also found in the advanced features of some bugs, some food tasteless discard feeling, and rewrite the new Narcissus must be a battle. Recently I contacted the UGLIFYJS, found that its parser is quite good, performance is much higher than Narcissus, here to introduce to you.

Uglifyjs is a JavaScript compressor, and the effect is more than Google Closure compiler. for modern JavaScript compressors, it is not enough to simply remove whitespace and compress local variables, but also to understand the semantics of the code and replace it with a reference to a smaller form (there are many descriptions on the Uglify page). This obviously requires a JavaScript parser. UGLIFYJS is based on Nodejs development, but can be run on a variety of JavaScript engines/platforms that support COMMONJS module systems. If there is no commonjs, you can simply remove the exports-related code.

the JavaScript parser's role is to decompose JavaScript code into an AST, and then do a lot of interesting things according to the AST. the same AST can have different representations in memory, such as the previous mention that I do not like the old version of Narcissus that Jscex is currently using, an important reason is that its AST structure is not friendly (the latest Narcissus is good). In addition, although it provides some advanced features, such as marking the location of each element in the source code, so that the user can get the source of the code directly based on the GetSource method--Unfortunately, the test feature has bugs, which forces me to traverse the full AST.

The UGLIFYJS JavaScript word breaker and parser are stored in the source code parse-js.js file, transplanted to the PARSE-JS project, which is a class library implemented with Common Lisp. Now you should be able to guess what its output AST is. Yes, it's a "table", which is represented by JavaScript, which is the array of arrays. I wrote some simple code to format the output, so you can simply try the UGLIFYJS parser here. This output is simple, but it is already fully enough for Jscex.

Use

Open the Parse-js.js file, and you'll see some code like this:

 
 

  
  

  
/*-----[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 is based on the COMMONJS module mechanism, this file is actually a module, its external methods through the exports exposed. If we introduce it as an ordinary JavaScript file into the browser, it is clear that the "export undefined" exception is reported. Theoretically, if you define a exports object, you can use the parse method normally even if you remove the code associated with exports. But there is also a serious problem, that is, the root object of the "pollution" is too serious, for example, in the browser all functions, definitions appear on the window, and then introduce some other class libraries, resulting in a very high likelihood of conflict.

Therefore, we must make some modifications to the code. Fortunately, it's easy to solve such "scope" problems in JavaScript, such as I've surrounded the parse-js.js code:

 
  
  

  
   
   
var uglifyjs = {};
  
   
   

  
   
   
(function (Exports) {
  
   
   

  
   
   
/* Original code here * *
  
   
   

  
   
   
}) (UGLIFYJS);
 
  
  

This solves the scope problem, and now we can access the Keywords collection on the Uglifyjs object and members of the parse.

Performance

And then again, performance. JavaScript has long been considered an inefficient language-a false point of view. In fact, JavaScript is faster than Python and Ruby in terms of language design, but because of historical reasons, the big browsers don't pay much attention to it. But now things have changed, and with V8 's lead, modern JavaScript engines perform faster than the current Python and Ruby implementations. Don't say much, now we will compare the UGLIFYJS parser and Narcissus in each browser performance bar.

The test page is here (http://files.zhaojie.me/demos/js-parsers/benchmark.html) and you can try it yourself, and the test scenario is to use both to parse 10 Narcissus implementations-- About 1500 lines of uncompressed JavaScript code (it is worth mentioning, I tried a lot of compressed code, such as Jquery-min.js, they use UGILIFYJS can parse normally, but Narcissus parse failed). I used two company-configured standard machines and tested two versions of IE, Chrome, and Firefox for a total of 6 browsers. Every browser I will run many times the test, where the result of large deviation, take the middle value. Unfortunately, due to the conditions, the operating system of the two machines is different, although I do not think it will have any effect on the results, but if you are good enough, you may wish to evaluate one.

First I tested the chrome 10, FireFox 3 and IE9 under Win 7, and the results were as follows:

For UGLIFYJS, Chrome 10 has the best performance, IE 9 is a little slower, and Firefox 3 takes several times more than the previous two. For Narcissus, it is IE 9 best performance, only for Chrome 10 one-fifth, and Firefox 3 compared to the order of magnitude of the lead. Interestingly, Chrome 10 and Firefox 3 have two parsers that take about 1:10, compared with IE 9.

Then the win XP under Chromium 12, Firefox 4 and IE 8, the results are as follows:

For UGLIFYJS, Chromium 12 performance is still eye-catching, more than Firefox 4, but the use of Narcissus is just the opposite. As you can see, ie 8 has lagged behind this age in terms of the performance of JavaScript engines, but it is similar to IE 9, Firefox 4 (and later Safari), where the UGLIFYJS and Narcissus are not very different.

For ease of observation, I put the results of two Tests together (except for the unofficial version of chromium 12):

Overall, Chrome 10, IE 9 and Firefox 4 are the first legion. IE 9 is UGLIFYJS on Chrome 10, but has obvious advantages in Narcissus. Chrome 10 is the best in uglifyjs, but it lags behind in Narcissus; Firefox 4 is not "best", but the gap is not too big. As for IE 8 and Firefox 3, it is true that JavaScript is lagging behind in its execution efficiency. It must be admitted that today's browser wars have indeed greatly improved the quality of the parties.

In addition, I tested Chrome 10, Firefox 3, and Safari 5 on the company's imac, listing the results:

Although the browser performance is high and low, the gap is also different, but it can be determined that the performance of the UGLIFYJS parser is indeed higher than the Narcissus. Therefore, I intend to replace the Narcissus in the current Jscex with UGLIFYJS in the next few days.

Summarize

As front-end development and javascirpt are popular, more and more people are starting to do interesting things with JavaScript. I don't like the many so-called front-end practices today, entangled in a lot of hack and the performance of a variety of browsers, and even a particular way of writing in JavaScript--for example, there is a message that, for string concatenation operations, the performance of A + B is higher (or vice versa) than A = a + B. In my opinion, these things are the most useless, know how? As browsers upgrade, these "experience" moments are useless.

This is why I like to play JavaScript, but die also do not want to do front-end development, especially HTML, CSS. Likewise, such browsers as IE 6 are something that must be eliminated in my eyes.

Original link: http://blog.zhaojie.me/2011/04/uglifyjs-has-a-good-javascript-parser.html

"Edit Recommendation"

1. Understanding of call and apply in JavaScript
2. 16 Most popular JavaScript frameworks
3. 8 Web sites for stunning JavaScript effects
4. JavaScript Learning notes have questions and answers
5. JavaScript code optimization new tool UGLIFYJS

"Responsible editor: Chen Yu new TEL: (010) 68476606"