La red de seguridad: por qué TS cuando ya sabes JS

Terminaste el supercurso de JavaScript: construyes apps, dominas closures, asincronía y patrones. Entonces, ¿para qué TypeScript? Porque cuando tu código crece —cuando lo tocas seis meses después, o en equipo—, JavaScript te deja solo ante los errores que solo aparecen al ejecutar. TypeScript te da una red que caza esos errores mientras escribes, y algo más valioso aún: la valentía de cambiar código sin miedo.

El plano del edificio

Regalo 1: los errores aparecen al escribir, no en producción

En JavaScript, un error de tipo es silencioso hasta que explota en runtime —muchas veces en la pantalla de un usuario. TypeScript lo subraya en rojo en tu editor, en el instante:

function calcularTotal(gastos) {
return gastos.reduce((suma, g) => suma + g.valor, 0);
}

calcularTotal({ valor: 5000 });
// ❌ En JS: gastos.reduce is not a function (¡en runtime, tarde!)
// ❌ En TS: Argument of type '{ valor: number }' is not assignable
//    to parameter of type '...[]'. — subrayado AL ESCRIBIR

const gasto = { nombre: "Café", valor: 4000 };
console.log(gasto.balor);
// ❌ En JS: undefined, silencioso — el bug vive semanas
// ❌ En TS: Property 'balor' does not exist. ¿Quisiste decir 'valor'?

Cada uno de esos // ❌ de TS aparece MIENTRAS tecleas, no cuando un usuario reporta que "los totales salen raros". El typo de balor, pasar un objeto donde iba un array: TypeScript los convierte de bombas de tiempo en avisos inmediatos. Es el mismo valor que el testing (módulo 16 de JS), pero para toda una categoría de bugs, gratis y sin escribir un solo test.

Regalo 2: refactor sin miedo

Este es el que enamora. Cambia el nombre de una propiedad o el tipo que devuelve una función, y TypeScript te señala TODOS los lugares que hay que actualizar —como una lista de tareas roja que desaparece a medida que arreglas:

// renombras 'valor' a 'monto' en el tipo Gasto...
// TS marca en rojo cada uso viejo en TODO el proyecto:
gasto.valor      // ❌ Property 'valor' does not exist. ¿'monto'?
suma + g.valor   // ❌ aquí también
// arreglas hasta que no queda rojo → el refactor está COMPLETO y correcto

En JavaScript, ese mismo cambio es un "buscar y rezar": esperas haber encontrado todos los usos, y descubres los que olvidaste cuando algo se rompe. Con TS, el compilador es tu lista de verificación exhaustiva. Por eso los proyectos grandes viven en TypeScript: no porque escribir tipos sea divertido, sino porque CAMBIAR código con red es lo que te deja evolucionar sin terror.

Regalo 3: documentación que no puede mentir

Los tipos describen la forma de tus datos y las firmas de tus funciones —y esa descripción vive EN el código, siempre actualizada:

// esta firma te dice TODO sin leer una línea del cuerpo:
function crearGasto(nombre: string, monto: number): Gasto

// tu editor te lo muestra al invocarla, y te autocompleta cada campo de Gasto.
// un comentario podría mentir (quedar viejo); un tipo NO: si mintiera, no compila.

Un comentario // recibe un número puede quedar obsoleto y engañarte. Un tipo : number no puede: si la realidad cambia, el código deja de compilar. Es documentación que el compilador OBLIGA a mantener verdadera —y, de paso, autocompletado que de verdad sabe qué métodos existen.

La regla de oro: el navegador no entiende TypeScript

Mini-reto

De reflexión: repasa "Mi Bolsillo" del supercurso de JavaScript y anota tres lugares donde un typo en una propiedad, un undefined inesperado, o pasar el dato equivocado PUDO romper algo en silencio. Esos tres puntos son exactamente los que TypeScript habría subrayado en rojo. Verlos te da la motivación real para lo que viene: no es burocracia, es la red que te faltaba.

Qué sigue

Convencido del porqué, al cómo. La próxima lección monta un proyecto TypeScript de verdad —instalar el compilador, correrlo, y ver con tus ojos cómo los tipos se borran y queda JavaScript puro. Del concepto a las manos en el teclado.