Usted ya conoce los argumentos familiares. TypeScript le brinda garantías más sólidas y mejores herramientas. JavaScript le brinda menos partes móviles y más inmediatez. Ese viejo debate no ha desaparecido; simplemente ha sido replanteado por tres cambios que importan en 2025:

  1. La IA ahora reside en el editor, refactorizando y creando código más rápido de lo que escribimos.
  2. Los runtimes y toolchains modernos han cambiado el costo de adoptar (o evitar) TypeScript.
  3. El proceso de estándares del lenguaje insinúa un futuro donde la sintaxis "tipo-ish" y JavaScript se vuelven vecinos más amigables.

Esta es una revisión pragmática para el desarrollador aumentado por IA: qué ha cambiado, qué es señal frente a ruido y dónde gana cada elección.

El mundo en el que vive su código se ha movido

Los runtimes son menos alérgicos a TypeScript. Deno ejecuta archivos .ts directamente con verificación de tipos y compilación integradas, sin configuración adicional. Bun ejecuta TypeScript de inmediato, transpilando sobre la marcha con su pipeline nativo. Incluso Node ha avanzado: Node.js 23+ ahora ejecuta archivos .ts de forma nativa mediante la eliminación de tipos, y en la versión 23.6+ está activado de forma predeterminada (sin verificación de tipos; use tsc para eso). Esto reduce el "impuesto de configuración" histórico que alguna vez hizo que TypeScript se sintiera pesado para pequeños servicios y scripts. Las herramientas tratan la verificación de tipos como un carril separado. Vite, el servidor de desarrollo de facto para front-ends modernos, transpila TypeScript con esbuild (muy rápido) pero no realiza la verificación de tipos durante esa ruta activa. El consejo oficial es: deje que su IDE y un tsc --noEmit paralelo (o un plugin) impongan los tipos mientras el servidor de desarrollo se mantiene ágil. Esta separación (transpilar rápido, verificar en paralelo) es ahora sabiduría convencional. La evolución del lenguaje ha reducido la fricción. TypeScript se alineó con los decoradores ECMAScript estandarizados en la versión 5.0, pasando de la variante experimental de larga data. Eso elimina una notoria oscilación de compatibilidad con frameworks y transpiladores. Y el futuro está coqueteando con "tipos como comentarios". La propuesta de "Anotaciones de Tipo" de TC39 (a menudo llamada "tipos como comentarios") permanece en la Etapa 1. Todavía no es JavaScript real, pero la intención es clara: permitir la sintaxis de tipos que los engines ignorarán mientras los checkers externos la analizan. Si esto cruza el río en los próximos años, la distancia psicológica entre JS y TS se reducirá aún más. Por ahora, es una tendencia, no un plan en el que deba confiar.

Dónde se encuentra TypeScript ahora mismo

  • La última versión estable es 5.9.x. npm muestra 5.9.3 como la versión actual; el anuncio 5.9 de Microsoft señala que la actualización a 6.0 debería ser en gran medida compatible con la API. Todavía no hay una versión GA 6.0.
  • Lo que probablemente significará 6.0: el equipo ha estado trabajando hacia una implementación nativa/alternativa y utilizó publicaciones de blog de 2025 para señalar que 6.x traerá algunas desaprobaciones para alinearse con esa dirección. Trate 6.0 como un hito de limpieza/compatibilidad en lugar de un nuevo paradigma de lenguaje.
  • Preparación para "6.0": Espere actualizaciones de bajo drama de 5.9 → 6.0; Microsoft dice que la compatibilidad debería ser alta. Esté atento a las advertencias de desaprobación en las notas de la versión 5.9.

Planifique para 5.9 hoy, esté atento a 6.0 (se espera una actualización de bajo drama) y apóyese en el manejo nativo de TS de los runtimes para simplificar los bucles de desarrollo.

La IA es el nuevo compañero de equipo, y los tipos son su brújula

