Community
Participate
Working Groups
If we could improve our Javascript compression, we could consider compressing all Javascript at runtime. To do so, we should consider integrating an existing compressor such as the YUI compressor http://yuilibrary.com/projects/yuicompressor/ or the Closure Compiler http://code.google.com/closure/compiler/. Expected benefits: * the additional step of creating pre-compiled Javascript files using a third-party tool would become obsolete * custom Javascript code would also benefit from the improved compression * standard and debug variant could not differ, which can now happen by mistake Possible problems: * the compression might slow down the initial start time, we need to evaluate that
You should be careful with approaches like the closure compiler. The last time I checked it, it did the same thing as GWT - dead code elimination. Without a client-side protocol handler, this can be problematic as either the code that is called from the LCAs isn't there anymore or has another name.
This would also enable us (in theory) to create browser- or application-specific client-code, decresing the size of javascript that needs to be transported and parsed.
(In reply to comment #1) > You should be careful with approaches like the closure compiler. The last time I > checked it, it did the same thing as GWT - dead code elimination. Without a > client-side protocol handler, this can be problematic as either the code that is > called from the LCAs isn't there anymore or has another name. If this code elimination is not optional, it would of course disqualify the Closure Compiler. Even with a protocol handler this would exclude any custom widgets. But the YUI compressor seems to do a very good job (see bug 327451)!
With the approval of CQ 4536, the subset needed from the YUI Compressor can now be checked into our CVS.
YUI Compressor is in CVS. client.js is not needed anymore as YUI Compressor compresses the javascript files at runtime in "standard" mode. In "debug" mode the javascript files are delivered uncompressed.
Does this change affect the startup time of RAP?
We do the measurement before the actual integration and the results are the following - measurement is done in DisplayLCA#writeLibraries: 1. with client.js - average time of 10 measurements is 1948 ms 2. with YIU compression - average time of 10 measurements is 2314 ms We loose ~350ms from the startup time witch is about 15%.
I did the measurements again with the current CVS HEAD - measurement is done in DisplayLCA#registerResources. The average time needed for QooxdooResourcesUtil.registerResources(); is 2250ms.
I reverted the last changes as my last measurements of the startup time show different result than before.
Is there anything we can do to make this a reality for 1.5?
We have it in our list for M7.
Compressing all JavaScript at runtime would delay the startup by roughly 2 seconds. While this is certainly acceptable at deployment time, it would further impede the development-deploy-test cycle. Therefore we agreed not to do this at the moment. I've opened bug 393496 to move the clientbuilder into the RAP repository. This will make it easier for others to re-built the client.
