Por qué uso TypeScript en todo proyecto

La primera vez que escuché sobre TypeScript pensé que era complejidad innecesaria. JavaScript funciona, ¿por qué agregarle tipos encima? Después de usarlo en proyectos reales, cambié de opinión completamente. No lo uso porque está de moda: lo uso porque me hace más rápido.

El argumento que más me convenció

TypeScript no va de encontrar bugs en producción. Va de encontrar bugs mientras escribes.

Cuando defines los tipos de una función, el editor sabe exactamente qué esperas recibir y qué vas a devolver. Si en algún lado del código llamas a esa función con los argumentos incorrectos, el error aparece antes de correr una sola línea. No en producción, no en un test que tardó 30 segundos en ejecutarse: ahí, inmediatamente, con el cursor sobre el problema.

Ese ciclo de feedback inmediato es lo que cambia cómo trabajas.

Lo que TypeScript me obliga a hacer bien

Pensar la interfaz antes que la implementación. Cuando tienes que definir los tipos de entrada y salida de una función antes de escribirla, te obligas a pensar en el contrato de esa función. Qué recibe, qué devuelve, qué puede fallar. Ese proceso de pensar los tipos suele revelar problemas de diseño antes de haber escrito una sola línea de lógica.

Documentar sin escribir documentación. Los tipos son documentación que el compilador puede verificar. Una función con tipos bien definidos te dice exactamente cómo usarla sin que necesites leer ningún comentario.

Refactorizar con confianza. Si renombras un campo en una interfaz, TypeScript te muestra todos los lugares del código que usan ese campo. Puedes hacer cambios grandes con la certeza de que, si compila, no rompiste nada por omisión.

Lo que la gente exagera

"TypeScript es verboso." Lo era hace cinco años. Hoy, con la inferencia de tipos moderna, escribes menos anotaciones de las que crees. TypeScript infiere el tipo de retorno de la mayoría de las funciones, infiere tipos de arrays, objetos y desestructuración. Muchas veces solo anotas los parámetros de entrada y el resto se deduce solo.

"Lleva mucho tiempo configurarlo." Con Next.js, Vite o cualquier framework moderno, TypeScript viene configurado de base. No hay nada que hacer. Si estás en un proyecto existente de JavaScript, activa allowJs y ve migrando archivo por archivo: no necesitas reescribir todo de golpe.

Cuándo me parece bien no usarlo

Scripts cortos de un solo uso. Automatizaciones rápidas que corren una sola vez y se descartan. Prototipos de menos de 200 líneas que vas a tirar.

Para cualquier otra cosa (proyectos con más de una persona, proyectos que van a durar más de una semana, cualquier cosa que tenga una API): TypeScript.

La recomendación práctica

Si estás evaluando si empezar con TypeScript: empieza. No cuando "entiendas todo de JavaScript primero". Aprender TypeScript junto con JavaScript te enseña a pensar en tipos desde el principio, que es una habilidad más valiosa que agregarlos después. Si todavía no lo has tocado, mi introducción a TypeScript cubre lo básico.

Si ya usas JavaScript y estás evaluando migrar: empieza un archivo nuevo en TypeScript, convive con los dos durante un tiempo y ve migrando a medida que tocas los archivos.

Si trabajas con Next.js App Router, TypeScript brilla especialmente: los tipos para Server Components, params y Server Actions hacen que la experiencia sea mucho más segura.

Y un argumento nuevo que no tenía cuando empecé: si trabajas con coding agents, los tipos son el feedback más barato que puede recibir el agente. Un error de tsc le dice exactamente qué rompió, sin ejecutar nada. En seis meses sin escribir código a mano se ve por qué ese tipo de verificación automática es lo que escala.