Cuándo dejar de usar TypeScript¶

7 minutos de lectura · 20 marzo 2026

Esto va a sonar herético. Llevo cuatro años defendiendo TypeScript en cada proyecto donde he podido. Y aun así, este año saqué TS de tres bases de código y no quiero ponerlo de vuelta.

TypeScript no es gratis. La factura llega tarde, pero llega.

No es una postura. Es una observación de dónde el coste superó al beneficio.

El coste que no se ve¶

El argumento clásico es: "TS te da seguridad, te ahorra bugs en producción". Verdadero. Lo que no se cuenta:

• Mantener @types/* actualizados cuando una dependencia cambia.
• tsc --watch y el lag perceptible al guardar.
• Tipos que mienten porque la librería externa no se actualizó.
• Refactors que se atascan en errores de tipos en cascada de archivos que tú no querías tocar.
• El propio diseño de tu API condicionado por qué tipos sabes expresar.

Ninguno de esos costes es enorme. Sumados sí.

Las tres bases de código donde lo quité¶

1. Un script de cron en Node¶

Cuarenta líneas que corren cada noche y leen una API. El tipado de la respuesta es un unknown enmascarado. El parsing real lo hace Zod. ¿Qué me daba TS sobre JS + Zod? Nada que no estuviera ya en el z.infer<typeof Schema>.

Lo pasé a JS + JSDoc para los handlers y z.infer para los DTOs. CI bajó un minuto.

2. Un build script de un monorepo¶

esbuild + plumbing. Cero lógica de negocio, mucha manipulación de strings y rutas. El value de los tipos era marginal. La fricción al cambiarlo, alta.

JS + // @ts-check con JSDoc en las funciones de utilidad. Lo mejor de los dos mundos: aviso del editor sin compilación adicional.

3. Una librería pública¶

Esta sigue en TypeScript. Aquí TS sigue valiendo cada euro. Una librería que otros consumen necesita .d.ts legibles, autocompletado fiel y un contrato verificable. Es para lo que TS fue diseñado.

La heurística¶

Me quedo con TypeScript cuando:

1. El código lo va a consumir alguien que no lo escribió. Una librería, una API pública, un SDK.
2. El dominio tiene tipos no triviales. Reducers, ASTs, máquinas de estados.
3. El equipo tiene más de tres personas. Los tipos son documentación ejecutable.

Lo saco cuando:

1. Es un script personal o un job nocturno.
2. Zod / Valibot ya hace el trabajo donde importa (el borde externo).
3. El tiempo de iteración importa más que la solidez (prototipo, experimento, glue code).

El compromiso intermedio¶

Para los casos del medio, // @ts-check + JSDoc en JavaScript da el 80% del valor de TS sin el coste de tsc:

// @ts-check

/**
 * @param {string} ruta
 * @param {{ dryRun?: boolean }} [opciones]
 * @returns {Promise<number>}
 */
export async function limpiar(ruta, opciones = {}) {
  const dryRun = opciones.dryRun ?? false;
  // ...
}

El editor te avisa. No hay paso de build. No hay @types/* que mantener. El día que el archivo crece, lo renombras a .ts y ya.

¿Comentarios o correcciones? info@encodigo.es.