Con asistentes estilo Copilot, la pregunta es menos "¿Puedo escribir esta función?" y más "¿Puede la máquina mantener mi codebase coherente a medida que escala?" Los experimentos controlados muestran que los copilotos de IA pueden mejorar la velocidad de finalización de tareas; cualitativamente, los equipos informan que los tipos le dan a la IA un andamio para ediciones más seguras y una navegación más precisa: menos sugerencias "inteligentes pero incorrectas" cuando las restricciones son explícitas. Piense en los tipos como barandillas en una escalera oscura: los humanos pueden tantear el camino sin ellas, pero las barandillas ayudan a todos a moverse más rápido y a caer menos.

Concretamente, vemos tres efectos compuestos en las tiendas asistidas por IA:

  • Las refactorizaciones son más valientes. Los cambios de nombre y de firma se propagan a través del grafo sin tanto temor; el asistente más el checker capturan más aristas.
  • El prompting es más nítido. "Haga que fetchInvoices devuelva ReadonlyArray y conserve el tipo InvoiceId con marca" no es poesía, pero es una instrucción inequívoca tanto para una IA como para el compilador.
  • La incorporación se acelera. Los nuevos contribuyentes (humanos o modelos) infieren la intención del dominio a partir de los tipos y JSDoc de manera más confiable que a partir de una taxonomía popular de nombres de archivo.

Si está utilizando la IA para impulsar refactorizaciones amplias a través de un codebase, TypeScript es un multiplicador de fuerza. Si su código es de corta duración (scripts, glue, experimentos), JS con tipos JSDoc y @ts-check puede alcanzar el punto óptimo de velocidad con suficiente seguridad.

El tamaño importa: un marco práctico

La mayoría de los proyectos "grandes" son en realidad medianos. Utilice estos ejes para dimensionarse: personas que se comprometen activamente, vida útil del código, área de superficie (paquetes/servicios) y exposición de la API (interna vs pública).

Pequeño

Definición: 1–2 desarrolladores; vida útil ≤ 6–9 meses; ≤ 10k LOC; 1–3 desplegables; usuarios internos; la superficie de la API no es pública/de larga duración. Valores predeterminados que funcionan en 2025:
  • Lenguaje: JavaScript + JSDoc + // @ts-check para la inteligencia del editor con una ceremonia casi nula. Promocione a TS más tarde si crece. (Los documentos de TS tratan los tipos JSDoc como de primera clase).
  • Runtime: Node 23+ (eliminación de tipo nativo) o Bun/Deno para bucles de retroalimentación instantáneos.
  • Validación: esquema en los bordes (Zod/Valibot/etc.); no sobre-modele los internos.
  • Build: ninguno (Node/Bun) o mínimo (Vite para front-end). Si usa Vite, mantenga la verificación de tipos separada.
  • Ángulo de la IA: deje que el asistente agregue JSDoc e impulse las correcciones de "ts-check"; usted sigue avanzando.
Cuándo actualizar a TS: en el momento en que la aplicación deba mantenerse más allá de un trimestre, o se una otro desarrollador y comience a realizar refactorizaciones reales.

Mediano

Definición: 3–10 desarrolladores; vida útil de 9–36 meses; 10k–75k LOC; 2–10 paquetes/servicios; múltiples entornos; algunas API internas estables. Valores predeterminados que valen la pena:
  • Lenguaje: TypeScript (estricto). Use exactOptionalPropertyTypes, noUncheckedIndexedAccess y prefiera el operador satisfies para configuraciones y literales.
  • Runtime: Node 23+ (eliminación de tipo nativo para desarrollo), o Bun/Deno; aún ejecute tsc --noEmit en CI y localmente (watch) para la verificación real.
  • Build: Vite/ESBuild/SWC para la velocidad de transpilación; checker en paralelo (vite-plugin-checker o tsc).
  • Estructura: un solo repositorio, "DTOs de límite" claros en los bordes, tipos de dominio en el interior.
  • Docs & DX: contratos de API a través de OpenAPI/JSON-Schema con tipos generados.
  • Ángulo de la IA: realice refactorizaciones de tipo primero: cambie los tipos, compile, corrija los sitios. El compilador se convierte en el mapa.
Huele a que se ha desviado a "grande": fusiones semanales entre equipos, SDK públicos, discusiones frecuentes sobre cambios importantes. Esa es su señal para adoptar controles "grandes".

