Comparison of Java Script Modules and Dependency Managing Frameworks

Comparison of Java Script Modules and Dependency Managing Frameworks

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality. Module based coding eases the effort for maintenance and increases re-usability.

However, managing dependencies between modules is a major concern Java Script developers faced. Hence there are several module and dependency management frameworks became famous among JS developers to give the responsibility to manage dependencies properly in larger projects.

For Eg:



But first three are the most popular and most used frameworks.

Choosing the right module loader is an important decision for any high quality web application. Large applications often require a number of JavaScript files. Generally, they are loaded one by one using <script> tags. Additionally, each file can potentially be dependent on other files. You don’t want to add script tags manually into the html because is not scalable (you have to manually order, no deploy minification…).

Following is a comparison listed in webpack documentation.

Feature webpack/webpack jrburke/requirejs substack/node-browserify jspm/jspm-cli
CommonJs require yes only wrapping in define yes yes
CommonJs require.resolve yes no no no
CommonJs exports yes only wrapping in define yes yes
AMD define yes yes deamdify yes
AMD require yes yes no yes
AMD require loads on demand yes with manual configuration no yes
ES2015 import/export no no no yes
Generate a single bundle yes yes♦ yes yes
Load each file separate no yes no yes
Multiple bundles yes with manual configuration with manual configuration yes
Additional chunks are loaded on demand yes yes no System.import
Multi pages build with common bundle with manual configuration yes with manual configuration with bundle arithmetic
Concat in require require(“./fi” + “le”) yes no♦ no no
Indirect require var r = require; r(“./file”) yes no♦ no no
Expressions in require (guided) require(“./templates/” + template) yes (all files matching included) no♦ no no
Expressions in require (free) require(moduleName) with manual configuration no♦ no no
Requirable files file system web file system through plugins
Plugins yes yes yes yes
Preprocessing loaders, transforms loaders transforms plugin translate
Watch mode yes not required yes not needed in dev
Debugging support SourceUrl, SourceMaps not required SourceMaps SourceUrl, SourceMaps
Node.js built-in libs require(“path”) yes no yes yes
Other Node.js stuff process, __dir/filename, global process, __dir/filename, global process, __dir/filename, global for cjs
Replacement for browser web_modules, .web.js, package.json field, alias config option alias option package.json field, alias option package.json, alias option
Minimizing uglify uglify, closure compiler uglifyify yes
Mangle path names yes no partial yes
Runtime overhead 243B + 20B per module + 4B per dependency 14.7kB + 0B per module + (3B + X) per dependency 415B + 25B per module + (6B + 2X) per dependency 5.5kB for self-executing bundles, 38kB for full loader and polyfill, 0 plain modules, 293B CJS, 139B ES6 System.register before gzip
Dependencies 19MB / 127 packages 11MB / 118 packages 1.2MB / 1 package 26MB / 131 packages

Following articles have much detailed comparison of above frameworks.

  1. What are the best client-side JavaScript module loaders?
  2. Module loader comparison: Webpack vs Require.js vs Browserify
  3. Webpack comparison



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s