a little madness

The development of Pulse 2.2 has seen a steady increase in the amount of JavaScript we are using to drive our web front end. To help maintain a snappy user experience, we have started to look at products / packages to reduce the size of our JavaScript. The first such package that I encountered was ShrinkSafe, a part of the Dojo Toolkit.

ShrinkSafe is packaged as a jar file, and with the js.jar (Rhino) on the classpath, can be run as follows:

To run this via ant, you could do something like:

<java jar="shrinksafe.jar" fork="true" output="outfile.js">
    <arg value="infile.js"/>
    <classpath>
        <pathelement location="js.jar"/>
    </classpath>
</java>

Whilst effective, this does become a little verbose when you need to apply it to multiple JavaScript files and does not support a dynamic set of files. Since the Pulse build uses ant and has a growing set of JavaScript files, I created an ant task to drive ShrinkSafe, the source of which is available via github.

So now we can run shrinksafe as follows:

<taskdef name="shrinksafe" classname="com.zutubi.ant.shrinksafe.ShrinksafeTask"/>
<shrinksafe outputDir="${out.dir}" sourceDir="${src.dir}">
    <include name="**/*.js"/>
</shrinksafe>

We can also append a suffix to the processed files for when we version them.

Anyone who does web development, particularly involving a significant amount of JavaScript, knows what a boon Firebug has been. The ability to debug your code in Firefox is a huge time saver. Unfortunately, those doing web development also know that they need to support Internet Explorer. Not only does IE have a host of quirks, it also has almost no support for debugging JavaScript.

For a long time I have been relying on Microsoft Script Debugger to debug IE-specific JavaScript problems. By installing this debugger and configuring IE to allow external script debugging (by unchecking Tools > Internet Options > Advanced > Disable Script Debugging (Other)), you could trap errors in an external debugger window. The biggest gain from this was the ability to determine the exact line where the error occurred – something that could be impossible to decipher from the built-in error dialog in IE. The script debugger also provides a call stack and a rudimentary command window allowing some inspection of the program state. However, the interface is clunky at best, making navigation through the code and inspection difficult.

Now, though, I have finally stumbled upon a Better Way. For some time Microsoft have made limited “Express” versions of Visual Studio tools available for free (with registration). One such free tool is Visual Web Developer Express. Like the other Visual Studio tools, Web Developer includes a decent debugger – in this case one that understands JavaScript. The only trick is getting the Express version of Web Developer to debug an external IE process for you. Thankfully, someone has figured out how to do just that and blogged about it. Essentially, you create a dummy project in Web Developer and configure it to point at your external web application. Now when you “Debug” the project Web Developer will launch IE and any errors will be trapped by the debugger. Happy debugging!

Note for FireFox users: If, like me, FireFox is your default browser, you may also need to set IE as your default browser in Web Developer. You can do this by opening an HTML file, then going to “File > Browse With …” and setting IE to the default.