Since SystemJS does not try to shim node built-ins and methods from modules, you cannot load any npm module in the browser and expect it to work with SystemJS.
Using StelaJS opens you up to npm, that has over 80k modules of which a great amount work both client-side and server-side. And the list is growing rapidly.
Sometimes changing the order of the require statements in a JavaScript file loaded with stealjs may cause unexpected problems or even breaking the code altogether.
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.
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.
With other loaders, aka browserify, it isn't possible to run your site without first bundling. Require.js can load everything async which is pretty powerful.
Since the RequireJS is quite popular among the dev community, that automatically means that problems get sorted out very quickly and most of the core code has already been tested.
Because of its easy to understand documentation, the RequireJS module loader is super simple to use; module definitions are as easy as defining just a key/value pair.
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.
The global ‘require’ and ‘define’ methods make namespace collisions likely if building a 3rd party plugin. AMD loaders line require are best if you control the site.
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.
Cached modules can be optionally & automatically compressed with lz-string loading a plugin (included in the distribution) either globally or on a per module or even per path/part of path base.
Version 1.1.2 of Qoopido.demand adds the possibility to not only set global caching parameters valid for all modules but allows for fine grained cache control on a per module basis.
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.
Qoopido.demand offers loading of legacy scripts as if they were modules through probe functions. These probe functions are similiar to Require.js shim, but where shim allows only string parameters, Qoopido.demand's probes are JavaScript functions that can check whatever you want.
It enables and encourages the development of atomic modules that do not necessarily have to get bundled (manually or via build-process) to gain performance
From version 1.1.1 onwards Qoopido.demand is able to load multiple concatenated modules in a single request (like jsdelivr) while maintaining automatic module resolution.
Async loading on demand including loadings from cdns. For example it is easy to load jquery from cdn as a module. The same thing is not that easy to achieve in Webpack
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.
Using Webpack opens you up to npm, that has over 80k modules of which a great amount work both client-side and server-side. And the list is growing rapidly.
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.
Webpack allows you to require your CSS and images at the top of your JS files. This makes your dependencies clear and reduces HTTP requests by inlining.
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.
Using browserify opens you up to npm, that has over 80k modules of which a great amount work both client-side and server-side. And the list is growing rapidly.
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.
<html>
<body>
<script src="bundle.js"></script>
</body>
</html>
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.
With Browserify-loader2, It's possible to load modules dynamically via ajax(file protocol is not supported). But it is impossible to do something like this:
var mod = require('path/'+name+'.js');