Módulos ESM: organizar JavaScript por responsabilidades

Aprende a dividir código en archivos reutilizables con export/import, evitando dependencias ocultas y mejorando mantenibilidad, pruebas y escalabilidad.

Cuando todo vive en un solo archivo, el proyecto crece rápido en complejidad y baja la confianza para tocar código.

ESM (ECMAScript Modules) permite separar responsabilidades en piezas pequeñas y explícitas con export/import.

Esto mejora lectura, pruebas, reutilización y reduce acoplamiento accidental entre partes de la aplicación.

Objetivo de esta lección: estructurar módulos claros y decidir cuándo usar exportaciones nombradas o por defecto.

  • Un módulo no es solo un archivo: es un contrato claro con el resto del sistema.
  • Piensa cada módulo como una caja con API pública definida. Lo que exportas es lo único que otras piezas deberían conocer.
  • Cuando separas lógica por dominio (formatos, validaciones, API, UI), el mantenimiento deja de depender de memoria personal.
  • Define qué sale del módulo y qué entra desde otros módulos.
  • Las exportaciones nombradas son ideales cuando un archivo ofrece varias utilidades (`export function ...`, `export const ...`).

Mentalidad modular: una responsabilidad por archivo

Un módulo no es solo un archivo: es un contrato claro con el resto del sistema.

Piensa cada módulo como una caja con API pública definida. Lo que exportas es lo único que otras piezas deberían conocer.

Cuando separas lógica por dominio (formatos, validaciones, API, UI), el mantenimiento deja de depender de memoria personal.

Export e import: el flujo base

Define qué sale del módulo y qué entra desde otros módulos.

Las exportaciones nombradas son ideales cuando un archivo ofrece varias utilidades (`export function ...`, `export const ...`).

La importación debe ser explícita para que el lector entienda dependencias sin recorrer todo el proyecto.

  • Nombra módulos por intención (`precio`, `auth`, `fechas`) y no por vaguedad (`helpers2`).
  • Evita exportar todo por defecto sin criterio.
  • Mantén rutas limpias y coherentes para facilitar refactors.
  • Revisa dependencias circulares al modularizar código antiguo.

Named export vs default export

Ambos son válidos, pero cada uno tiene un contexto más claro.

Usa named exports cuando un módulo ofrece varias piezas o cuando quieres autocompletado/renombrado más explícito.

Usa default export cuando el módulo representa una única entidad principal (por ejemplo, una clase o función central).

Diferencias prácticas: navegador y Node

ESM es el estándar, pero el contexto de ejecución importa.

En navegador, para usar módulos debes cargar scripts con `type=module`. En Node, depende de extensión/configuración (`.mjs` o `type: module`).

Comprender este detalle evita errores típicos como rutas incorrectas o mensajes de import no soportado.

  • En frontend, incluye extensión en rutas relativas (`./modulo.js`).
  • No mezcles CommonJS y ESM sin estrategia explícita.
  • Separa entrypoint (`main.js`) de módulos internos.
  • Comprueba mensajes de consola sobre path/resolución de módulos.

Checklist de modularización sostenible

Si aplicas estas reglas, tu base de código será más fácil de evolucionar.

Una buena modularización no persigue archivos mínimos, sino límites claros entre responsabilidades.

Antes de crear más módulos, valida si cada uno aporta cohesión y evita acoplamiento innecesario.

  • Cada módulo tiene propósito único y nombre semántico.
  • Las exportaciones son mínimas y explícitas.
  • No hay dependencia circular entre módulos principales.
  • Puedes probar/utilizar un módulo sin cargar toda la app.
JavaScript
23

Módulos ESM: organizar JavaScript por responsabilidades

Aprende a dividir código en archivos reutilizables con export/import, evitando dependencias ocultas y mejorando mantenibilidad, pruebas y escalabilidad.

Código del tema: export · import · default export · named export

📘 Teoría

Mentalidad modular: una responsabilidad por archivo

Un módulo no es solo un archivo: es un contrato claro con el resto del sistema.

Piensa cada módulo como una caja con API pública definida. Lo que exportas es lo único que otras piezas deberían conocer.

Cuando separas lógica por dominio (formatos, validaciones, API, UI), el mantenimiento deja de depender de memoria personal.

1

Contrato

2

Encapsulación

