How to import a module in JavaScript

Modules in JavaScript are the backbone of organizing code into reusable, maintainable chunks. Unlike traditional scripts that run in the global scope, modules have their own scope, meaning variables and functions declared inside a module are not accessible outside unless explicitly exported.

The core of module syntax revolves around two primary keywords: export and import. Using export, you specify what parts of your module are exposed to other modules. With import, you bring those exported parts into the current module.

Ponder this simple example where a function is exported:

export function greet(name) {
  return Hello, ${name}!; }

Here, greet is explicitly exported and can be imported elsewhere. Inside the importing module, you would write:

import { greet } from './greetings.js';

console.log(greet('Alice'));

Notice the curly braces around greet in the import statement. This syntax is used for named exports, where you export multiple bindings by name. If the module exported multiple functions or constants, you could selectively import only those you need.

Besides named exports, there’s the idea of a default export, which is a single value or function a module opts to export as its main entity. For instance:

export default function multiply(a, b) {
  return a * b;
}

Importing a default export looks slightly different:

import multiply from './math.js';

console.log(multiply(2, 3));

Here, no curly braces are needed because you’re importing the default export directly. You can even rename it as you import:

import mul from './math.js';

console.log(mul(4, 5));

Modules are always executed in strict mode, which helps avoid common pitfalls like accidentally creating global variables. Every module file is treated as its own scope, which eliminates conflicts and makes dependencies explicit.

One important thing to keep in mind is the static structure of ES modules. The import and export statements must be at the top level. You cannot conditionally import or export inside functions or blocks. This static structure enables tools and browsers to analyze dependencies before execution, improving optimization and loading.

If you want to export multiple bindings from a module, you can do so in one of two ways. Either you add export keywords before each binding:

export const pi = 3.14159;
export function circleArea(radius) {
  return pi * radius * radius;
}

Or you declare them first and then export them together:

const e = 2.71828;
function naturalLog(x) {
  // Implementation here
}
export { e, naturalLog };

This flexibility allows you to organize code cleanly and control what is exposed to consumers of your module.

When importing, if you want all exported members as a single object, you can use the * as syntax. It’s especially useful when a module exports many things and you want to avoid listing them:

import * as math from './math.js';

console.log(math.pi);
console.log(math.circleArea(10));

In this example, math becomes a namespace object containing all exported members.

Dynamic imports, introduced more recently, allow you to load modules asynchronously at runtime. This can be crucial for performance, letting you delay loading code until it’s actually needed. The syntax uses the import() function, which returns a promise:

async function loadModule() {
  const module = await import('./heavy-module.js');
  module.doHeavyWork();
}

This contrasts with static imports, which are resolved at compile time. Dynamic imports enable code splitting and lazy loading in modern applications.

Another subtlety is that modules are always evaluated once. Multiple imports of the same module return the same module instance, meaning shared state is preserved. This can be leveraged for singletons or shared caches without explicit global variables.

Lastly, when working with modules, keep in mind the environment you’re targeting. Node.js originally supported CommonJS by default and requires experimental flags or specific configurations for ES modules. Browsers, on the other hand, support ES modules natively with the tag, but older browsers might need transpilation.

The module system also influences how relative and absolute paths are resolved. For example, importing './utils.js' is relative to the importing file’s location, while bare specifiers like 'lodash' require a bundler or Node’s module resolution to locate dependencies. This separation enforces better control over dependencies and makes the module graph explicit.

Understanding these syntactic rules and behavioral nuances is essential before diving into advanced concepts like tree shaking, scope hoisting, or module federation, which rely on this solid foundation of how modules are declared, imported, and executed by JavaScript engines. Without mastering the syntax, all the tooling and patterns lose their footing.

Exploring the boundaries of module syntax also reveals what is forbidden, such as importing or exporting conditionally or dynamically changing exports at runtime. These limitations ensure static analysis can be performed, enabling faster and more reliable bundling and loading strategies.

For example, this is invalid:

