.

EasyPack! Pushbutton Validation and Compression

Sample Image - EasyPack.jpg

Introduction

If you are developing a fat-client AJAX application; your JavaScript files are in the order of 3000 to 10000 lines; and you have dozens of that files you will eventually long for a stricter client-side language than JavaScript.

I am one of the above, currently developing an AJAX application. And I am (or I was) fed up with the looseliness of JavaScript. So fed up that I decided to write a program that makes my scripts stricter and less error-prone. Hence EasyPack is born.

JavaScript is an object-based (some prefer to call object-oriented, but JavaScript is not object-oriented as Java or C# is) loosely-typed and prototypical language. Being loosely-typed makes it a perfect candidate for a client-side scripting language.

Or it was some time ago before the AJAX buzz has hit our grounds. With the introduction of AJAX, web applications began to rely more an more on JavaScript (which is a bad thing but is a subject of another article). Nowadays seeing a JavaScript file with 10000 or more lines of code is not a big surprise.

If you have several huge JavaScript files at hand

  • It will be hard to maintain them

    Since JavaScript is really forgiving on syntax errors; and it is not a type-safe language chances are that you will not realize some of your JavaScript errors before production phase.

  • They will consume a lot of bandwidth

    Large files means large amount of bytes to send through the pipe. Hence a less responsive web application. User agents cache script files but the first time the user sees a web application load is his first and most valuable impression. You would not want to ruin it. Or would you?

    HTTP Zip compression is an option if you want to reduce the amount of bytes transferred. But there are certain caveats: First, GZip compression algorithm introduces a server overhead; it consumes a lot of cpu cycles. And if you have a large amount of files and your web site has a high traffic load (both of those are true for most of the AJAX web sites around) your server will stagnate trying to compress your script files. And your audience will not like this at best.

How to Solve this Problem

Since GZip compression is most of the time not applicable for contemporary AJAX applications, a text-based compression algorithm seems to be an optimum solution.

But we have a larger problem here. We need to validate our JavaScript for syntax errors AND compress them afterwards.

So how can we sort this problem out? By splitting it to smaller chunks of course. We need three separete components.

  1. An algorithm to check for JavaScript syntax errors.
  2. An algorithm to compress and obsfucate JavaScript code.
  3. And an algorithm to execute those two in batches. So that I can be able to compress all JavaScript files of my web application with a single button click.

Pondering on these questions, I stumbled upon two priceless resources that saved months of development time:

Douglas Crockford has an excellent solution to the first problem:

Meet JSLint.

and Dean Edwards has another excellent solution to the second problem:

Meet the packer.

As you see, EasyPack is created stepping on the shoulders of these two giants. EasyPack uses Douglas' JSLint for syntax checking and Deans' packer for file compression.

But not only them:

  • EasyPack uses orkinos (it is currently more or less a C# wrapper around Deans' code, but I plan to enhance it further) for batch compression operations,

  • and sardalya - sarmal dynamic framework as an AJAX stub to glue JSLint and the business tier together.

The license file enclosed in the project archive gives more detailed explanations about those libraries.

Security Considerations

EasyPack is aimed for local development environments. It is not recommended for the internet medium. However if you somehow want (or need) to run it on the Internet make sure that

  • You have a reliable authentication mechanism

    If not, anyone who accesses the application will be able to compress your script files.

  • You have full control over your web server

    The compression algorithm EasyPack uses consumes considerable amount of CPU. Moreover, it has not been tested in a heavy-load environment. If something goes wrong you may need to restart the server.

How to use EasyPack

Easy! All you need is to press a single button.

Needless to say you also need dot net framework installed, an IIS server, and a DOM-compliant browser (latest versions of Opera, Mozilla, Firefox, Safari, Camino, Flock, Netscape or IE will do).

Let us start by running the example project. First of all you need to edit
/resources/metadata/BatchProcess.xml:

<file-list>
 <file>F:/WEBS/.../easypack/sandbox
/script1_src.js</file>
 <file>F:/WEBS/.../easypack/sandbox/
script2_src.js</file>
 <file>F:/WEBS/.../easypack/sandbox/
script3_src.js</file>
 <file>F:/WEBS/.../easypack/sandbox/
script4_src.js</file>
 <file>F:/WEBS/.../easypack/sandbox/
script5_src.js</file> 
</file-list>


F: is the drive that I install my web applications. Chances are that you don't use the same directory setting as I do. You will need to modify the paths in the XML file so that they map to correct locations.

After having tweaked the XML all you need to do is to click the button and watch easypack validate and compress the JavaScript files in /lib/js/easypack/sandbox.

Here is a sample screen you will see during compression

And here is the screen you will see when everthing finishes successfully

But what if there is a syntax error in the file? Then the operation will halt and you will be immediately informed about the error.

Beware that EasyPack has stricter requirements for JavaScript syntax. Which is, imho, good because it keeps your source code strictly organized. If you are involved in an AJAX project team organization has vital importance.

After fixing the error you can click one and only one button of this application to re-validate your script.

When all operation is completed if you browse to /lib/js/easypack/sandbox/ you will see compressed and uncompressed files together. Take, for example, script1.js

  • script1_src.js:

    is the uncompressed JavaScript file that you use in your development environment, add extensive comments, give meaningful variance names, and indent the  code and document it as much as you can so that your team member (hopefully) understands what that script is for at a glance.

  • script1.h

    is the header comment file (this may be a copyright notice) which will be ammended to the top of the compressed file.

  • script1.js

    is the compressed and obsfucated JavaScript file.

For the example files in the sandbox the compression ratio is negative (that is, the uncompressed files are smaller in byte count than compressed ones). However in our production AJAX application, which we excessively document, use long and meaningful variance names for readability, we achieve an average of 60 to 80 percent compression.

Just think about it. A 100K script file all of a sudden reduces to 40K.

Not that bad, huh?

Conclusion

I use EasyPack all the time for my AJAX applications. I find it to be a great time saver. I hope someone finds it useful as much as I do.

Happy coding!

History

  • 2006-07-25 : Article created

linkibol bu sayfayı sevdin mi?  hemen linkiboluna ekle!

Çeşitli

sardalya

EasyPack

Önerdiğim Tarayıcı

Önerdiğim Bağlantılar