3

Reutilización

4

Escalabilidad

Export e import: el flujo base

Define qué sale del módulo y qué entra desde otros módulos.

Las exportaciones nombradas son ideales cuando un archivo ofrece varias utilidades (`export function ...`, `export const ...`).

La importación debe ser explícita para que el lector entienda dependencias sin recorrer todo el proyecto.

  • Nombra módulos por intención (`precio`, `auth`, `fechas`) y no por vaguedad (`helpers2`).
  • Evita exportar todo por defecto sin criterio.
  • Mantén rutas limpias y coherentes para facilitar refactors.
  • Revisa dependencias circulares al modularizar código antiguo.
Módulo de utilidades
Revisar
// archivo: utils/precio.js
export function aplicarIVA(base, iva = 0.21) {
  return base * (1 + iva);
}

export const MONEDA = 'EUR';

// archivo: app.js
import { aplicarIVA, MONEDA } from './utils/precio.js';

console.log(aplicarIVA(100), MONEDA);

Named export vs default export

Ambos son válidos, pero cada uno tiene un contexto más claro.

1

Usa named exports cuando un módulo ofrece varias piezas o cuando quieres autocompletado/renombrado más explícito.

2

Usa default export cuando el módulo representa una única entidad principal (por ejemplo, una clase o función central).

Comparativa rápida
Revisar
// named export
export function validarEmail(email) {
  return email.includes('@');
}

// default export
export default function crearCliente(nombre) {
  return { nombre, activo: true };
}

Diferencias prácticas: navegador y Node

ESM es el estándar, pero el contexto de ejecución importa.

En navegador, para usar módulos debes cargar scripts con `type=module`. En Node, depende de extensión/configuración (`.mjs` o `type: module`).

Comprender este detalle evita errores típicos como rutas incorrectas o mensajes de import no soportado.

  • En frontend, incluye extensión en rutas relativas (`./modulo.js`).
  • No mezcles CommonJS y ESM sin estrategia explícita.
  • Separa entrypoint (`main.js`) de módulos internos.
  • Comprueba mensajes de consola sobre path/resolución de módulos.
Entrada en navegador
Revisar
<!-- index.html -->
<script type="module" src="./main.js"></script>

// main.js
import { iniciarApp } from './app/iniciar.js';

iniciarApp();

Checklist de modularización sostenible

Si aplicas estas reglas, tu base de código será más fácil de evolucionar.

Una buena modularización no persigue archivos mínimos, sino límites claros entre responsabilidades.

Antes de crear más módulos, valida si cada uno aporta cohesión y evita acoplamiento innecesario.

  • Cada módulo tiene propósito único y nombre semántico.
  • Las exportaciones son mínimas y explícitas.
  • No hay dependencia circular entre módulos principales.
  • Puedes probar/utilizar un módulo sin cargar toda la app.

🧪 Aprende probando

Ejemplo Ejemplo guiado: módulo de utilidades Separa cálculo e interfaz importando funciones desde un módulo dedicado.
Ejemplo Ejemplo guiado: export default Usa exportación por defecto cuando el módulo representa una sola pieza principal.
Ejemplo Demo interactiva: mini arquitectura por módulos Simula un flujo modular (validar + calcular + presentar) para ver cómo cada bloque tiene una responsabilidad.

🏁 Retos

Reto Reto 1: módulo de formato Define una función exportada para formatear nombres y luego úsala desde otro archivo con import.
Reto Reto 2: combinar default y named exports Crea un módulo que exporte una función por defecto y una constante nombrada; luego impórtalas y ejecútalas.

¿Qué es esto?

Soy Cristian Eslava y a veces hago webs para procrastinar yo y vosotros 😉.

Esta la hice en febrero de 2026 para facilitar el aprendizaje de mis alumnxs. Aprender desarrollo web practicando. La idea es que crezca semanalmente con nuevos temas, tests y retos.

Inspirado en MDN, en W3Schools, en Codepen, en el crack de Manz y en mil sitios de documentación sobre desarrollo web. Quería aportar además de bloques teóricos con ejemplos, la gamificación de los retos y el sistema de test que ya tenía en culTest .

Si te gustó, si no te gustó, si quieres saludarme, o invitarme a 🍻 no dudes en escribirme en cristianeslava@gmail.com .