Module 29 // Core JavaScript

ES Modules

Module Objective

import/export, named vs default exports, live bindings, module scope

Mental Model Realtime Simulation

INTERACTIVE_CANVAS
Editor_Pane
Loading...
Console_Output
Waiting for output...

Practical Code Examples

// Example 1
// 1. Named vs Default Exports
// helpers.js
export const config = { port: 3000 };
export function log(msg) { console.log(msg); }
export default class App {}

// main.js
import App, { config, log } from './helpers.js';
💡 Default exports are imported without curly braces. Named exports must use curly braces `{}` and match the name exactly.
// Example 2
// 2. Renaming Imports
import { longFunctionName as log } from './utils.js';

log("Hello");
💡 The `as` keyword allows you to rename an import to avoid name collisions in your current file.
// Example 3
// 3. Re-exporting (Aggregator Pattern)
// index.js
export { default as User } from './User.js';
export { default as Product } from './Product.js';
export * from './constants.js';
💡 You can create an 'entry point' file that collects exports from many files, allowing users to import everything from a single folder.

Engine & Memory Architecture

Module Loading Lifecycle

1. Static Analysis:

  • Imports are analyzed before any code runs.
  • This allows tools like Vite to "tree-shake" (remove unused code) from the final bundle, saving RAM and download time.

2. Module Registry:

  • The browser maintains a registry of loaded modules in the Heap.
  • Each module is executed exactly once, no matter how many times it's imported.

3. Singleton Behavior:

  • If you export an object, every file that imports it gets a reference to the same object in memory.

4. Performance:

  • Modules run in Strict Mode by default.
  • Deeply nested imports can increase "Main Thread Blocking" time during initial page load as the browser fetches and parses each file.