if (someCondition) {
  import { foo } from './foo.js'; // SyntaxError
}

You must structure your code so imports are always at the top level, which may require different design decisions but pays off by making module dependencies clear and predictable.

At its core, the ES module syntax brings JavaScript closer to classical module systems seen in other languages but with flexibility suited for the dynamic web environment. Mastery of this syntax lets you compose applications from small, focused pieces that are easier to reason about and maintain.

The next challenge is understanding the various module types available and when to use each, especially given the coexistence of CommonJS, AMD, UMD, and ES modules in the ecosystem. Each has its own semantics and tooling implications, which can complicate integration but also provide options for compatibility and performance.

Before that, it’s worth drilling down further into how imports resolve and how the module graph is constructed, but the fundamental syntax remains the same:

import { greet } from './greetings.js';

console.log(greet('Alice'));

and variations thereof, including default exports and namespace imports. This minimal vocabulary is surprisingly powerful once you grasp its constraints and applications.

Let’s now look at the different module types and their typical use cases to understand how they fit into the JavaScript ecosystem and what trade-offs they bring to the table. This context will help you choose the right module format for your project’s needs and avoid the common pitfalls that happen when mixing module systems.

Understanding these distinctions is key, especially when dealing with legacy codebases, third-party libraries, or tooling that targets different environments. For instance, Node.js has historically used CommonJS, which uses require() and module.exports, while browsers have moved toward ES modules. Bridging these can be tricky and often requires shims or transpilers.

Before jumping into specifics, think these fundamental differences: ES modules are statically analyzable, support asynchronous loading natively, and enforce strict mode by default. CommonJS modules are loaded synchronously and allow dynamic require calls, which gives more flexibility but less optimization potential.

Here’s a quick illustration of CommonJS syntax:

import { greet } from './greetings.js';

console.log(greet('Alice'));

Compare that to ES modules, where imports are declarative and exports are explicit bindings:

import { greet } from './greetings.js';

console.log(greet('Alice'));

This difference shapes the way code is written and organized. While CommonJS can conditionally require modules anywhere in the code, ES modules require upfront declarations, which can be a hurdle but also a boon for tooling.

In the browser context, AMD (Asynchronous Module Definition) was one of the first attempts at modular JavaScript, enabling asynchronous loading with the define() function:

import { greet } from './greetings.js';

console.log(greet('Alice'));

Though ES modules have largely replaced AMD, understanding it helps when working with legacy projects or certain libraries that still use this pattern.

UMD (Universal Module Definition) tries to be a hybrid, working in CommonJS, AMD, or as a global variable, ensuring maximum compatibility:

import { greet } from './greetings.js';

console.log(greet('Alice'));

Choosing between these requires understanding your target environment, build tools, and performance requirements. ES modules have become the modern standard due to their declarative syntax and native support in browsers, but interoperability remains a practical concern.

When authoring new code, favor ES modules for their clarity and tooling benefits. If you must consume or produce code in other formats, look into transpilers like Babel or bundlers like Webpack and Rollup that can bridge these worlds while allowing you to write in ES module syntax.

This overview sets the stage for deeper dives into how these module types behave at runtime, how they impact load order, circular dependencies, and how tooling optimizes them. The syntax is the entry point, but the ecosystem’s complexity lies beneath the surface, waiting to be explored with practical examples and real-world scenarios where you’ll see these principles in action.

By holding onto these basics and understanding the module types, you’ll be better equipped to navigate the JavaScript ecosystem’s modular landscape without getting lost in configuration headaches or compatibility issues. And that’s where the real craftsmanship begins—knowing how to wield modules effectively, not just write them syntactically correct.

As you experiment more with modules, pay attention to how imports and exports behave when circular dependencies occur. Because of the static nature of ES modules, the module graph is constructed upfront, and the code is executed in dependency order, which affects what is accessible during initialization. This can lead to unexpected undefined values if you’re not careful.

For example:

import { greet } from './greetings.js';

console.log(greet('Alice'));