Grande

Definición: 10–50+ desarrolladores; varios años; ≥ 75k LOC (a menudo 200k+ en todos los paquetes); 10–100 paquetes/servicios; API/SDK públicos; dominios regulados; trenes de lanzamiento formales. Valores predeterminados para institucionalizar:
  • Lenguaje: TypeScript, estricto en todas partes.
  • Monorepo & builds: Referencias de Proyecto + tsc -b con composite, declaration, declarationMap. Esto permite builds incrementales y grafos de dependencia precisos.
  • Gobernanza de la superficie pública: adopte API Extractor para bloquear/revisar por tipo las API exportadas; CI de puerta en informes de API.
  • Runtime/Dev: Node 23+ (o Bun/Deno) para bucles locales; CI todavía ejecuta verificaciones completas y produce .d.ts + artefactos.
  • Tooling: lint + format + type-check en pasos separados; almacene en caché los builds (Nx/Turbo) y automatice las referencias si es necesario.
  • Contratos: esquema primero en los límites del servicio; tipos versionados; política de desaprobación.
  • Ángulo de la IA: deje que el asistente escriba y aplique codemods guiados por errores de tipo; los revisores se centran en la intención, no en la plomería.

Qué es lo suficientemente nuevo como para cambiar de opinión en 2025

1) Decoradores que realmente puede estandarizar

TypeScript 5.0 implementa la propuesta de decoradores estandarizados. Los frameworks y las bibliotecas pueden converger en una sola historia; no tiene que vivir con el temor de las trampas de "decoradores heredados vs. decoradores modernos". Si los decoradores están en su arquitectura (Angular, Lit o su propia metaprogramación), esto solo elimina una razón importante por la que algunos equipos se protegieron en el pasado.

2) De "TypeScript compila JavaScript" a "los engines borran los tipos"

Entre Deno/Bun y la reciente eliminación de tipos de Node, la imagen del runtime es más simple. Puede tratar TypeScript como sintaxis que las herramientas borran, no como un segundo universo que debe apaciguar constantemente. Y aunque el soporte de Node se centra en la eliminación en lugar de la verificación, eso sigue siendo suficiente para reducir el afeitado de yak en pequeños servicios y CLI.

3) El bucle de build es ligero (si lo permite)

Los documentos de Vite lo dejan explícito: transpila solo en el servidor de desarrollo; ejecute tsc --noEmit (o use un plugin checker) para errores. Esto mantiene la recarga en caliente increíblemente rápida incluso en proyectos grandes. Las viejas quejas sobre "TypeScript ralentiza mi HMR hasta arrastrarse" a menudo se remontan a obligar al checker y al servidor de desarrollo a compartir un solo pipeline. Sepárelos; el problema se evapora en su mayoría.

4) El propio TypeScript sigue recortando la grasa

El impulso constante del equipo de TS últimamente ha sido "más pequeño, más simple, más rápido". Ese arco incluye el trabajo de decoradores estandarizados y esfuerzos de rendimiento significativos, además de la experimentación continua con implementaciones nativas/transpiladas que prometen aceleraciones. Esto importa si su codebase es grande; el compilador cada vez más se aparta de su camino.

Dónde están los frameworks

Los documentos oficiales de React presentan TypeScript como la forma predeterminada de expresar props y hooks; Next.js crea andamios con TypeScript automáticamente y se posiciona como "TypeScript-first". En la práctica, la mayoría de los starters de front-end modernos asumen que estará en TS, incluso si todavía toleran .js. Eso no es ideología; es lo que la mayoría de los equipos han elegido.

Los datos de la encuesta respaldan esto. JavaScript sigue siendo el lenguaje más utilizado en general, pero la participación de TypeScript sigue aumentando y ahora es utilizado por un subconjunto muy grande de desarrolladores profesionales (y una mayor participación entre los equipos de front-end y full-stack). Si crea UI o servicios de Node profesionalmente, la atracción gravitacional es hacia TS.

El camino intermedio: JavaScript con tipos JSDoc

