I find libraries such as Require.js to be too complicated to trust them.<p>I put all my client-side JS files into ./src directory and watch them with Node.js server. When any file in ./src is added or modified then server automatically copies it to ./build directory and wraps it with additional code required by module loader.<p>This way I can use (almost) the same syntax for handling modules on both client- and server-side, e.g. I can write client-side script which looks like this:<p><pre><code> var button = require('widgets/button.js').button;
var toggleButton = Object.extend(button, {
label: 'Toggle me',
});
exports.toggleButton = toggleButton;
</code></pre>
And it will automatically get compiled into:<p><pre><code> 'use strict'; module('widgets/toggleButton.js', function(exports) {
var button = require('widgets/button.js').button;
var toggleButton = Object.extend(button, {
label: 'Toggle me',
});
exports.toggleButton = toggleButton;
});
</code></pre>
The client-side framework for handling such modules takes 28 lines of code: <a href="https://gist.github.com/1287050" rel="nofollow">https://gist.github.com/1287050</a><p>Unless you are writing really large apps, this approach seems to be much cleaner, just remember to combine and minify all modules before deployment.
What I didn't like about Require.js is having to wrap so many portions of my code into callback functions and not being able to merge and minify code on the fly.<p>We ended up using Browserify instead. It's a Node.js module that lets you use CommonJS-style require in your client-side code. Browserify scans your code for all requires, figures out in which order the dependencies should be loaded and merges the code. Optionally, it lets you compile CoffeeScript on the fly or use filters, such as UglifyJS (to minify the output). Another great advantage, IMO, is that Browserify can package most Node.js modules for client-side use. Instead of downloading & distributing JS libs, you can manage them as modules via NPM and require them as you would in Node.js apps. Browserify will grab the code from the module and package it for you.<p>However, if you can't use Node.js on your server, Require.js is definitely the way to go.
I most definitely agree with this. Though our company has approached it a little differently than you, the combination of Require.js and Backbone.js (with Zepto.js too) has allowed us to make totally flexible HTML5 apps that are easy to test and maintain and once optimised (using r.js that comes with Require.js), we have something very nippy too.<p>I think it's a great combination! And after finishing three commercial projects with it we have yet to run into any brick walls... Unlike with many other JS MVC frameworks, which in my opinion, try to do too much for you.
That approach may fit the need of a modularity but it doesn't solve the remaining issues. To me, the most important issue is to make both backend and frontend dependencies same.<p>I haven't documented yet but there is something I'm working on for a while, OneJS. It generates a single, stand-alone JavaScript file, not requiring coder to make any change on a CommonJS code. The built file it generates can be run at any platform that doesn't support CommonJS, such as web browsers. It means that we can use the great dependency mechanism NPM provides in our frontend apps.<p>For those who wonders, OneJS; <a href="https://github.com/azer/onejs" rel="nofollow">https://github.com/azer/onejs</a><p>Example project; <a href="https://github.com/azer/onejs/tree/master/test/example-project" rel="nofollow">https://github.com/azer/onejs/tree/master/test/example-proje...</a><p>Output of the above example project; <a href="https://gist.github.com/1286969" rel="nofollow">https://gist.github.com/1286969</a><p>A relatively larger example; <a href="https://github.com/azer/multiplayerchess.com/tree/master/frontend/lib" rel="nofollow">https://github.com/azer/multiplayerchess.com/tree/master/fro...</a>