Shulou(Shulou.com)06/02 Report--

This article is about how to use the JavaScript parser UglifyJS, the editor feels very practical, so share with you to learn, I hope you can get something after reading this article, say no more, follow the editor to have a look.

I've been looking for a good JavaScript parser for Jscex. I used Narcissus before and wrote about it. Unfortunately, Narcissus uses an extension of SpiderMonkey, so it is not implemented in ECMAScript 3 and cannot be used in browsers such as IE 8. At present, Jscex uses the old version of Narcissus in NarrativeJS, but I don't like the AST structure of its output. I also found some bug in advanced features, some of which are tasteless and a pity to be abandoned, and it is necessary to rewrite the new version of Narcissus. Recently I came into contact with UglifyJS and found that its parser is quite good and its performance is much higher than Narcissus. I would like to introduce it to you here.

UglifyJS is a JavaScript compressor, which is even more effective than Google Closure Compiler. For modern JavaScript compressors, it is not enough to simply remove whitespace and compress local variables, and you need to understand the semantics of the code and replace it with a smaller form of reference (there are many descriptions on the Uglify description page). This obviously requires an JavaScript parser. UglifyJS is based on NodeJS development, but can be run on various JavaScript engines / platforms that support CommonJS modular systems. If there is no CommonJS, you just need to remove the exports-related code.

The natural role of a JavaScript parser is to break down JavaScript code into AST, and then you can do a lot of interesting things based on AST. The same AST can be expressed in different ways in memory. For example, I mentioned earlier that I don't like the old version of Narcissus currently used by Jscex. One of the important reasons is that its AST structure is not friendly enough (* Narcissus is not bad). 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 its corresponding source code directly according to the getSource method-unfortunately, this feature has bug, which forces me to traverse the full AST.

UglifyJS's JavaScript word splitter and parser are stored in the parse-js.js file of the source code and ported to the parse-js project, which is a class library implemented in Common Lisp. Now you should be able to guess what the output AST looks like. Yes, it's just a "table", represented by JavaScript, is an array of arrays. I've written some simple code to format the output, and you can simply try UglifyJS's parser here. This output is simple, but it is enough for Jscex.

Use

Open the parse-js.js file and you will 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 written based on the CommonJS module mechanism, this file is actually a module, and its external methods are exposed through exports. If we introduce it into the browser as a normal JavaScript file, we will obviously report a "export undefined" exception. In theory, if you define an exports object, or even remove the code associated with exports, you can use the parse method normally. However, there is a serious problem with this, that is, the "pollution" of the root object is too serious. for example, in the browser, all the functions are defined on window, and some other class libraries are introduced, which is quite likely to cause conflicts.

Therefore, we have to make some changes to the code. Fortunately, it is easy to solve such "scope" problems in JavaScript, for example, I surround the parse-js.js code like this:

Var UglifyJS = {}; (function (exports) {/ * original code here * /}) (UglifyJS)

This solves the scope problem, and now we can access members such as the KEYWORDS collection and parse on the UglifyJS object.

Performance

And then talk about performance. JavaScript has always been regarded as a language with inefficient execution-this is actually a wrong view. In fact, in terms of language design, JavaScript is faster than Python and Ruby, but for historical reasons, major browsers don't pay much attention to it. But things have changed a long time ago, and under the leadership of V8, modern JavaScript engines have outperformed the fastest Python and Ruby implementations. Needless to say, now let's compare the performance of UglifyJS's parser and Narcissus in various browsers.

The test page is here (http://files.zhaojie.me/demos/js-parsers/benchmark.html), or you can try it yourself. The test scenario is to parse the Narcissus implementation ten times each-- about 1500 lines of uncompressed JavaScript code. (it's worth mentioning that I tried a lot of compressed code, such as jquery-min.js, which parsed normally with UgilifyJS, but Narcissus failed.) I tested six browsers in two versions of IE, Chrome and Firefox using two standard workmachines configured by the company. I will run the test many times in each browser to get rid of the results with large deviation and take the middle value. Unfortunately, due to the limited conditions, the operating systems of the two machines are different, although I don't think it will have any impact on the results, but if you are serious enough, you might as well evaluate it yourself.

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

For UglifyJS, the performance of Chrome 10 is slightly slower than that of IE 9, while Firefox 3 takes several times longer than the first two. For Narcissus, the performance of IE 9 is only 1/5 of that of Chrome 10, which is an order of magnitude ahead of Firefox 3. Interestingly, the time consuming of the two parsers under Chrome 10 and Firefox 3 is about one to ten, while that under IE 9 is about the same.

Then there are Chromium 12, Firefox 4 and IE 8 under Win XP. The results are as follows:

For UglifyJS, the performance of Chromium 12 is still eye-catching, much better than Firefox 4, but the opposite is true with Narcissus. It can also be seen that IE 8 has lagged behind this era in terms of JavaScript engine performance, but it is similar to IE 9, Firefox 4 (and later Safari), that is, the time consuming of UglifyJS and Narcissus is not much different.

For ease of observation, I put the results of the two tests together (except for the informal version of Chromium 12):

Overall, Chrome 10, IE 9 and Firefox 4 are legions. IE 9 loses less than Chrome 10 in UglifyJS, but has obvious advantages in Narcissus; Chrome 10 performs * * in UglifyJS, but lags far behind in Narcissus; although Firefox 4 is not "* *", the gap is not too big. As for IE 8 and Firefox 3, they are indeed lagging behind this era in terms of JavaScript execution efficiency. It must be admitted that today's browser wars have greatly improved the quality of all parties.

In addition, I tested Chrome 10, Firefox 3, and Safari 5 on the company's iMac and listed the results here:

Although the performance of browsers varies, what is certain is that the performance of the UglifyJS parser is higher than that of Narcissus. Therefore, I intend to replace the Narcissus currently used in Jscex with UglifyJS in the next few days.

Summary

Due to the popularity of front-end development and JavaScirpt, more and more people are starting to do interesting things with JavaScript. I don't like many of today's so-called front-end practices, obsessed with the large number of hack and the performance of various browsers, and even the higher performance of a particular way of writing in JavaScript-for example, there is a message that a + = b performs better than a = a + b for string concatenation operations (or vice versa). In my opinion, these things are the most useless, so what if I know? As browsers are updated, these "experiences" are instantly useless.

That's why I like to play JavaScript, but I don't want to do front-end development, especially HTML and CSS. Similarly, browsers such as IE 6 are something that must be eliminated in my eyes.

This is how to use the JavaScript parser UglifyJS. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.