TypeScript es JavaScript con un sistema de tipos estático encima. Lo creó Microsoft y se publicó en 2012, y hoy es la opción por defecto en muchos proyectos de cierto tamaño: Angular está escrito con él y se usa también en React, Vue y Node. No es una moda pasajera, pero tampoco es una solución universal. Esta guía explica qué problema resuelve, cuáles son sus límites y cómo empezar sin reescribir nada.
El problema que resuelve
En un proyecto JavaScript grande es fácil perder de vista qué forma de datos espera cada función. Refactorizar sin esa información es un ejercicio de fe: cambias algo y no sabes qué se rompe hasta que falla en producción. TypeScript comprueba los tipos al compilar y detecta buena parte de esos errores antes de ejecutar el código. Por ejemplo:
function precioConIva(precio: number, iva: number): number {
return precio * (1 + iva);
}
precioConIva('100', 0.21); // error al compilar: '100' no es un numberEn JavaScript puro, esa llamada no avisa y devuelve un resultado equivocado o un NaN en tiempo de ejecución.
Es JavaScript, no un lenguaje aparte
TypeScript es un superconjunto de JavaScript: cualquier código JavaScript válido es también código TypeScript válido. Por eso se puede adoptar de forma gradual, archivo a archivo. Lo que escribes se compila a JavaScript normal y los tipos desaparecen en ese proceso.
Qué aporta en el día a día
- Errores antes de ejecutar: el clásico «undefined is not a function» se reduce mucho.
- Autocompletado preciso en el editor, porque conoce la forma real de tus datos.
- Refactors más seguros: renombrar una propiedad muestra al instante todos los sitios que hay que actualizar.
- Documentación que no caduca: si un tipo deja de ser cierto, el compilador se queja.
Lo que TypeScript no hace
Conviene conocer sus límites para no confiar de más. Los tipos se borran al compilar, así que no validan los datos que llegan en tiempo de ejecución: una respuesta de una API que no cumple el tipo que declaraste no fallará por sí sola. Para eso se usan librerías de validación como Zod. Tampoco evita los errores de lógica, y su sistema de tipos puede volverse complejo si abusas de él: un tipo que nadie entiende es peor que no tener tipo.
Cómo empezar sin reescribir tu proyecto
- Añade TypeScript al proyecto y crea un
tsconfig.json. Activa la opciónallowJspara que conviva con tus archivos JavaScript. - Migra archivo a archivo, empezando por las utilidades pequeñas y los modelos de datos, que son los que más se reutilizan.
- Activa el modo estricto (
strict: true) en proyectos nuevos. En uno existente puedes activarlo por partes para no bloquearte. - Evita el tipo
any: desactiva la comprobación y vuelves al punto de partida. Si dudas, prefiereunknowny estrecha el tipo antes de usarlo. - Deja que el compilador infiera: no hace falta anotar todo. Escribe los tipos en las firmas de funciones y en los datos que entran al sistema, y deja que el resto se deduzca.
Qué aprender primero
Con lo básico (tipos primitivos, interfaces y alias de tipo) ya se obtiene la mayor parte del beneficio. Después, merece la pena aprender las uniones y el estrechamiento de tipos, los genéricos y los tipos utilitarios que trae el lenguaje: Partial, Pick, Omit o Record. No hace falta dominar los tipos avanzados para ser productivo.
¿Merece la pena?
Si trabajas con proyectos que van a crecer, con varias personas o que vas a mantener durante años, casi siempre sí: el coste de aprendizaje es bajo y el beneficio crece con el tamaño del código. En un script pequeño o un prototipo desechable, el esfuerzo extra puede no compensar. Y si buscas trabajo como desarrollador frontend, es una habilidad que aparece con frecuencia en las ofertas. Empieza por un proyecto pequeño, migra poco a poco y deja que el compilador te enseñe.











Comentarios (0)
Deja un comentario
Cargando comentarios...