First, the why
My first goal was to get gDial Pro to compile using the Closure compiler and its standard optimization level. This can be simple, just compiling each js file individually, which doesn't really give too much gain since a lot of the optimizations need to see all of the js code in one file in order to really do its magic.
So it should have been simple right, just pass in each js file on one line to the Closure compiler and let it work its magic which it did. The resulting code would not run though as it simply concatenates all the files together in the order passed in and compiles. In the gDial Code there are some js files that need to load in specific order after other files. So when they concatenate willy nilly, you get broken code as some objects/functions were not defined before where they were being used.
Also, after this happens, all of the code for the app is now in a single output file and so that same sources.json file need replaced with a file referencing the single .js file that we have output from the Closure compiler.
And then it works!!!!
You can't use the object oriented inheritance from the Prototype library. (i.e. Class.create). The reason is due to the way that you make calls to super class functions in their system. They require that the function receive a special parameter named '$super'. Closure changes the name of all parameters to short 1 letter names for space reasons and so this '$super' variable will have its name changed which breaks the inheritance.
You can get around this by using the excellent Dojo Library and its class inheritance system which doesn't require the use of special variable names and works fine with the Closure compiler.
Also, I only apply the Closure compilation when building my production releases of the software as the name/file mangling would be a nightmare for use in debugging. So I debug my code and then I have a build script which runs the compiler on the code and builds my packages for distribution.
Also, for the same reasons, using the Closure Library is a no go as well. It has a package system that dynamically loads the js files it needs, but due to the way the webOS apps are loaded, the package system doesn't seem to work.
Tough question. Now that I am done with implementing it, the hard work is done and I will likely continue to use it as I plan to migrate to the Closure Library and Advanced Optimizations as techniques are discovered to make them work with webOS.
As to whether there is any performance increase in the resulting code, I am not sure as I just put it out there to the Homebrew community and I am awaiting feedback from all of the users on their experiences with the app. It was pretty optimized before and I was already minifying code with the YUI Compressor.
Only time will tell whether it was worthwhile.