[Mapbender-dev] Packer (code conventions)

[Paul Spencer]

There are essentially three load costs associated with javascript:

* the size of the javascript file itself (transfer time)
* the number of javascript files (number of http connections required  
to get all the javascript)
* size/complexity of the javascript to execute

The goal here, I think, is to improve load time for the application,  
so you need to put all your javascript into a single file and  
minimize the size of the file.  The execution time will not change  
for these things unfortunately, only spending quality time with a  
code profiler (thank you FireBug) can help actual execution time/ 
processor load.

I have achieved about 8 x smaller file size using white space and  
comment removal (essentially what jsmin does) combined with gz  
compression.  Coupled with putting all the js into one file, this is  
a substantial improvement in load time for clients.

As a side note to this discussion, I'm not keen on the packer concept  
because it requires unpacking on the client side, which causes  
additional load on the browser.  The jsmin and equivalents produce  
code that executes as is in the browser without additional load on  
the browser.  See this article for a discussion on the topic http:// 
clientside.cnet.com/best-practices/optimization/dean-edwards-packer- 
compression-tool/.  Note that you can run packer to just strip white  
space and comments, but then it is the same as jsmin and most other  
minification tools.

Finally, it is much more convenient to maintain javascript in  
multiple files.  Obfuscation as part of combining and compressing is,  
in my opinion, acceptable because you can make the original,  
commented, source available as well.  Any obfuscation that happens as  
part of creating a runtime executable is no different from compiling  
C source ... if it results in faster load times then clients will be  
happy.  I guess my point here is that you are not compressing to  
obfuscate, you are compressing to optimize, but don't discard options  
just because they obfuscate.  Any decent compression or minification  
is going to produce more-or-less unreadable code anyway so don't make  
that part of your assessment criteria.

What is nice is being able, at run time, to choose between loading  
the compiled, optimized version of the code (for production code) and  
the uncompiled, uncompressed version of the code (for development,  
debugging).  Whatever you choose to do, I highly recommend that you  
be able to switch easily from one to the other.


On 6-Feb-07, at 6:07 AM, Marc Jansen wrote:

> Hello list, Hi Christoph,
>
>
> Christoph Baudson (WhereGroup) schrieb:
>> Another thing that we should keep in mind is, that a lot of  
>> different js-scripts are loaded into map.php on startup, and  
>> conflicts could arise if each script would be compressed  
>> individually (as Dean Edwards' packer shortens variable names as  
>> well).
>>
>
> Yes the names are shortened, but that should not be a problem since  
> everything  done by Dean Edwards packer is being reverted as the  
> script is loaded. The whole resultung function (p, a, c, k, e, d) 
> {...} is being evaluated at once. Different scripts are sent  
> through eval in the order of presence of script-tags in the markup.  
> I used is together with about 6 other scripts and there were no  
> problems.
>
>> I did a little research, and found this list of JS obfuscators and  
>> packers (there are quite a lot)
>>
>> http://www.javascriptsearch.com/guides/Advanced/articles/ 
>> 061221JSObfuscators.html
>>
>
> I think we should keep in mind that our target is not obfuscation.  
> Lots of the tools listed on this page have annoying descriptions:
>
> "...is a utility for all JavaScript programmers who are fed up with  
> the fact, that their source code can be stolen and simply modified."
> "...will encode javascript to make it more difficult for people to  
> read and/or steal..."
>
> Sure enough other packers should be considered. Can't we make up a  
> small test page in the wiki with results for some of the tools and  
> pros and cons for each?
>
>> Especially this one
>>
>> http://www.saltstorm.net/depo/esc/varsubst.wbm
>>
>> seems to be interesting, as it is free software and can handle the  
>> compression of multiple (dependent) js files.
>>
>
> As mentioned above, I don't think there are new dependencies  
> related to packing... at least with Dean Edwards tool
>
>> So I guess we should consider other packers as well. If anyone has  
>> experience with any of these or other tools, please share your  
>> knowledge.
>>
>> Christoph
>> _______________________________________________
>> Mapbender_dev mailing list
>> Mapbender_dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
>>
>
>
> -- Marc
>
> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapbender_dev

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+