Introducing Yabble!

A few months ago I started working with Node.js, and by extension, CommonJS. Since then I've become fascinated with the goals of CommonJS and wanted to get involved. CommonJS is mostly suited for the server-side environment, but it does not exclude browsers. There are even a number of frameworks/libraries out there using it in the browser space such as SproutCore, Narwhal, and RequireJS. However, these don't really fullfill the need for a simple, barebones CommonJS module loader for the browser. SproutCore and Narwhal are great, and come with a ton of goodies, but oftentimes all of those goodies are not needed. RequireJS fits more closely with my goals, but still doesn't quite fill the niche that I'm after. Enter Yabble.

Yabble is a general purpose browser-side CommonJS module loader. The goals are to be small, flexible and useful. There are numerous places where, when two paths exist, both were made available instead of choosing one.

XHR vs script tags

Many argue that using script tags for dynamic Javascript injection is preferable over XHR. I tend to agree. Script tags are usually easier to debug and support fetching cross-domain. However, in the CommonJS world, that means that the modules need to be wrapped in some boilerplate code (named a Transport). Since no server-side CommonJS module loader requires this wrapping, it is a pretty big disconnect between modules meant for the server-side and those meant for the browser. Ideally, a single module could be supported on both. With XHR and eval(), it is possible to retrieve the raw module code and "wrap" it on-the-fly. It is also harder to debug and doesn't often support cross-domain requests. So, Yabble supports both. The XHR and eval() method is the default one and I envision its use mostly for quick-and-dirty development efforts. The script tag method can always be used if the developer prefers and when the application is deployed to production.

Hand-wrapped vs auto-wrapped modules

It is possible for modules to be automatically wrapped in a Transport through a build process or some other means. However, some argue that hand-wrapping is the best way to go. I tend to disagree, but, there is nothing stopping anyone from hand-wrapping modules with the use of Yabble. For automatically wrapping, a build-time tool is included to analyze modules and wrap them. Another method is to use a server-side script to wrap and serve modules on demand.

Individual file loading vs packaged file loading

This isn't really a debate. In general, individual file loading is used during development and for deployment a single, packaged file is created to reduce the number of requests. Yabble supports multiple modules being defined in a single file without any additional instructions. In addition, file packaging support for the tooling is on the roadmap.


It is my sincere hope that many find this project useful in creating well-structured web applications. The more people jumping on the CommonJS bandwagon, the better.

For more information and to get the code, visit the project page.
To see it running live, visit the unit tests.