TypeScript vs JavaScript en 2026: cuándo compensan los tipos

Usa TypeScript cuando el código vaya a sobrevivir a quien lo escribió: proyectos de varios meses, equipos de más de dos personas, APIs públicas o internas y cualquier cosa que se vaya a refactorizar. Usa JavaScript puro cuando el código es pequeño, de vida corta o pertenece a una sola persona que lo borrará antes de que necesite mantenimiento. En 2026 el argumento de las herramientas de build contra TypeScript prácticamente ha desaparecido; lo que queda es un juicio sobre cuánto vale un contrato en tiempo de compilación para tu equipo.

Qué garantiza TypeScript en realidad (y qué no)

TypeScript es un comprobador estático de tipos por encima de JavaScript. Lee tu código, infiere o comprueba los tipos, informa de las incompatibilidades y luego borra cada anotación. El JavaScript que se ejecuta es el mismo que habrías escrito a mano. Nada cambia en runtime.

Eso te da tres garantías concretas en tiempo de compilación:

• Toda propiedad a la que accedes existe en el tipo que declaraste.
• Toda función se llama con la forma de argumentos que declara.
• Todo valor marcado como posiblemente null o undefined se gestiona antes de usarlo (con strictNullChecks activado).

Y tres cosas que no garantiza:

• Que los datos que llegan en runtime son lo que dijiste que eran. Un as User sobre la respuesta de un fetch es una promesa al compilador, no una comprobación.
• Que tu lógica es correcta. Una función tipada como (a: number, b: number) => number puede seguir devolviendo el número equivocado.
• Que los tipados de terceros son precisos. Los paquetes @types/* y los archivos .d.ts escritos a mano son documentación en la que el compilador confía.

TypeScript también es deliberadamente "unsound". any, las aserciones de tipo y // @ts-ignore son válvulas de escape por diseño. Una base llena de ellos tiene un paso de build y ninguna garantía. El valor de TypeScript es proporcional a lo estricto que estés dispuesto a ser.

Coste y beneficio según el tamaño del proyecto y del equipo

La balanza cambia con la escala. El coste de TypeScript es más o menos constante: un archivo de configuración, un paso de comprobación de tipos, algo de curva de aprendizaje y, de vez en cuando, tiempo perdido con un genérico complicado. El beneficio crece con el número de puntos de llamada, de personas y de años.

Desarrollador solo, código de vida corta. Un script que parsea un CSV y genera un informe gana casi nada con los tipos. Tienes todo el programa en la cabeza; una ejecución fallida te dice qué está mal antes que un error de tipo.

Equipo pequeño, un producto, unos meses. Esta es la zona gris. Si el producto sobrevive al prototipo, echarás de menos los tipos cuando llegue la primera gran refactorización. La mayoría de los equipos en esta situación empieza con TypeScript en modo no estricto y lo endurece a medida que el código se asienta.

Varios equipos, módulos compartidos, años de mantenimiento. Aquí los tipos no son opcionales. Son el único mecanismo que escala para avisar a un desarrollador de un equipo de que un cambio en el módulo de otro equipo rompió su punto de llamada, antes de que el código llegue a CI. Renombra un campo en un tipo compartido y el compilador lista cada archivo afectado en segundos. En JavaScript puro, ese mismo rename es un grep y una plegaria.

La otra dimensión es la rotación. Los tipos son la documentación más barata que puedes escribir, porque el compilador los mantiene honestos. Un ingeniero nuevo lee la firma de una función y sabe qué entra y qué sale sin abrir otros tres archivos ni leer los tests. Combinado con un buen proceso de revisión de código, esto acorta la rampa de semanas a días en una base grande.

TypeScript vs JavaScript: tabla comparativa

Criterio	JavaScript	TypeScript
Paso de build	Ninguno obligatorio (ESM se ejecuta de forma nativa)	Type stripping o transpilación; casi instantánea con esbuild/SWC/Vite o el stripping nativo de Node
Seguridad al refactorizar	Depende de tests y grep	El compilador señala cada punto de llamada afectado
Onboarding	Leer tests y llamadas para entender los contratos	Las firmas y las interfaces documentan los contratos
Soporte del IDE	Inferencia por uso; a menudo adivina	Autocompletado preciso, ir a la definición, errores inline
Seguridad en runtime	Ninguna por parte del lenguaje	Ninguna por parte del lenguaje; requiere validación en las fronteras
Tipados de librerías	No aplica	La mayoría de los paquetes grandes ya incluyen tipos; algunos van con retraso o faltan
Curva de aprendizaje	Menor; un solo lenguaje	JavaScript más un sistema de tipos; los genéricos y los utility types llevan tiempo
Superficie de configuración	Mínima	tsconfig.json, flags strict, configuración de módulos
Detectar "undefined is not a function"	En runtime	En tiempo de compilación, si el valor vino de código tipado

La fila que sorprende es seguridad en runtime: las dos columnas dicen "ninguna". Ese es precisamente el tema de la siguiente sección.

El contexto de herramientas en 2026: el argumento del paso de build se acabó

Durante años, el argumento más fuerte contra TypeScript era la fricción con las herramientas. Ese argumento se ha derrumbado en gran medida.

• Node ejecuta archivos TypeScript directamente. Las versiones actuales de Node eliminan las anotaciones de tipo al cargar, así que node app.ts funciona con código que usa solo sintaxis borrable (sin enum, sin parameter properties, sin namespace heredado con código en runtime). Consulta la documentación de Node.js para las reglas exactas de tu versión.
• esbuild y SWC transpilan sin comprobar tipos. Eliminan los tipos en milisegundos. Vite usa esbuild en desarrollo y puede usar bundling basado en Rolldown en producción, así que un frontend en TypeScript se construye tan rápido como uno en JavaScript. Si estás eligiendo un bundler, mira nuestra comparativa de herramientas de build para frontend.
• tsc es un comprobador de tipos, no tu bundler. La configuración moderna ejecuta tsc --noEmit en el editor (a través del language server) y en CI, y deja que el bundler o el runtime se encarguen de la salida JavaScript real. Comprobar tipos y transpilar son preocupaciones separadas con herramientas separadas.
• Viene un compilador nativo. Microsoft está portando el compilador y el language server de TypeScript a Go, con el objetivo declarado de acelerar mucho la comprobación de tipos y la respuesta del editor. Trátalo como una dirección, no como una versión sobre la que planificar hoy; la semántica del lenguaje no cambia.
• Bun y Deno ejecutan TypeScript de forma nativa desde hace años.

Consecuencia práctica: la pregunta "¿TypeScript va a ralentizar mi build?" ahora es "¿la comprobación de tipos va a ralentizar mi CI?". En un monorepo grande la respuesta todavía puede ser sí, y las soluciones son project references, builds incremental y ejecutar la comprobación en paralelo con los tests.

Un tsconfig.json mínimo de 2026 para un servicio Node queda así:

{
  "compilerOptions": {
    "target": "es2022",
    "module": "nodenext",
    "strict": true,
    "noEmit": true,
    "skipLibCheck": true,
    "verbatimModuleSyntax": true,
    "erasableSyntaxOnly": true
  },
  "include": ["src"]
}

erasableSyntaxOnly rechaza el puñado de características de TypeScript que necesitan una transpilación real, lo que mantiene el código compatible con el type stripping de Node.

Validación en runtime en las fronteras: por qué los tipos solos no bastan

Todo programa no trivial tiene fronteras por las que entran datos sin tipar: cuerpos de peticiones HTTP, respuestas de APIs de terceros, filas de base de datos, colas de mensajes, variables de entorno, archivos en disco. TypeScript no ve más allá de esas fronteras. Lo que anotes ahí es una suposición.

// Esto compila. También es mentira si la API cambia.
const user = (await res.json()) as User;
user.email.toLowerCase(); // TypeError en runtime si falta email

La solución es validar en la frontera y derivar el tipo estático del validador, para que los dos no se desincronicen. Tanto zod como valibot soportan este patrón; valibot es tree-shakeable y más pequeño para bundles de navegador.

import { z } from "zod";

const User = z.object({
  id: z.string().uuid(),
  email: z.string().email(),
  role: z.enum(["admin", "member"]),
});
type User = z.infer<typeof User>;

const user = User.parse(await res.json()); // lanza un error con un mensaje preciso
user.email.toLowerCase(); // ahora garantizado como string

Reglas prácticas:

• Valida una vez, en el borde. Dentro del sistema, confía en los tipos.
• Deriva los tipos de los esquemas, nunca al revés.
• Trata las variables de entorno como una frontera. Un esquema para process.env detecta un despliegue mal configurado en el arranque, y no a las 3 de la madrugada.
• Combínalo con una estrategia consistente de manejo de errores y logging para que los fallos de validación sean visibles, no se traguen.

Los equipos que se saltan este paso se quedan con lo peor de los dos mundos: la ceremonia de los tipos y los fallos en runtime del código sin tipar.

Ruta de migración para una base JavaScript existente

No necesitas una reescritura. El compilador se diseñó para una adopción gradual, y una base mixta JS/TS es un estado normal y estable, no una transición que atravesar a toda prisa.

Etapa 1: comprobar el JavaScript tal cual.

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true,
    "noEmit": true,
    "strict": false
  },
  "include": ["src"]
}

Ejecuta npx tsc. Obtendrás errores en archivos .js solo por inferencia: propiedades mal escritas, funciones llamadas con el número de argumentos equivocado. Corrígelos o suprímelos con // @ts-expect-error (que falla si el error desaparece, a diferencia de @ts-ignore).

Etapa 2: añadir tipos JSDoc en los archivos más editados. Sin renombrar nada, sin cambiar el build. El compilador lee JSDoc.

/**
 * @param {{ price: number, qty: number }[]} items
 * @returns {number}
 */
