I recently discovered box2djs by Ando Yasushi, a nice little physics simulation engine made to run in javascript, here's an example from the homepage:
However, it being a port of a port, there are one or two little problems. The main one by far is the delivery of the library - in the flash version, modules are loaded lazily (i.e. as needed), however in javascript all the different libraries need loading up-front.... all 64 of them... in a set order... and each file has the full MIT license information at the top!
So the browser has to make 64 different server calls and pull down 349 Kb just to start doing anything. This can clearly be improved on.
Turning on server-side gzip, is a good way to reduce the amount of data transmitted with no real downsides. Also putting everything in one file will help a lot, but more can still be done.
To shrink the javascript filesize even more there are two paths: compressors or encoders. Compressors (like yahoo's YUI compressor) remove whitespace, rename internal variables to have shorter name and do a hundred and one different optimizations, but crucially, the end javascript is programmatically identical to the input file (a browser doesn't care if a variable is called "theGreenBallsRadius" or "aPb"). Encoders (like Dean Edwards' Packer) go one stage further - they encode the resulting file (much like gzipping) and then tag on some javascript so the browser can decode it at the other end, but this creates some javascript overhead before things can get up and running.
Now because everything is better in table form:
| Name | Files | Size (Kb) | w/ GZip (Kb) |
|---|---|---|---|
| Original | 64 | 349 | 100 |
| Concatenated | 1 | 349 | 54 |
| YUI | 1 | 139 | 28.2 |
| Packer | 1 | 80.7 | 28.3 |
This shows near 85% improvement just by putting everything in one file and turning on gzip! But even better, the filesize can be halved on top of this.
My first instinct was to go with the Packer encoded version: it's the smallest (or close enough) whether the user's browser supports gzip or not. But the YUI compressed version is my recommendation. Why? Well I'm glad you asked! The vast majority of visitors' browsers will accept gzipped files, so for them there's no filesize difference between YUI and Packer. Now with YUI you can just un-gzip and you're away, however with Packer you unzip then decode then you're good to go. This additional step will still halt rendering until it's complete, making the page load feel slower - the exact thing we were trying to improve.
There you go, a good library made better! Now onto hacking it.....