At least here in the US, we must still be concerned about dial-up users, with at most a 5KB/sec download rate. As of this writing, the entire XBLinJS library is around 180KB, requiring half a minute to download all at once, more if broken up into files. This is clearly unacceptable, but it is fortunately also handlable. A mimimal deployment of XBLinJS, using none of the provided widgets and skipping the ability to use <widget> tags, can be squeezed down to just under 5KB. This number will vary as the system develops, but it is not a typo.
There are two concerns in minimizing the time-to-download for a user. One, you want to ship as few files down the wire as possible, as each file incurs some degree of connection overhead, which can be quite large. (There are some optimizations which help, but you can not control whether the user has configured their browser to use them and it is best to assume they have not.) Second, you want to ship as few bytes down the wire as possible.
This document will help you address these issues.
The order the files should be concatenated in is the following:
- flavors.js - Note you can remove unused flavors from this file for a small gain. If you change BrowserFlavor or DOM2Flavor to derive directly from JObject instead of Flavor, you can cut the Flavor class out too. (If this does not work, file it as a bug and it should be trivial to fix.)
- widgetsBasic.js - Unused widgets may be stripped out of this file, as well. Note that LabelWidget gets used a lot by other XBLinJS-provided widgets, and others from this file may be as well.
- Any other XBLinJS widget file you care to use; there should be no other dependencies.
- Your own code; only you can know the correct order for that.
The widgets.css file is easier to deal with; of course, either ship it as a separate CSS file, or integrate it into your own. It should generally be obvious and well-labelled which classes go with what, if you want to trim it.
These techniques are overrated, though not quite useless. They suffer from three problems:
- Third, and most importantly, they are compressing the wrong thing.
I am considering in the future implementing a sort of "#ifdef" feature in simpleCrunch, and allowing you to compile in or out various "capabilities" of XBLinJS; for instance, if you never use <widget> tags, why should you ship that code? This may make it very easy to create minimal functional installations of XBLinJS, but will make it harder to test.
The terms of the LGPL, which XBLinJS is licensed under, require that unobfuscated code be made available to the user upon request. You can automatically fulfill the terms of this license by dropping a small comment on the top of the final file giving URLs of the source files, available on your server. (Pointing them to the Sourceforge site would be sufficient only if you have made no changes to the core library.) Users must also recieve that code under the LGPL as well.
Remember this only applies to widgets shipped with XBLinJS; widgets you create for your own use are not covered by this restriction.
As a final note, if your lawyers are really uncomfortable about the licensing of XBLinJS for some reason, as I am still the only copyright holder, you may negotiate with me to obtain your own license, of any kind you'd like, subject to negotiation and the obvious fact that I can not give out exclusive rights that contradict the LGPL. If you absolutely insist on giving me money, I won't stop you.