export function total(items) {
  return items.reduce((s, x) => s + x.price * x.qty, 0);
}

Algunos equipos se quedan aquí para siempre. Grandes librerías JavaScript publican sus tipos así y nunca renombran un archivo.

Etapa 3: renombrar módulos a .ts, primero las hojas. Empieza por las utilidades y los modelos de datos con pocos imports y avanza hacia los puntos de entrada. Cada archivo renombrado recibe anotaciones reales. Añade paquetes @types/* para las dependencias según aparezcan; escribe un .d.ts local para las que no tengan tipado.

Etapa 4: activar las flags strict en orden. Activar strict de golpe en una base grande produce miles de errores y paraliza el esfuerzo. Actívalas una a una y corrige cada lote:

1. noImplicitAny
2. strictNullChecks (la que más bugs reales tiene detrás)
3. strictFunctionTypes, strictPropertyInitialization
4. noUncheckedIndexedAccess (opcional, estricta con la indexación de arrays y objetos)

Etapa 5: imponerlo en CI. tsc --noEmit pasa a ser una comprobación obligatoria. Prohíbe nuevos any con @typescript-eslint/no-explicit-any. Sigue el recuento de comentarios @ts-expect-error y hazlo bajar.

Mantén unas pocas reglas durante todo el proceso:

• Nunca mezcles una migración de tipos con un cambio de comportamiento en el mismo pull request.
• Convierte los tests junto con los módulos que cubren.
• Si un archivo se te resiste más de una hora, déjalo en JavaScript con JSDoc y sigue adelante.

Es la misma lógica incremental que se aplica a migrar sistemas heredados: pasos pequeños y reversibles, cada uno entregable.

Antes y después: qué detecta un tipo en realidad

JavaScript puro:

function applyDiscount(order, discount) {
  return order.total - order.total * discount.percent;
}

applyDiscount({ total: 100 }, { percentage: 10 });
// Devuelve NaN. Nadie se da cuenta hasta que una factura muestra "NaN €".

TypeScript:

type Order = { total: number };
type Discount = { percent: number }; // 0.1 para 10%

function applyDiscount(order: Order, discount: Discount): number {
  return order.total - order.total * discount.percent;
}

applyDiscount({ total: 100 }, { percentage: 10 });
// Error: Object literal may only specify known properties,
// and 'percentage' does not exist in type 'Discount'.

Fíjate en lo que el tipo no detectó: el comentario dice que percent es una fracción, pero quien pasa 10 en lugar de 0.1 sigue compilando. Eso es un contrato de lógica, y su sitio es un test o un branded type, no un number a secas. Los tipos estrechan el espacio de bugs; no lo vacían. Aquí es donde un enfoque disciplinado de desarrollo orientado a pruebas cubre el hueco.

Cuándo JavaScript puro es la decisión correcta

TypeScript es el valor por defecto, no la ley. JavaScript puro está bien, y a veces es mejor, cuando:

• El código tiene menos de unos cientos de líneas y un solo responsable.
• Es un script de build, una migración, un arreglo puntual de datos o un helper de CI.
• Es un prototipo que te has comprometido a tirar (y que de verdad vas a tirar).
• El runtime prohíbe un paso de build y no puedes usar el type stripping de Node.
• El código es intensivo en metaprogramación dinámica (proxies, estructuras generadas en runtime), donde los tipos serían básicamente any de todos modos.
• El equipo no tiene ninguna experiencia con TypeScript y el proyecto termina antes de que la curva de aprendizaje se amortice.

Incluso en estos casos, un // @ts-check al principio de un archivo .js te da comprobación por inferencia en el editor gratis. No cuesta nada probarlo.

Checklist de decisión

Responde antes de elegir. Tres o más "sí" apuntan a TypeScript.

• ¿Este código seguirá ejecutándose dentro de doce meses?
• ¿Lo editarán más de dos personas?
• ¿Expone funciones o tipos de los que dependen otros módulos o servicios?
• ¿Esperas renombrar o remodelar los modelos de datos centrales más de una vez?
• ¿Incorporas ingenieros con regularidad?
• ¿El modelo de dominio no es trivial (más de un puñado de tipos de entidad)?
• ¿Ya tienes validación en runtime en las fronteras, o estás dispuesto a añadirla?

Señales que apuntan a JavaScript:

• Un responsable, un propósito, desechable.
• No tener paso de build es aceptable y el runtime no puede eliminar tipos.
• El proyecto tiene una fecha límite medida en días y nadie en el equipo conoce TypeScript.

Si estás eligiendo toda la stack, no solo el lenguaje, sopesa las decisiones de alrededor (runtime, framework, hosting) con las mismas preguntas.

Recomendación

Adopta TypeScript con strict: true por defecto en cualquier base que vaya a recibir mantenimiento. Deja que el bundler o el runtime elimine los tipos y ejecuta tsc --noEmit como comprobación separada en el editor y en CI. Valida toda entrada externa con una librería de esquemas y deriva tus tipos de los esquemas. Mantén any y las aserciones de tipo fuera de la base, salvo detrás de un comentario que explique por qué.

En una base JavaScript existente, activa checkJs, añade JSDoc en los archivos que más cambian y renombra los módulos de las hojas hacia dentro mientras activas las flags strict una a una. No programes una reescritura; programa un trimestre de pull requests pequeños.

Reserva JavaScript puro para scripts, prototipos y herramientas con un solo responsable y vida corta. En Arvucore solemos recomendar TypeScript desde el primer commit en los proyectos de clientes, porque el coste de añadirlo después siempre es mayor que el de empezar con él.