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.
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
