Definición
TypeScript es JavaScript con un sistema de tipos encima. Le dices al lenguaje qué forma tiene cada dato, y un comprobador te avisa mientras escribes si algo no encaja.
Es un superconjunto: todo JavaScript válido es TypeScript válido. Puedes empezar cambiando la extensión del fichero y añadir tipos poco a poco.
El detalle clave: los tipos desaparecen al compilar. El navegador nunca ve TypeScript. Un compilador lo traduce a JavaScript normal y los tipos se borran. Son una ayuda para quien escribe el código, no algo que exista en tiempo de ejecución.
Qué resuelve
El problema real que ataca es este: en JavaScript, un error de tipo no se descubre hasta que el código se ejecuta. Y a veces eso pasa en producción, con un cliente delante.
function total(precio: number, cantidad: number): number {
return precio * cantidad;
}
total("12.50", 3); // TypeScript te lo marca aquí, antes de ejecutar
En JavaScript puro eso devuelve NaN y el error aparece tres pantallas más adelante, con un mensaje que no menciona el origen.
Lo que ganas, por orden de valor real:
- El editor sabe qué tiene entre manos. Autocompletado de verdad, no adivinando. Esto es lo que más productividad da y lo que menos se menciona.
- Refactorizar deja de dar miedo. Cambias el nombre de un campo y el compilador te enseña los 40 sitios que hay que tocar.
- Los tipos documentan. La firma de una función dice qué espera y qué devuelve, sin comentarios que se quedan viejos.
- Menos errores tontos en producción.
Ejemplo práctico
Esta web está escrita en TypeScript, y donde más se nota es en el diccionario.
Cada término es un fichero Markdown con una cabecera de datos: título, categoría, nivel, palabras clave, fechas. Hay un esquema que valida esa cabecera y, a partir de él, TypeScript deriva el tipo de un término.
El efecto práctico: cuando escribo la plantilla que pinta una ficha y pongo termino.definicionCorta, el editor me lo autocompleta. Si me equivoco y escribo termino.definicion, me lo marca en rojo antes de compilar. Con 101 términos y una plantilla compartida, un error así sin tipos aparecería como una página en blanco en un término concreto y a saber cuándo.
El caso más claro fue al añadir una quinta categoría al diccionario. TypeScript me listó de golpe todos los sitios donde había un mapa de categoría a color al que le faltaba la nueva. Sin tipos, eso se descubre cuando alguien entra en la categoría nueva y no tiene color.
Los tipos que más se usan
- Primitivos:
string,number,boolean. - Interfaces y
type: la forma de un objeto. - Uniones:
"principiante" | "intermedio" | "avanzado". Solo esos tres valores, nada más. Es de lo más útil del lenguaje. - Opcionales:
email?: string, que puede no venir. - Genéricos: tipos que reciben otro tipo como parámetro, para escribir algo una vez y usarlo con cualquier dato.
unknown: para lo que viene de fuera y hay que comprobar antes de usar.
Errores comunes
- Poner
anyen todo. Es la salida de emergencia y anula el sistema entero. Si te ves escribiendoanya menudo, o el tipo está mal planteado o estás peleando contra la herramienta. - Confundir tipos con validación. Los tipos no existen en ejecución. Si un dato viene de una API o de un formulario, hay que validarlo de verdad con una librería como Zod. TypeScript te promete la forma; no te la garantiza.
- Tipos rebuscados. Cuando un tipo necesita cinco líneas de genéricos anidados, casi siempre hay un diseño más simple detrás.
- Ignorar los errores del compilador. Un
@ts-ignorees una promesa de que sabes lo que haces. Suele ser mentira.
Cuándo compensa
Sí cuando el proyecto va a durar, cuando lo va a tocar más de una persona, cuando hay muchos datos con estructura, y cuando vas a refactorizar a menudo. En un proyecto mediano el coste de escribir tipos se recupera en la primera semana.
No —o no todavía— en un script de veinte líneas, en un prototipo que se va a tirar, o si el equipo no lo conoce y el proyecto es urgente. Un TypeScript lleno de any es más ruido que ayuda.
