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

Analytics Lane lanza la versión 1.1 del laboratorio con nuevas suites de CLV y Scoring

Seguimos evolucionando el laboratorio de Analytics Lane y hoy lanzamos la versión 1.1, disponible en:…

5 horas ago

Interés compuesto: la fuerza que multiplica tu dinero (y los errores que la anulan)

“El interés compuesto es la octava maravilla del mundo. El que lo entiende lo gana…

4 días ago

Cómo comparar datos con barras en Matplotlib: agrupadas, apiladas y porcentuales

Tienes los datos de ventas de tres productos en dos años distintos y quieres saber…

6 días ago

Costes hundidos en ciencia de datos: cuándo mantener un modelo y cuándo migrar

Imagina la situación. Tu equipo lleva tres años con un modelo en producción. No es…

2 semanas ago

WOE e IV: La Base Matemática del Credit Scoring

Cuando un banco evalúa una solicitud de crédito necesita responder a una pregunta aparentemente simple:…

2 semanas ago

Lanzamiento de la versión 1.0 del laboratorio de Analytics Lane con nuevas herramientas de scoring

En el octavo aniversario de Analytics Lane seguimos ampliando nuestro laboratorio de aplicaciones interactivas y,…

2 semanas ago

This website uses cookies.