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.

You want to ship as few files as possible. To that end, you should probably deploy your final XBLinJS widget code as a single Javascript file, such that the server and browser can cache it correctly. (In other words, make sure they can use E-Tags or something; if it is a static file on the filesystem all major servers should handle this for you. You may have to do something explicitly if you are using a template system or something, but your administrator will have to tell you what to do for that as it varies from system to system.)

The order the files should be concatenated in is the following:

• jobject.js
• 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.)
• widgets.js
• 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.

That will create one Javascript file that can be sent to the user once and cached for the remainder of the session.

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.

The traditional answer to this has been Javascript compressors/obfuscators, which try to shrink variable names and make other changes to the Javascript file to make it smaller.

These techniques are overrated, though not quite useless. They suffer from three problems:

1. All of the ones I've found are available only as web pages with embedded Javascript. If you know of a command-line obfuscator (free as in beer), let me know.
2. None of the compressor programs truly understand Javascript, they are mostly some regexes and logic. widgets.js is too much for the ones I've used to handle, because of the way I've used a function to create new classes; the obfuscators never get a change to realize that "JavascriptConsole" specifies a class, not a string.
3. Third, and most importantly, they are compressing the wrong thing.

The value of a Javascript compressor should not be measured by comparing the original size of the file to the compressed size of the files. The output of the compressor should be compared to the original file, stripped of all comments and gzip'ed. (To be fair, you should probably gzip the compressor output as well.)

Why is this? Any browser that you might use XBLinJS with will support gzip compression per web request. Almost any server you might think of using XBLinJS with, especially if you are doing something with AJAX techniques, will support gzip compression per web request. While a Javascript compressor might eke a few more bytes out, it will not be worth the additional effort.

Therefore, I recommend stripping all comments out of the Javascript files, and turning on gzip compression on your server. If you have not already had it turned on, you will find that your webserver immediately feels more responsize (even across LAN connections) and your bandwidth costs will go down. Apache 2 has the ability to apply it to everything intelligently, even the output of mod_perl or PHP. Failing this, you should be able to use your web server to at least compress your Javascript file specifically.

In the extras/ directory, there is as Perl script called simpleCrunch.pl that will strip all the comments out of a Javascript file, assuming you don't do crazy things like put // in a string, and remove all extraneous whitespace (wmich doesn't gain you much but you might as well take it). By and large, this is Good Enough that you don't need to go further. (I just did a test, and changing 98 instances of Widget to W dropped the compressed file size from 4723 to 4709, a gain of 14 bytes. In fact, because going further rapidly requires changing the actual interface of the code (class names, variable names, function names, etc.), it becomes an actively bad idea.

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.

Due to the fact the LGPL is intended for conventional programs created in C, and contains numerous references to "object code" and other such meaningless terms when discussing Javascript code, I modified the license to make the previous paragraph more obviously true (see LICENSE in the distribution). One can still argue about what it may or may not mean to concatenate your widget code into one file with XBLinJS code. As the current sole author, I can tell you this would not bother me, as one file and one <script> tag or two files with two <script> tags are completely logically equivalent, the difference is merely technical. However, it may make you or your lawyers more comfortable to create two files, one with your code and one with XBLinJS, used as a library/framework.

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.