When running this, a.js logs undefined for bValue because of the timing of execution. That is a classic scenario to understand to avoid subtle bugs.

Getting these nuances right requires both understanding the syntax and the runtime behavior of JavaScript modules. The syntax lays the foundation, but the semantics are where the real mastery happens. This interplay is what makes modules powerful and sometimes tricky.

We’ve covered the essential syntax and hinted at the various module types. Next, diving deeper into their specific uses and trade-offs will reveal practical patterns that help you write modular JavaScript that scales gracefully and interoperates smoothly across environments.

For now, keep experimenting with import, export, default and named exports, namespace imports, and dynamic imports. Write small modules, import them in different ways, and observe how the module system handles them. This hands-on approach is the fastest path to true understanding.

Remember, the module syntax is deceptively simple but unlocking its full potential requires seeing beyond the surface and appreciating the static analysis, execution order, and environmental constraints that shape how JavaScript modules behave in practice.

Only then will you be able to leverage modules not just as a syntax feature, but as a fundamental architectural tool in your JavaScript projects, whether front-end, back-end, or anywhere JavaScript runs.

Now, turning to the exploration of module types and their use cases, it’s important to start by mapping the landscape of existing standards and their historical context so you can understand why ES modules emerged as the preferred choice and where the others still fit in. Each brings unique characteristics that influence your project’s design decisions and interoperability strategies.

CommonJS remains dominant in Node.js environments due to its synchronous loading and simple semantics, but it lacks the static analyzability that ES modules offer. This affects tooling capabilities like tree shaking and bundling efficiency.

AMD, designed for asynchronous loading in browsers, paved the way for modular front-end development before ES modules were standardized. While less common now, some legacy and niche projects still rely on it.

UMD tries to provide the best of all worlds by being compatible with both CommonJS and AMD, as well as exposing globals for script tag inclusion. It’s often used in libraries that want to maximize reach but adds complexity and boilerplate.

ES modules, standardized in ECMAScript 2015 (ES6), bring a uniform syntax and behavior across environments. They support static import/export, asynchronous loading in browsers, and enable advanced optimizations by bundlers.

Understanding these trade-offs helps when choosing dependencies or deciding on a module format for your own libraries. For example, if your library targets both Node.js and browsers, and you want to leverage tree shaking, authoring in ES modules and transpiling or bundling appropriately is the modern approach.

Conversely, if your codebase or dependencies rely heavily on dynamic requires or older module formats, you may need to adopt CommonJS or use compatibility layers, affecting your build process and runtime behavior.

In summary, module types differ primarily in loading mechanisms, syntax, and compatibility. ES modules offer the most modern, flexible, and optimized system but require understanding of their static nature and environmental support. The others fill niches or legacy use cases but come with trade-offs.

Next, practical code examples comparing these module types in real-world scenarios will solidify your grasp of when and how to use each effectively. This hands-on knowledge is critical to avoid pitfalls when mixing module systems or migrating codebases.

For instance, here’s how you might convert a CommonJS module to an ES module:

import { greet } from './greetings.js';

console.log(greet('Alice'));

import { greet } from './greetings.js';

console.log(greet('Alice'));

Notice the switch from require to import and from module.exports to export default. Also, here we use the ES module build of lodash (lodash-es) to keep everything consistent.

Mixing module types can introduce subtle bugs, especially around circular dependencies and default export interop, so being deliberate about module formats saves headaches down the line.

In complex projects, build tools like Webpack, Rollup, or Parcel handle these conversions and optimizations, but a clear understanding of the underlying module systems remains invaluable for debugging and architecture.

As you explore further, keep in mind that the module system is not just syntax – it’s a contract between your code, tooling, and runtime environments. Mastering it opens doors to writing maintainable, performant, and interoperable JavaScript.

The journey continues by examining module resolution algorithms, loading behaviors, and how these impact runtime characteristics such as memory usage, startup time, and code splitting, but that’s a story for the next chapter.

