Testing minified JS Libraries in ExtendScript

Davide Barranca —  — 2 Comments

It’s not uncommon, when scripting for Adobe applications, to borrow JS libraries that have been originally written for web development. While the new generation of HTML Extensions will run on the Chromium Embedded Framework, traditional Adobe ExtendScript code is based upon the implementation of a different, older Javascript engine. Besides ECMAScript unsupported features (i.e. ES 5) I’ve noticed that using minified JS libraries is a risky business – scripts can break or fail silently. I’ve set up a proper testing environment to inspect them.

Minified libraries

Web developers need to keep their data transfer footprints as light as possible so they minify their code – i.e. use engines such as  or  to transform eloquent, commented and nicely indented code into an unreadable blob of characters – for instance as follow is a minified version of a CryptoJS library for Base64 encoding:

Being generally installed on the machine the users work on, Adobe scripts don’t benefit from a reduction in filesize (which is pretty small per se) so developers don’t bother with minifiers; and ESTK can deploy a binary version, so code readability is not an issue.

A couple of pretty neat libraries that I use – and will test in this post – are:

  1.  – monkey-patch a JavaScript context to contain all EcmaScript 5 methods that can be faithfully emulated with a legacy JavaScript engine.
  2.  – a growing collection of standard and secure cryptographic algorithms implemented in JavaScript. I wrote some time ago that appears to be quite popular.


Libraries that I will test are the actual ES5-Shim.js and the core.jsenc-Base64.js (routine for Base64 encoding, as you may guess) from CryptoJS. Below you can find a comparative view over the original files, the minified version provided by the libs authors and minified versions that I’ve compiled using UglifyJS (default params) and Closure Compiler (three versions: whitespaces only, simple and advanced – detailed info about their differences here).

As you see the compression can be remarkable! (~21.000 -> ~3.000 bytes). Let’s set up a test environment: I’ve created a Lib2Test folder in Photoshop CC/Presets/Scripts where I’ve put all the above listed files. In order to include a library in a jsx add the line:

$.evalFile is more flexible than #include in my opinion, since you can load external code when you need it (i.e. testing a condition – if this happens, then I need this lib, else I don’t or I need some other lib).


I’ve written a simple evaluation test that cycle through all the original, provided minified version and custom made compression:

As a result, I’ve found that:

Problem: for some reason – that I’m not willing to investigate – each and every compressed versions for Photoshop is indigestible. Conclusion: keep the original version!


The test for the CryptoJS libraries is slightly more complex. First let’s just evaluate the core.js

Then (including core.js because it’s a dependency) the enc-Base64.js file:

Problem: apparently there are no evaluation errors, but for the Base64 module when compressed with Closure (advanced).

Let’s do a functional test on the minified versions of core.js – true, it’s evaluated without errors, but this doesn’t mean it works as expected. The following is not the most bulletproof test in the northern hemisphere, but should work. Basically I’m converting a Latin1 encoded String to a WordArray, then the reverse (WordArray to Latin1). If the two strings match, the test is passed. (If you have doubts about how CryptoJS works, please have a look at my my tutorial to refresh your 007 skills).

The results are encouraging:

Apparently – as long as this simple test is concerned – core.js has no functional problems.

Let’s involve the enc-base64.js library: this time the test will be a roundtrip:

  • from Latin1 to Word Array;
  • from WordArray to Base64;
  • from Base64 back to WordArray;
  • from WordArray back to Latin1.

If the two Latin1 strings are identical, the test is passed. I’ve removed the version compressed with Closure Compiler (advanced) because it gives evaluation errors.

Mixed results:

Problem: the minified file provided by CryptoJS authors and a version compressed with Closure (simple) fail. If you’re curious, their converted strings is miBdJeBd.
Digression: you can’t directly output in the console the “wrong” string, you’ve to loop through it this way (mind you the string length appears to be correct, 28):


These tests – even if trivially simple – have shown that there’s a dangerous variability in the different output minified code can lead to.

  • 2/3 of the minified versions provided by Libraries authors failed a simple evaluation test.
  • Closure Compiler (advanced) has the highest failure rate.
  • UglifyJS and Closure (whitespace) have the highest success rate, though not 100%. Returning more or less the same filesize, they can be used interchangeably.
  • Beware minified version, stick to uncompressed code if you can afford some extra bytes on the disk! You’ll save yourself some useless debug time!


Mind you: this post is far from being an exhaustive review of code minification in ExtendScript- yet should suggest that an appropriate testing environment is a useful tool – so test your code!

Print Friendly, PDF & Email

2 responses to Testing minified JS Libraries in ExtendScript

  1. William Waller August 7, 2014 at 4:32 PM

    Nice article!

Trackbacks and Pingbacks:

  1. Partial Serial Number Verification System in Javascript | Photoshop, etc. - July 5, 2015

    […] JS Minifier (use “Conservative” then strip newlines – aggressive minifiers will break ExtendScript code, see this article) […]

Leave a Reply

Text formatting is available via select .

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">