JavaScript

null y undefined en JavaScript y TypeScript: ¿son realmente lo mismo?

Cuando alguien empieza a programar en JavaScript o TypeScript, una de las primeras dudas que aparece es esta: ¿null y undefined son lo mismo? A simple vista parecen equivalentes porque ambos representan la ausencia de un valor, pero en realidad expresan conceptos distintos, y usarlos de forma incorrecta puede provocar errores difíciles de rastrear.

En esta entrada veremos por qué existen dos valores “vacíos”, qué significa realmente cada uno, cuándo conviene usarlo y cómo los trata el lenguaje en diferentes situaciones. También revisaremos las implicaciones que tiene en TypeScript, donde la distinción entre ambos afecta a la definición de tipos, interfaces, clases y validaciones.

¿Por qué existen null y undefined?

JavaScript es un lenguaje curioso en muchos sentidos. Se desarrolló en muy poco tiempo y algunas decisiones iniciales se quedaron para siempre dentro del estándar, incluso si hoy no parecen las más acertadas. Una de ellas es la convivencia de dos formas distintas de representar la ausencia de valor:

ValorSignificado
undefinedAlgo no ha sido definido o no tiene asignación.
nullAlgo sí fue definido, pero se le asignó intencionalmente un valor vacío o no válido

Es decir:

  • undefined aparece de forma automática cuando algo todavía no tiene valor.
  • null es una decisión deliberada del desarrollador para indicar un valor vacío o no aplicable.

undefined: lo que JavaScript asigna por defecto

Cuando declaramos una variable sin inicializarla, JavaScript le asigna automáticamente undefined:

let a;
console.log(a); // undefined

Lo mismo ocurre cuando intentamos acceder a una propiedad que no existe:

const persona = { nombre: "Ana" };
console.log(persona.edad); // undefined

En estos casos, el lenguaje nos está diciendo: “La variable o propiedad existe… pero aún no tiene un valor.”

Incluso las funciones, salvo que se indique explícitamente lo contrario, devuelven undefined:

function saludar() {
  console.log("Hola");
}

const resultado = saludar();
console.log(resultado); // undefined

null: el valor vacío intencional

A diferencia de undefined, null nunca aparece automáticamente. Solo lo vemos cuando se asigna a propósito:

let usuario = null; // no hay usuario activo por ahora

Esto significa que la variable existe, pero su contenido está vacío por decisión del desarrollador. Se usa para representar estados como:

  • “todavía no tengo el dato”
  • “este valor no aplica”
  • “este espacio se rellenará más tarde”

Ejemplo:

let sesionActiva = null;

// ... más tarde en el programa
sesionActiva = { nombre: "Carlos", rol: "Admin" };

Comparaciones: ¿son iguales o no?

JavaScript tiene dos tipos de comparación:

  • == → comparación no estricta, permite conversiones de tipo
  • === → comparación estricta, no convierte tipos

Observemos esto:

null == undefined   // true
null === undefined  // false

Con == el lenguaje los considera equivalentes, pero realmente no lo son: sus tipos son distintos.

typeof undefined   // "undefined"
typeof null        // "object"  ← bug histórico del lenguaje

Este comportamiento de typeof null es un error reconocido desde los inicios de JavaScript, pero ya no puede corregirse sin romper millones de programas.

Usos recomendados en la práctica

En el desarrollo diario se suele adoptar una convención clara:

✔ Usa undefined cuando algo podría no existir.
✔ Usa null cuando algo está definido pero está vacío de manera intencional.

Esto no solo mejora la consistencia del código, sino también la comunicación dentro del equipo.

En TypeScript: aún más relevante

TypeScript añade tipado estático y, con strictNullChecks activado, obliga a distinguir de forma explícita si un valor puede ser null o undefined. Esto previene numerosos errores antes de ejecutar el programa.

Por ejemplo:

interface Usuario {
  nombre: string;
  edad?: number; // puede ser undefined
}

Aquí la propiedad edad puede o no existir. Es equivalente a edad: number | undefined.

En cambio:

interface Usuario {
  nombre: string;
  edad: number | null;
}

La propiedad siempre existe, pero su valor puede ser null.

Elegir uno u otro cambia completamente la semántica y el comportamiento esperado.

Buenas prácticas generales

Para finalizar, podemos enumerar algunas buenas prácticas a la hora de usar null o undefined en nuestro código:

  • No uses null y undefined como sinónimos.
  • Define una convención para tu proyecto y cúmplela.

En JavaScript:

  • Usa undefined para ausencia de definición.
  • Usa null para ausencia intencional.

En TypeScript:

  • Activa strictNullChecks.
  • Utiliza operadores de seguridad como ?, ?? y ?..

En APIs y bases de datos:

  • null indica un campo existente, pero sin valor.
  • undefined no debe aparecer: en JSON se omite automáticamente.

Conclusiones

Aunque null y undefined puedan parecer equivalentes al principio, representan ideas diferentes y cumplen roles distintos dentro del lenguaje. Comprender esta diferencia es esencial para escribir código más claro, robusto y coherente, especialmente en proyectos grandes o en entornos donde se manejan estados complejos.

En resumen:

ValorSignificadoCuándo usarlo
undefinedNo tiene asignaciónEl valor podría no existir
nullValor vacío asignado a propósitoEl campo existe, pero está “en pausa”

Dominar esta distinción no solo mejora la calidad del código: también mejora la comunicación entre desarrolladores y reduce sorpresas en la ejecución.

¿Te ha parecido de utilidad el contenido?

Daniel Rodríguez

Share
Published by
Daniel Rodríguez
Tags: TypeScript

Recent Posts

Migrar tslane a un paquete dual CommonJS y ESM con tsup y Vitest

tslane es la plantilla que uso como punto de partida para mis librerías TypeScript, nacida…

1 día ago

Cómo construir tu primer scorecard paso a paso

En los artículos anteriores de esta serie vimos la teoría detrás del credit scoring: qué…

3 días ago

Actualizar expresslanets a ES Modules con tsx y Vitest

expresslanets es la plantilla de API REST con Express y TypeScript que empezó como una…

1 semana ago

Pareto/NBD: cuando el abandono silencioso cambia el CLV

En el artículo del Dashboard vimos que Pareto/NBD aparecía junto a BG/NBD con un ajuste…

1 semana ago

Por qué migrar tus proyectos TypeScript a ES Modules en 2026

Durante años, CommonJS (require/module.exports) ha sido la forma por defecto de organizar módulos en Node.js,…

2 semanas ago

Método del codo: interpretación correcta y limitaciones

Cuando usas k-means tienes que decidir algo incómodo de entrada: cuántos grupos, , vas a…

2 semanas ago

This website uses cookies.