Hay una opción duradera y subestimada: escribir JavaScript, anotar con JSDoc y habilitar // @ts-check. Obtiene muchas de las ergonomías (intellisense, seguridad básica, mejor ayuda del editor) sin comprometerse con archivos .ts o un paso de compilación. Para bibliotecas pequeñas, scripts rápidos y código que vive cerca de los bordes (manejadores lambda, glue de worker), este es un compromiso pragmático. Los equipos que eligen esto tienden a:

  • Mantener la validación del runtime como el contrato real (por ejemplo, Zod o Valibot) y usar JSDoc para mantener honestos a los editores.
  • Publicar .js sin formato (sin pipeline de build) mientras envían .d.ts para los consumidores que desean tipos.
  • Usar eslint/biome para imponer la coherencia y confiar en @ts-check para una corrección "suficiente".

La documentación del propio proyecto TypeScript trata esto como un camino de primera clase; no es un hack.

La verdad del runtime todavía vive en el runtime

Ningún sistema de tipos estáticos elimina la necesidad de validar las entradas en el límite. El patrón que envejece mejor en 2025 es:

  • Esquema en el borde (Zod, Valibot, TypeBox, etc.) para la validación y el análisis del runtime, generando tipos a partir de esquemas o viceversa.
  • Tipos en el núcleo para la guía de la IA, las refactorizaciones y la velocidad del desarrollador.
  • OpenAPI/JSON-Schema como la lingua franca entre los servicios.

Aquí es donde la IA realmente brilla: es asombrosamente buena para redactar esquemas a partir de ejemplos y mantener los tipos coherentes en todos los módulos, siempre y cuando su proyecto ya hable en esquemas y tipos.

Heurísticas de decisión para 2025 (IA en el bucle)

Utilice esto como una prueba de fuego: asuma que un par-programador de IA siempre está presente.

Elija TypeScript cuando…
  • El codebase sustentará a más de un equipo o varios trimestres de crecimiento.
  • Espera refactorizaciones grandes regulares (remodelación del dominio, preocupaciones transversales).
  • Crea API/SDK para otros y desea confianza en la superficie pública.
  • Está viviendo en React/Next/SvelteKit/Astro o un ecosistema basado en Vite que ya está optimizado para TS.
Elija JavaScript (+ JSDoc + @ts-check) cuando…
  • Está escribiendo pequeños servicios, CLI o scripts donde la iteración rápida y las implementaciones simples importan más que el modelado de tipos profundo.
  • Entrega código a equipos de habilidades mixtas donde un paso de compilación es una barrera.
  • Está apuntando a runtimes de borde o workers ligeros y desea artefactos mínimos: JS hoy, tipos más fuertes mañana.
Elija cualquiera de los dos con confianza cuando…
  • Se ejecuta en Deno o Bun. Ambos manejan TypeScript con una ceremonia mínima; ambos ejecutan JavaScript perfectamente. Su decisión se convierte en cultura, no en fricción.

Comprobaciones de realidad desde la trinchera

La promesa vs. los bugs de producción

El discurso de venta de TypeScript es irresistible: tipos estáticos, interfaces auto-documentadas, sugerencias premium del IDE. Son beneficios reales, pero la mayoría de las caídas que reviso provienen de otro lado: errores de lógica, flujos asíncronos que colapsan solo con tráfico real, APIs que mienten en runtime. El análisis estático nunca ve esas rutas.

Encuestas y datos internos cortan la exageración

Incluso Microsoft admite que las mayores ganancias aparecen en pilas empresariales enormes donde cientos de desarrolladores comparten la misma codebase. En equipos pequeños o medianos la curva se aplana. State of JS 2023 respalda ese sentimiento: apenas ~36 % de los desarrolladores de JavaScript reportaron un verdadero aumento de seguridad gracias a TypeScript, y muchos lo calificaron de percibido más que medido.

JavaScript moderno + validación en runtime ya es formidable

Los módulos ES, las funciones flecha, la destructuración/spread, el encadenamiento opcional, la coalescencia nula y async/await cubren el hueco de expresividad que TypeScript llenó al inicio. Sume ESLint/BIOME, pruebas unitarias y validadores en runtime (Zod, Valibot, superstruct) y estará atacando los bugs que realmente hieren a los usuarios.

