After building all the modules to be loaded, the built files can be optimized as well (minified and concatenated), even though this is a completely optional step, but doing so could be a lot beneficial for your site's performance.
The RequireJS module loader is extremely well documented. So no matter whether you're a pro at JS based web development or just a newbie, you will find the documentation very helpful whenever you're stuck or just starting out. Everything is well-defined and logically placed in proper sections in a manner such that it is very easy to understand.
One of the best advantages of RequireJS over Browserify is that you don't need a nodejs environment to get started. Just "require" your dependencies and it takes care of loading them. By contrast, Browserify requires a running NodeJS implementation so you can build your one monolithic file, then you can push the file to your static web server.
It's the one of the few modules in this category that can handle IOC-style dependency injection. The others work well for apps that have knowable dependency lists at compile time, but this is the only one that can load new modules without being recompiled.
RequireJS is awesome for bundling and managing dependencies in an async manner. But the server-side needs neither of this killer features. Because of this it's not as good if you're building a library that should work on both client and server (i.e. PouchDB).
Loading is dealt with via handlers that are themselves modules (dynamically loaded and cached). Qoopido.demand comes with support for its own module format built-in and offers handlers for css, json and text. Due to handlersbeing modules themselves it is really easy to write custom handlers.
It's the one of the few modules in this category that can handle IOC-style dependency injection. The others work well for apps that have knowable dependency lists at compile time, but this is one of the few that can load new modules without being recompiled.
Cookie support within Qoopido.demand can be enabled globally or per module. Whenever the localStorage cache for a module changes an accompanying cookie gets updated/deleted so the server can handle the clients module caching state and, e.g., inline modules as long as the client das not have them in localStorage.
Webpack supports AMD and CommonJS module styles. It performs clever static analysis on the AST of your code. It even has an evaluation engine to evaluate simple expressions. This allows you to support most existing libraries.
Plugins and loaders are easy to write and allow you to control each step of the build, from loading and compiling CoffeeScript, LESS and JADE files to smart post processing and asset manifest building.
The more moving parts a thing has the more that can break. Most webpack configs are poorly implemented ad-hoc compliers. It's horrible if you "just want it to work" rather than spend tons of time debugging and playing mad scientist.
To require a file, just use the require() function.
var foo = require('./foo.js');
These files may have dependencies of their own. Browserify will build a dependency graph and bundle it into a single file that you just have to put in a script tag.
Browserify includes transforms such as deAMDify, that allow you to use modules written in the AMD module format, and debowerify, that allows you to use modules intended to be managed by Bower package manager.
Browserify does nothing client-side. It's only a server-side builder. If you want to load files from other domains, look at RequireJS. If you want to break your code up into multiple modules, look at RequireJS or Webpack.
Writing plugins is relatively easy and straight forward as each file, you can run a function that gives a file name and path, based on that you can decide if you want to do something like parse, transform, modify etc the file or skip it.
While it's not too hard to create npm package for an existing library, it means maintaining it when the library updates. While most libraries are now on npm, many client side specific libraries are not.
It's possible to require local files instead, at the expense of not having npm managed version control.