User Experience Engineering

Tuesday, May 18, 2010

 

Debugger-Friendly JavaScript Compression

For a rapidly-evolving application, sometimes it is necessary to sacrifice a bit of compression for the sake of debugger-friendly code. If you know of a javascript debugger or FireBug plug-in that is able to decompress-and-debug on the fly, please let me know.
A Conscious Trade-off
It's common knowledge that such tools as Yahoo Compressor can achieve optimal compression, with as much or as little obfuscation as you desire. A recognized best practice dictates "debug on your development server and compress for production." However, troubleshooting a live issue with ultra-compressed JavaScript is problematic. It can be a big hurdle for a solutions management department. Super-compression may be appropriate, depending on the application. How rapidly is the application evolving? How diverse its uses? In how many environments must it excel? If your answers are "fast", "very" and "many", a trade-off may be worthwhile.
Debuggers and Compressors
Firebug, WebKit Inspector provide some traditional debugging tools; you can set breakpoints, and do the usual step-through process. There are serious limitations.
My first step toward balance was to use Yahoo Compressor's "preserve line feed" feature. Here is an invocation of the Yahoo Compressor --line-break option.
java -jar yuicompressor-x.y.z.jar -line-break 0
However, the FireBug debugger / Yahoo Compressor combination is broken as follows.
  • Separate logical statements end up on the same line.
  • Breakpoints stop at declaration time. Function declarations and the first statement or two in their closures are on the same line. Whereas the developer intends to stop on a line in the function at runtime, FireBug will stop when the script loads.
  • Convenient Watches unusable. Normally you may hover cursor over a variable name, to see its value. This feature becomes difficult to use.
  • Breakpoints on extremely long lines are unusable... ...unless you can scroll sideways, and follow the bouncing highlighter.
If you follow the module pattern, and use object literal notation, you'll find even more compression and debugger limitations.
  • JavaScript Object Literals become single-line monstrosities. One complex object declaration became a string of 8000+ characters with no line feeds! This appears to be a side-effect of Yahoo's 1-linefeed-per-semicolon approach; the statements in an object literal are comma-delimited.
Next, I'll explore some alternatives.

Comments:
Try JS Deminifier (https://github.com/benmmurphy/jsdeminifier_xpi). Turn it on and after page refresh, you can use Firebug or view source. Good luck.
 
Post a Comment

Links to this post:

Create a Link

<< Home

Archives

March 2006   May 2006   July 2006   August 2006   January 2007   March 2007   April 2007   August 2007   March 2008   April 2008   August 2008   April 2010   May 2010   July 2010   September 2010   April 2011   November 2012   March 2013   December 2013  

This page is powered by Blogger. Isn't yours?