There are lots of script loaders out there in the wild; require.js, ControlJS, $scriptJs to name a few. So why do people still create them and why would we care if someone created another one? Well, there are a few problems with script loaders.

• They load scripts asynchronously, which means your larger scripts will load slower then small scripts and there is no guarantee if a piece of code will be ready and loaded. If you are dealing with lots of files, ie 20 (like most large sites) this is simply a nightmare.
• Script Order. As mentioned before, the asynchronous way the scripts are loaded cannot guarantee load order. There are plugins that helps with this, but only to some extent.
• Lots of HTTP requests. When you inspect the network traffic on your page loads, you will see as many HTTP requests as you have js files. Like I mentioned before, for most large sites this will end up being close to 30 or 40 requests!
• You have to jump through hoops to get minification and most have no Coffeescript support.

So what makes BoxJs different? And why would I even need script loaders in the first place?

To answer the latter question, with libraries such as Coffeescript and Class extensions, developers are now ending up with lots of .js files. Rather than working on one .js file with 100s of methods, we want to follow a more structured and Object-Oriented approach. The problem is lots of files = lots of HTTP request = making site painfully slow. No amount of minification is going to solve this issue. Your files could be 2 bytes, but it will still need a HTTP GET request to fetch. To make matters worse, if you host your .js files in the same web application (which is about 99% of the cases) then the synchronous nature of how web servers work (other than Node.js) means all the files will wait in a queue and get processed one by one. That means your site is waiting even if you are loading in the files with an asynchronous client library such as require.js.

BoxJs, a script loader with a difference!

• BoxJS has a client and a server side to it. The client gathers all the information it needs and sends 1 request to the server. The server will fetch all the JS files from your site, package them and minify the whole lot. So even if you have 50 JS files, it will end up with 1 request and 1 minified file.
• Scripts are combined in the order you give them. Period. The synchronous way we fetch the files means guaranteed load order.
• Isn’t it slow to fetch the scripts asynchronously and minify them on the fly? If you would need to do this every time a request is made, then absolutely. It is considerably slower, but that’s where the caching comes in. BoxJS will only ever fetch these files once. All subsequent requests will return the final boxed version which is lightning fast. But what if I make lots of changes to my JS files and don’t want to use the cached version? Simply ad a version=1.0 or version=1.1 in the BoxJs call and it will produce a new version. It will also cache the older versions till the next refresh, would is usually a few days.
• Minification out of the box! BoxJS supports CoffeeScript too. It will automatically compile any .coffee files into .js files before it passes it to the packager to be minified and cached too!

This sounds cool, but how can I rely on the CDN?
BoxJS uses Amazon and Heroku which are very reliable. It scales depending on the amount of traffic. For some, this may still not be enough. They suggest grabbing the output of the BoxJs HTTP request and save that locally as one file for your production server. This would get rid of any worries.

There is no way this will stay free!
If usage of BoxJS becomes more popular, it will be difficult to stay free. But its almost certain that there will be a free version for sites with lower traffic. For now we will have to wait and see!