import { z } from "zod";


const userSchema = z.object({
  name: z.string(),
  age: z.number().int().positive(),
});



export function greet(user) {
  const parsed = userSchema.parse(user);
  console.log(Hello ${parsed.name});
}

JavaScript puro, sin paso de compilación, y aun así el esquema rechaza un string para la edad antes de llegar a la base de datos. Ese es el modo de falla con el que lidia la mayoría de las apps SaaS.

Cuando TypeScript frena al equipo

He incorporado gente en repos TypeScript-heavy que pasó media jornada desenredando un mismatch de tipos que jamás importó en producción. Los builds se alargan, las pipelines de CI se frenan y la salida de emergencia termina siendo rociar any como confeti para enviar un fix. Así se cancela la promesa de seguridad y el desenlace suele ser reescribir de vuelta a JS puro.

Dónde sigue valiendo el presupuesto TypeScript

Las codebases masivas y de larga vida y las bibliotecas públicas aún justifican la ceremonia: allí TypeScript es el contrato API. Todos los demás pueden usar sin culpa JavaScript moderno con esquemas y pruebas hasta que el proyecto demuestre que necesita garantías más estrictas. Eso es exactamente lo que ordena el marco basado en tamaño descrito antes.

Patrones que juegan maravillosamente con la IA

  • Contratos de esquema primero: defina Zod/JSON-Schema para entradas y salidas, genere tipos y deje que el asistente los conecte a través de sus manejadores y pruebas.
  • DTO de límite + tipos de dominio estrechos: mantenga los tipos "grandes" en los bordes (API, DB) y los "pequeños, descriptivos" en el interior. La IA tiene menos espacio para improvisar incorrectamente.
  • Refactorizaciones basadas en tipos: pida al asistente que cambie los tipos primero, ejecute el checker y luego corrija los sitios. Este bucle de "tipos-luego-reparaciones" es más confiable que el de código-luego-tipos.
  • Prefiera satisfies para las configuraciones: en el código TS, const cfg = {...} satisfies Config mantiene la inferencia literal al tiempo que garantiza la forma. Esto evita una legión de errores de configuración sutiles y mejora las finalizaciones de la IA.

Antipatrones que envejecen mal

  • Servicios de larga duración y sin tipos que amplían silenciosamente los contratos hasta que nadie sabe cómo se ven los datos. (La IA realizará cambios con confianza... y a veces solo con confianza).
  • Escapes monolíticos de any para "desbloquear" un sprint. Estos hacen metástasis. Si debe hacerlo, escóndalos detrás de pequeñas funciones y documente por qué.
  • Forzar la verificación de tipos en la ruta activa del servidor de desarrollo. No pague ese impuesto de latencia innecesariamente; mantenga los builds rápidos y las verificaciones en paralelo.

Una rápida verificación de la realidad sobre los costos

TypeScript no es "seguridad gratuita". Usted paga en:
  • Tiempo de modelado. Alguien tiene que diseñar tipos que expresen su dominio sin convertir cada objeto en un problema de álgebra.
  • Superficie de herramientas. Linters, formatters, variantes de tsconfig: cada uno agrega una perilla que alguien podría girar mal.
  • Capacitación de los humanos. Los tipos imponen claridad; también revelan la ambigüedad que los comentarios estaban encubriendo.
JavaScript no es "velocidad gratuita". Usted paga en:
  • Contratos implícitos. Sin tipos ni esquemas, cada función es una caída de confianza.
  • Riesgo de refactorización. En el momento en que escala más allá de un par de miles de líneas, el costo de "buscar-reemplazar y esperar" se agrava.

La IA cambia la pendiente de ambas curvas (lo que hace que TypeScript sea más fácil de adoptar y JavaScript más fácil de mantener honesto), pero no elimina las compensaciones.

Prescripciones de una página que puede colocar en un repositorio

Pequeño (idea de tsconfig.json)

