{{announcement.body}}
{{announcement.title}}

JavaScript Module System

DZone 's Guide to

JavaScript Module System

In this article, we discuss how to better modularize our code in larger JavaScript applications in order to write cleaner code.

· Web Dev Zone ·
Free Resource

Separate and Abstract code in its own scope, making it accessible and included again!

That’s the thing that JavaScript module systems help us to achieve. JavaScript applications tend to grow fast and without any kind of structure in place. It is often very difficult to keep a clean code-base in larger JavaScript applications. Traditionally, different techniques, like IIFE, Revealing Module Pattern, etc. are used to achieve modularity in the beginning, but as application complexity grows, more sophisticated systems are required, and various module systems are available for us to use. 

This post will provide an introduction for these module systems, and in future posts, we will be building on top of this knowledge. In this post, I will describe what JavaScript modules are, why we need those, and what the benefits of using those module systems ar.

If you are a C# developer or a Java developer, we normally break down our code in different classes/files and then import those classes/files to another class (e.g. via a using statement in C#), and with that, the functionality is available in other classes to be used.

This way, we can structure and organize our code in a cleaner manner. This also promotes reusability, separation of concerns, etc.

JavaScript module system allows us to do the same thing for JavaScript. The module system allows us to separate code in different blocks (modules) and make it available in other parts of the application.
In JavaScript, there are different formats and ways to accomplish this challenge to separate and abstract code in its own scope, making it accessible and included again.

Module System Depending on Environment

JavaScript can be executed in many places, to start with, in the browser (for web UI ) and Node (for back-end services).

  • Depending on the environment you are in (in a browser, or in a Node application) modules can and have to be written in many different systems, so that it can be used in many different environments.
  • Each module system describes a different format in a way that code separation can be created (CommonJs, AMD, ESM).

Module Formats vs Loaders

  • Module format is really just the syntax used to define the module. Module Format -> Syntax.
  • However, the syntax is useless without something that understands how to execute it. That’s the role Module Loader plays. They are usually JavaScript Libraries that you can include in your project.
  • Using a particular module-format will also require a compatible module-loader. Not all module loaders support all module formats.

AMD vs ComonJS vs ESM

AMD and CommonJS are the popular module formats, and the following details describe their general characteristics, However, the one which we are interested in is ECMAScript modules, and we will use it in conjunction with TypeScript. For AMD and CommonJS, you can search online for details; I just mentioned those here because you will most likely read about those in various other blog posts or articles.

AMD vs CommonJS

Here is a code example of writing a basic module in typescript and then consuming this module in another module.

Creating and consuming module in TypeScript

So, this was the introduction to the JavaScript module system. As I mentioned before, our focus in the upcoming posts will mostly involve typescript, so I will suggest that you visit http://www.typescriptlang.org/ to understand more about it. 

Also, the TypeScript website will show you how to set up your development environment and some basic examples as well. In the next post, we will be starting our journey from this point onward. Happy Coding.

Topics:
clean code ,javascript ,javascript modules ,module ,typescript ,web dev

Published at DZone with permission of Jawad Hasan Shani . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}