As modern web applications become increasingly client heavy, it’s important to properly organize your client side code. In small applications, organization may not seem necessary, however, as your application grows and more people are involved with the project, proper organization becomes key to keeping the application maintainable. This is where Modules come in.

WHAT IS A MODULE?

Modules are an integral piece of any robust application architecture and typically help in keeping the units of code for a project both cleanly separated and organized. Modules should be:

Specialized – Each module should have a very specific function
Independent – Modules should know as a little as possible about other modules
Decomposable – It should be fairly simple to test and use modules in isolation from other modules
Substitutable – It should be possible to completely substitute one module with another, as long as it supplies the same interface

WHY USE MODULES?

Encapsulation – Implementation details are kept private and expose a public API
Team-Ready – Team members can build modules in parallel with minimal conflicts
Extensibility – Dynamically extend existing modules
Scalability – Modules work independently of other modules and therefore can be removed and added as necessary
Avoiding Conflicts – Modules reduce the likelihood of variable names conflicting in the global scope.

TYPES OF MODULES

Object Literal – A set of comma-separated name/value pairs enclosed in curly braces
Module Design Pattern – Used to further emulate the concept of classes in such a way there we’re able to include both public/private methods and variables inside a single object, thus shielding particular parts from the global scope.
AMD (Asynchronous Module Definition) – Wraps a module inside a function called “define()”. Any required dependencies as asynchronously loaded.
CommonJS – Assign keys to the variable “exports” to declare the modules public API. Any required dependencies are synchronously loaded with a “require()” function.