Meanwhile, keep experimenting with the syntax and semantics covered here. Write, break, fix, and repeat. That’s how you internalize this fundamental aspect of modern JavaScript development.

And remember, the module system is only one piece of the puzzle. Integrating it well with package management, build pipelines, and deployment strategies makes your code truly production-ready.

So keep it practical, keep it modular, and keep pushing the boundaries of what JavaScript can do with modules at its core. Because once you get this right, everything else becomes cleaner and more elegant, starting with how you organize and share your code.

There’s more to uncover, but for now, focus on the syntax and semantics as your foundation for all that follows. Modules are not just a feature; they are a mindset for writing better JavaScript.

And with that, the next step is to understand how different module types fit into the ecosystem and when to use each—

Exploring module types and their use cases

and how they interact with one another. Each module type offers distinct advantages and drawbacks that can influence your development process. CommonJS is widely used in server-side applications with Node.js, allowing for synchronous loading, which simplifies dependency management in environments where modules are loaded in a linear fashion.

For example, a CommonJS module might look like this:

const greet = require('./greetings.js');

console.log(greet('Alice'));

This simple syntax allows for simpler imports, but it lacks the static structure of ES modules, making it harder for tools to analyze dependencies at build time.

On the other hand, AMD was designed for the browser environment, facilitating asynchronous loading. Here’s a typical example:

define(['./greetings'], function(greet) {
  console.log(greet('Alice'));
});

AMD’s asynchronous loading model helps avoid blocking the rendering of the page, which is critical for performance in web applications. However, it can introduce complexity in managing dependencies and callbacks.

UMD attempts to bridge the gap between CommonJS and AMD, providing a flexible approach that can adapt to different environments. A UMD module might look something like this:

(function (root, factory) {
  if (typeof define === 'function' && define.amd) {
    define(['./greetings'], factory);
  } else if (typeof exports === 'object') {
    module.exports = factory(require('./greetings'));
  } else {
    root.myModule = factory(root.greetings);
  }
}(this, function (greet) {
  return function(name) {
    console.log(greet(name));
  };
}));

This complexity allows for maximum compatibility but can lead to larger bundle sizes and more boilerplate code, which may not be ideal for all projects.

As ES modules became standardized, they introduced a cleaner and more powerful syntax that enhances both performance and maintainability. A typical ES module structure looks like this:

import { greet } from './greetings.js';

console.log(greet('Alice'));

This declarative syntax allows static analysis and optimizations like tree shaking, which removes unused code from the final bundle, reducing load times and improving performance.

When deciding which module type to use, ponder your project’s requirements, the environment in which it will run, and the tooling available. For new projects, ES modules are often the preferred choice due to their modern features and broad support.

However, if you’re working with existing codebases or libraries that use CommonJS or AMD, you may need to adapt your approach. Tools like Babel can help transpile ES modules to CommonJS, ensuring compatibility with older systems.

It’s also important to note that mixing module types can lead to challenges, particularly around circular dependencies and how default exports are handled. For instance, if a CommonJS module imports an ES module, it may not behave as expected due to differences in how exports are resolved.

In practice, you might encounter a situation like this:

// CommonJS module
const greet = require('./greetings');

console.log(greet('Alice'));

If the greet function is exported as a default in the ES module, you may need to ensure proper compatibility by using a default import statement in your CommonJS context, which can lead to confusion and bugs if not handled carefully.

As you delve deeper into the nuances of module types, remember that understanding their loading mechanisms and implications for performance is essential. This knowledge will empower you to make informed decisions about how to structure your applications and libraries.

In conclusion, the interplay between module types, their respective strengths and weaknesses, and the context in which they’re used forms the bedrock of modern JavaScript development. By mastering these concepts, you’ll be well-equipped to navigate the complexities of the ecosystem and leverage the full power of modular programming.

As you continue to explore the landscape of JavaScript modules, focus on writing clean, maintainable code that adheres to the principles of modularity. This will not only enhance your projects but also foster a deeper understanding of the language as a whole.