FSM Full Stack Masterclass
Platform under construction
JavaScript course badge

Modules & Code Organization

Advanced

Default & Namespace Imports

Default imports and namespace imports are two different ways to consume module exports.

import createApp from "./create-app.js";
import * as format from "./format.js";

format.title("Dashboard");

Modules & Code Organization

Default imports name one main export; namespace imports collect many exports.

A default export represents the main value of a module. The importing file chooses the local name.

A namespace import collects all named exports into one object-like namespace.

Both patterns are useful, but overusing them can make code less explicit than named imports.

default export

One primary exported value.

default import

The importing file chooses the local name.

namespace import

Collects named exports under one namespace.

Explicitness

Named imports usually reveal exactly what a file uses.

Examples

Good module code makes dependencies visible instead of magical.

Use namespace imports for cohesive utility groups

import * as format from "./format.js";

heading.textContent = format.title(record.title);

Hiding every dependency behind a namespace

import * as utils from "./utils.js";

utils.doThing();
utils.otherThing();
utils.unknownThing();

Code patterns

Reusable examples for quick reference.

These examples focus on imports, exports, module boundaries, on-demand loading and file structure you can use in real projects.

Default export

Common for one main function or class.

export default function createApp(root) {
  return { root };
}

Default import

No curly braces.

import createApp from "./create-app.js";

Namespace import

Access exports through a namespace.

import * as format from "./format.js";

format.title("Dashboard");

Named import alternative

Often clearer for small sets.

import { title, count } from "./format.js";

Rules that matter

Organize by responsibility.

A module system only helps when files have clear jobs, small public APIs and predictable import paths.

Use default for one main value

The module should clearly have a primary export.

Use named exports for multiple helpers

They keep dependencies explicit.

Use namespace imports for cohesive groups

format.title reads better than a vague utils bag.

Avoid giant utility namespaces

They hide what code really depends on.

Name default imports consistently

Different local names can confuse a team.

Do not mix styles without reason

A module should have an export style that matches its purpose.

Production thinking

A project that is easy to navigate is easier to debug, test and grow.

Why does this matter?

Choosing import style affects how quickly another developer understands a file.

Accessibility

A cohesive namespace can group reusable focus, label or status helpers clearly.

Production note

Production codebases benefit from predictable export conventions.

SEO note

Readable organization reduces the chance of client-rendering failures.

Live code lab

Change the HTML, CSS or JavaScript and run the result.

The preview runs inside an isolated iframe. The JavaScript is placed inside the HTML editor for now, so every example stays together and remains easy to understand.

Mini assignment

Try this now.

  • Add one named import example.
  • Explain which import style is clearest.
  • Rename a namespace to something more specific.

Practice assignment

Do this before moving to the next topic.

  1. Write one default import.
  2. Write one namespace import.
  3. Explain when each one fits.

Try it yourself

Compare import styles

Live preview

Self-check

Before you continue, prove that you understand Default & Namespace Imports.

Advanced

If you can explain what a file exports, what it imports and why it exists, the module structure is doing its job.

  1. Can you explain default export?
  2. Can you explain default import?
  3. Can you explain namespace import?
  4. Can you explain when named imports are clearer?
  5. Can you explain why vague utility namespaces are weak?