Latest Stabe/Release version v1.2.5: modulr.js | modulr.min.js | Release Notes

A browser Javascript asynchronous module definition framework loosely based on the principles of AMDJS and similar in configuration and application to RequireJS for JS code dependency management.

A quick rundown of the differences of Modul R based on the AMDJS documentation:

1. Module id's are defined explicitly; defining modules anonymously are not allowed.

   Why: For simplistic Optimization. Aggregate your files, and you're done with optimization. The author also do believe explicit declaration of the module identifier is a better practice.

2. With respect to the AMDJS implementation, it does not create a define.amd property.

3. Global variables define and require are not reserved. The script uses Modulr.define and Modulr.require.

Modul R introduces the concept of packaged instances. Packaged instances are independent, but can communicate with other packages. Modules/instances don't need to be on the same aggregated/optimized files. Applications, especially large-scale implementations that requires to split application architecture in multiple files, can benefit from this.

A large-scale development implementation example, is where one development would have to maintain multiple sites which share global/shared files, site/channel files, and template specific files.

Example:

<!-- global files shared across multiple applications -->
<script src="//cdn.staticdomain.com/js/global.min.js"></script>
<!-- site #1 specific code -->
<script src="//cdn.staticdomain.com/js/site1.min.js"></script>
<!-- template specific code -->
<script src="//cdn.staticdomain.com/js/pages/articles.min.js"></script>

Why do you have to separate files? Can you just aggregate them all like how r.js does it for RequireJS? One of the very important reasons why, is CDN delivery. As with all very high traffic sites, caching is critical. In separating files, it can ensure that updates to code can propagate consistently in the CDN network. Multiple files mitigate the risk of site-wide issues in an unlikely event of bad code deployments.

Base assumption of Modul R is that you have a CDN domain. Advantages of CDNs are well documented, and one thing to point out here and not really elaborate, is cookie-less requests reducing bandwidth costs. Websites with CDN typically sets up their static assets in a different dedicated domain. Modul R gives you an option to configure your bootstraps with a base domain host where all your javascript paths will be coming from.

/** example bootstrap from a site //www.hmabesa.com **/
var GlobalPackage = Modulr.config({
	// package instance name
	instance: "globalScripts",		
	// your cdn domain, different from your website domain
	baseDomain: "//cdn.hbm.com",
		
	. . .
});

Not a fan, it's a matter of preference. And just like how the author was put off with the r.js optimization process, developing modular js should not require a developer to always run some extra overhead process just to build these optimized files every time updates are made while in development phases of an application.

The very particular use-case that the author have found to be a limitation of what he wanted to do in RequireJS, which is the main reason why Modul R was created, is creating multiple applications in different optimized/aggregated files, and the interaction between applications.

Also, RequireJS has too much configuration, and a lot of case-specific setup that isn't really needed for the website the author is currently architecting.

The needs:

• A simple AMD loader

• Applications as packages that can communicate with other packages without being dependent

• Be able to have multiple applications/packages spanning on different files

• Be CDN friendly

This flavor of AMD may not be your cup of tea, but the author feels that open-sourcing this script is the right thing to do.

Modul R is currently being rolled out incrementally, replacing legacy applications at the author's current work. With a QA resource team, a team of javascript developer colleagues, and being used on very high traffic websites -- the author hopes to achieve further optimizations to the code through rigorous testing and application.

Please, any suggestions or recommendations are most welcome: [email protected]