Q: Backbone.js application using CommonJS structure to work with node.js and client I am looking into a way to write by BackboneJS application using a CommonJS structure which allows Javascript modules to be required. This application could then work on the client or server side with node.
I have looked into requirejs and other similar options but you have to write the app in a specific way which in my opinion looks really naff.
I have also looked at browserify and webmake which takes your code and any modules that are required and  combines them into a single js file with the missing (require) methods. All a clever idea, but leaves the code on the client side a bit messy.
Is there such a thing out there which can take by code written in its commonJS format, compile all the required modules that are compatible with the browser and spit out a Javascript file (or several) that can be used in the browser without having to worry about missing require methods? Even better would be a solution tailored to backbone applications.

A: You have a number of options for using CommonJS structured modules in the browser:


*

*RequireJS 2.0.2 supports the configuration option cjsTranslate.  Setting this to cjsTranslate: true in your r.js optimizer configuration will wrap any included modules that appear to be in the CommonJS format with the define boilerplate.  See details here.

*Cajon is new a module loader built on top of RequireJS that supports modules in the CommonJS format (also written by the RequireJS author @jrburke).

*The Volo dependency management tool (again by @jrburke) has the ability to include and translate cjs modules into amd modules.  This is probably not a great option for you but worth including for completeness.

*You could write a server component that automatically wraps your code in the AMD define boilerplate.  I believe this is the approach they're taking at SoundCloud - see this blog post.


Edit Aug 29, 2014: The current best practice here is arguably Browserify with generated source maps for easier client-side debugging.

A: It is not clear to me why something like webmake does not solve your problem.


*

*It does not require you to write client modules in any different fashion than what you'd do for a server side module. 

*You raise the concern that webmake/browerify munge up the js. Well, guess what. RequireJS/Curl do the same thing. Yes, I know, not necessarily, but in any actual production situation circa 2012, you'd have some sort of a tool to combine your js and minify it before sending it over the wire.

*The first three points in the current accepted answer by @rharper are basically listing out alternatives in the AMD loader space. AMD as a concept is definitely very different from Common JS, and addresses a very valid concern that escaped the attention of the CJS spec writers. But it is a valid concern for the future, since currently script sizes are dwarfed by that of images etc. By the time script sizes become a noticeable performance concern, we'd probably have with us ECMA Harmony modules, which should have  native browser support. (And even today, nothing is stopping you from manually splitting up your modules into logical groups and demand loading each combined group as and when required. It's just not needed that often). 

*webmake is an (sort of) implementation of the fourth alternative that @rharper listed. I advocate webmake over browserify because webmake states in its mandate that it is just supposed to do one thing - after you've written a bunch of modules with their dependencies stated via the require("foo") and exports.bar = ... mechanism, you run a command specifying your initial javascript file, and it spits out a js file containing all transitively discovered dependencies. And it does that thing well, in my limited experience using it. With minimal overhead - just 75 odd lines of non minified code is added as a preamble.

*If having a extra build step is causing friction while development, you can alternatively dynamically regenerate the combined js and serve it via a node.js server  (couple of lines of code). webmake also supports sourcemaps so debugging in webkit browser also works.

*Keep in mind that I am suggesting webmake because after a lot of hunting around, it was the simplest solution that I came across. But that doesn't mean it works for you. The reason why there are so many alternatives in this space is because each one has its own set of bells and whistles, some of which might be essential for your use case. But the general principles will hold in the case of most good javascript loaders:


*

*Regardless of if you use AMD or CJS, you should not need to write the AMD boilerplate. @rharper lists a couple of AMD alternatives that have support for automatically doing that.

*You should have two different paths for production and development. Production javascript should be minified/combined as of today. Development javascript shouldn't, and one shouldn't need to add a extra step to the save(in editor)/reload(page)/debug(in browser) cycle. 
