Tim, what was the A/B comparison you did to determine JS size difference between Shindig's and iGoogle's JS? Ie. which URLs? Just for a sanity check.. --John
On Thu, Jan 22, 2009 at 10:27 AM, Kevin Brown <[email protected]> wrote: > 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 > > > > >
