On Thu, Jan 22, 2009 at 6:46 AM, Tim Wintle <[email protected]>wrote:
> I don't want to start a huge debate with this, but I have noticed that
> the (minified) javascript feature code that gets inserted into gadgets
> generated by shindig is significantly larger than the javascript that
> gets inserted by the iGoogle gadget server.
>
> The iGoogle feature code (which I am using as a baseline for size since
> I assume they have spent a long time optimising it) is often 30% smaller
> than the Shindig feature code.
>
> I'm using PHP, but I'm fairly sure it's similar for Java - unless it
> uses a much better minification algorithm that I haven't seen elsewhere
> online.
No, it's completely different for Java. igoogle's javascript (assuming
you're talking about an opensocial gadget and not a legacy gadget) is
exactly what is produced by the java build system.
We're definitely not going to go about manually making changes that a
minifier / compiler should be doing. The instructions that Chris has
provided should produce the same output as the java build.
>
>
> For example, I haven't found an algorithm that automatically converts to
> use one character local variable names. If there is such an algorithm
> available to run the javascript through, can somebody point me to it?
>
> I'm normally more or less in the the "optimise late" group of people,
> but this does seem important given the volume of gadgets that are likely
> to be served from Shindig.
>
>
>
> Possibilities:
>
> There seem to be a number of types of improvements that can be made to
> the code, some of them more obscurificating than others.
>
> At one end, there are changes such as:
>
> """
> var someVar = 1;
> var anotherVar = 0;
> """
>
> becoming
>
> """
> var someVar = 1,
> anotherVar = 0;
> """
>
> but the effect of these is minimal.
>
> Somewhere in the middle are changes to use one-character local variable
> names such as:
>
> """
> function parseUrlParams() {
> var query,
> l = document.location.href;
> queryIdx = l.indexOf("?");
> hashIdx = l.indexOf("#");
> if (hashIdx === -1) {
> query = l.substr(queryIdx + 1);
> } else {
> query = [l.substr(queryIdx + 1, hashIdx - queryIdx - 1), "&",
> l.substr(hashIdx + 1)].join("");
> }
> return query.split("&");
> }
> """
>
> becoming:
>
> """
> function parseUrlParams() {
> var q,
> l = document.location.href;
> r = l.indexOf("?");
> h = l.indexOf("#");
> if (h === -1) {
> query = l.substr(r + 1);
> } else {
> query = [l.substr(r + 1, h -r - 1), "&",
> l.substr(h + 1)].join("");
> }
> return query.split("&");
> }
> """
> (saves about 60 bytes in the above example - bytes that wouldn't have
> been saved through the PHP minification algorithm )
>
>
> And at the really tough to read end are major re-factors of the code,
> which generally don't save that much space anyway.
>
>
> Personally, I would like to suggest that features are patched in the
> first manner, and possibly in the second manner for tight loops (where
> the scope of a variable is less than, say, 6 lines - so you can always
> see where the variable was defined when you're looking through the code)
>
>
> I would also like to suggest that this is especially relevant for the
> most common features - which in our case are "core" and "flash" - but I
> assume that most Shindig users will find the opensocial core features
> just as important.
>
>
> Tim Wintle
>
>