Use JS con // @ts-check; agregue types: ["node"] en jsconfig.json. Mantenga sin build siempre que sea posible. ¿Vite/React? Deje que Vite transpila; ejecute tsc --noEmit solo en CI.

Mediano

{
  "compilerOptions": {
    "strict": true,
    "exactOptionalPropertyTypes": true,
    "noUncheckedIndexedAccess": true
  }
}

Prefiera satisfies para objetos de configuración; esquemas en I/O; Node 23+ o Bun/Deno para ejecuciones locales; CI: tsc --noEmit + pruebas.

Grande

Espacio de trabajo con Referencias de Proyecto; composite, declaration, declarationMap; API Extractor con CI gating; líneas de base de tsconfig por paquete; notas de la versión generadas a partir de la diferencia de la API.

Recomendaciones por escenario

Aplicación front-end o full-stack greenfield (React/Next/Vite)

Predeterminado a TypeScript. Es el camino pavimentado, y su servidor de desarrollo no sufrirá si separa la transpilación de la verificación. Si está creando sistemas de diseño o componentes públicos, TS no es opcional; es su especificación pública.

Servicios back-end con Deno o Bun

Cualquiera de los dos lenguajes funciona; el delta de configuración es pequeño. Si el servicio es pequeño y efímero, JS con JSDoc está bien. Para cualquier cosa con peso de dominio o bibliotecas compartidas, elija TS.

Herramientas CLI, workers y glue code

Prefiera JavaScript con JSDoc y @ts-check. Mantenga las implementaciones muy simples; mantenga los esquemas del runtime estrictos. Si la herramienta se vuelve popular o compleja, ascienda a TypeScript en un fin de semana.

Bibliotecas/SDK que publicará

TypeScript. El autocompletado y los errores de compilación de sus usuarios son su marca. Envíe .d.ts fielmente (o genérelos) y trate la superficie de tipo como API. Los consumidores de React/Next lo esperarán.

Hacia dónde se dirige esto

La apuesta a largo plazo es la convergencia. Los runtimes están facilitando la ejecución de TypeScript. Los toolchains están fomentando la transpilación rápida con la verificación en paralelo. El proceso de estándares está explorando la sintaxis de tipos que los engines de JavaScript pueden ignorar de forma segura. Los frameworks escriben documentos en TypeScript primero y recurren a JavaScript en segundo lugar, no al revés. El significado práctico de "Escribo JavaScript" se está desplazando hacia "Escribo JavaScript con tipos en algún lugar cercano".

Su estrella polar no ha cambiado: haga que las invariantes sean legibles. Ya sea que las deletree como anotaciones de TypeScript, comentarios de JSDoc o esquemas del runtime, el objetivo es el mismo: convertir el conocimiento tácito en forma explícita para que tanto los humanos como las máquinas puedan colaborar productivamente.

El extraño regalo de 2025 es que ya no tiene que elegir la pureza. Use TypeScript donde aumente el apalancamiento de su equipo, JavaScript donde lo mantenga ágil y deje que la IA cierre las brechas con barandillas en lugar de conjeturas.

Conclusión: Dimensionarse sin piedad, luego elija

La pregunta no es "¿TypeScript o JavaScript?" Es cuán explícitas deben ser sus invariantes para que los humanos y las máquinas colaboren de forma segura.

La IA hace que ambos caminos sean más rápidos; los tipos hacen que la velocidad sea sobrevivible. Dimensionarse sin piedad utilizando el marco anterior (Pequeño/Mediano/Grande), luego elija la configuración más ligera que aún le permita refactorizar con audacia.

Los equipos más rápidos en 2025 no están debatiendo la pureza del lenguaje. Están enviando características con asistencia de IA, detectando errores con tipos o esquemas y ejecutando código en runtimes que finalmente respetan ambas opciones.

---

Acerca del autor: Odd-Arild Meling ha estado escribiendo JavaScript de producción desde antes de que existiera Node.js y TypeScript desde antes de que fuera genial. Ha migrado codebases de JS a TS, de TS a JS y viceversa, siempre con usuarios reales esperando al otro lado. Actualmente está construyendo arquitecturas edge-first en Gothar, donde ambos lenguajes se envían a producción diariamente.