3 Sistemas de Tipos que No Son TypeScript

TypeScript es la forma predeterminada de tipar JavaScript, pero no es la única. Si alguna vez has añadido un paso de compilación a un proyecto pequeño solo para obtener unas pocas anotaciones de tipos, o has visto cómo tsc avanzaba lentamente por una base de código extensa, probablemente te has preguntado si existe una forma más ligera de obtener seguridad de tipos. La hay, y no es solo una opción.

Los tres sistemas de tipos no-TypeScript más sólidos para JavaScript en 2026 son JSDoc con // @ts-check, ReScript y Flow: uno te ofrece verificación de tipos sin ningún paso de compilación, otro te proporciona garantías más robustas que TypeScript, y el último es un verificador heredado que solo adoptarías para mantener código existente. Todo lo demás que suele aparecer en los resúmenes de “alternativas a TypeScript” (Deno, Dart, Kotlin/JS) es un entorno de ejecución o un lenguaje multiplataforma, no un sistema de tipos superpuesto sobre JavaScript.

Este es un análisis comparativo para desarrolladores que ya conocen TypeScript y quieren entender las compensaciones de forma directa: lenguaje versus verificador, con o sin paso de compilación, solidez frente al modelo intencionalmente no sólido de TypeScript, y el estado actual del ecosistema.

Las tres alternativas reales a TypeScript en 2026

Un auténtico “sistema de tipos para JavaScript” o bien verifica tipos en el código fuente JavaScript (un verificador o una capa de anotaciones), o compila un lenguaje tipado a JavaScript. Esa definición incluye JSDoc con @ts-check, ReScript y Flow. Excluye a Deno (un entorno de ejecución que, por casualidad, ejecuta TypeScript), y a Dart y Kotlin/JS (lenguajes independientes que tienen a JavaScript como uno de varios backends de compilación). Estos merecen conocerse, pero responden a una pregunta diferente.

Como contexto de referencia: a mediados de 2026, TypeScript 7.0 es la versión estable actual. Se lanzó el 8 de julio de 2026 como una reescritura nativa del compilador en Go, que según Microsoft es típicamente entre 8 y 12 veces más rápida que TypeScript 6.0 en compilaciones completas. TypeScript 6.0 fue la última versión construida sobre la antigua base de código en JavaScript, cuyo comportamiento de verificación de tipos preserva la versión 7.0. Queda una brecha pendiente: la versión 7.0 se lanza sin una API programática estable, por lo que la verificación de tipos en plantillas de Vue, Svelte y Angular debe esperar a TypeScript 7.1, prevista para alrededor de octubre de 2026. Ten esto en cuenta: afecta a lo que se mantiene vigente para JSDoc, como se explica más adelante.

JSDoc + @ts-check: el sistema de tipos de TypeScript sin el paso de compilación

Qué es: El tipado basado en JSDoc permite anotar archivos .js planos con comentarios estructurados y verificar los tipos usando exactamente el mismo motor que TypeScript: el servicio de lenguaje de TypeScript. Esto es distinto de JSDoc como generador de documentación; aquí las anotaciones impulsan la verificación de tipos. El manual de TypeScript documenta --checkJs como el indicador que reporta errores en archivos .js, disponible desde TypeScript 2.3.

Cómo adoptarlo: Añade un único comentario al inicio de un archivo, o activa dos indicadores en tsconfig para todo el proyecto. La documentación de JavaScript de VS Code describe // @ts-check como la forma de probar la verificación en unos pocos archivos sin habilitarla en todo el proyecto.

// @ts-check

/**
 * @typedef {{ id: number, name: string }} User
 */

/**
 * @param {User} user
 * @returns {string}
 */
function greet(user) {
  return `Hi, ${user.name}`;
}

Para un proyecto completo, omite el comentario por archivo:

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true
  }
}

Dado que los tipos JSDoc son comentarios que se eliminan, el archivo se ejecuta como JavaScript estándar en cualquier navegador o entorno de ejecución sin ningún paso de compilación; esta es también la razón por la que puedes adoptarlo archivo por archivo. La compensación: heredas el modelo de TypeScript exactamente, incluyendo su falta de solidez deliberada, y la sintaxis de anotaciones es más verbosa que en .ts. Una nota relevante para la era de la versión 7.0: Microsoft reescribió la verificación de tipos de JavaScript desde cero para TypeScript 7.0 y eliminó algunas etiquetas de uso menos frecuente, por lo que TypeScript 7.0 no reconoce las etiquetas @enum ni @constructor.

Cuándo elegirlo: Cuando quieres seguridad de tipos incremental en una base de código JavaScript existente, o en una biblioteca que distribuye JS plano, y no quieres un paso de compilación en medio.

ReScript: tipos sólidos, nominales y completamente inferidos

Qué es: ReScript es un lenguaje independiente que compila a JavaScript, no una capa de anotaciones, con un sistema de tipos heredado de OCaml. El sistema de tipos de TypeScript es intencionalmente no sólido: acepta algunos programas incorrectos para mantener la compatibilidad con la semántica en tiempo de ejecución de JavaScript. Esa es precisamente la brecha que ReScript cierra: es completamente inferido y, como describe el propio proyecto, no tiene any, ni tipos mágicos, ni undefined inesperados. A diferencia del tipado estructural de TypeScript, donde cualquier objeto con la forma correcta satisface un tipo, los registros y variantes de ReScript son nominales, por lo que dos tipos estructuralmente idénticos no son intercambiables a menos que se declare explícitamente.

Cómo adoptarlo: Instala el compilador y configura rescript.json, el único archivo de compilación obligatorio para un proyecto ReScript (era bsconfig.json en versiones anteriores a ReScript 11). ReScript 12, lanzado el 25 de noviembre de 2025, elimina completamente el soporte para bsconfig.json y establece los módulos ES como salida predeterminada.

{
  "name": "my-app",
  "sources": { "dir": "src", "subdirs": true },
  "package-specs": { "module": "esmodule", "in-source": true },
  "suffix": ".res.js"
}

Puedes elegir libremente el sufijo de los archivos JS generados; el equipo recomienda .res.js o .res.mjs, que es también lo que usan las plantillas oficiales de create-rescript-app. Un módulo mínimo:

let add = (a: int, b: int): int => a + b
let result = add(1, 2)
Console.log(result)

El coste es real: es un lenguaje diferente con su propia sintaxis, debes escribir bindings de interoperabilidad para consumir bibliotecas de JavaScript, y el ecosistema es mucho más pequeño que el de TypeScript. Sin embargo, ReScript fue diseñado pensando en la adopción gradual: si en algún momento quieres volver a JavaScript plano, eliminas los archivos fuente y conservas la salida JavaScript limpia.

Cuándo elegirlo: En un proyecto nuevo donde quieres las garantías de tipos más sólidas posibles y estás dispuesto a comprometerte con un lenguaje, no solo con anotaciones.

Flow: todavía presente, ampliamente superado

Qué es: Flow es un verificador de tipos estático de código abierto para JavaScript, desarrollado por Facebook/Meta y escrito en OCaml. Al igual que Flow, ReScript desciende de OCaml, pero ambos se encuentran ahora en extremos opuestos en cuanto a adopción. Flow es un verificador, no un lenguaje: anotas archivos .js, los marcas con // @flow y eliminas los tipos con Babel en tiempo de compilación.

// @flow
function add(a: number, b: number): number {
  return a + b;
}

Realidad de la adopción en 2026: Flow sigue en producción dentro de Meta en millones de archivos de JavaScript y React, pero su ecosistema externo se ha contraído notablemente: menos definiciones de bibliotecas, menos tutoriales y herramientas más limitadas que TypeScript. La migración de proyectos importantes relacionados con Meta desde Flow hacia TypeScript se ha planteado en discusiones de la comunidad, aunque ninguna fuente primaria confirma un plan definitivo. Considera desactualizadas las comparaciones antiguas que afirman que “Flow tiene un futuro brillante”; el impulso se trasladó a TypeScript hace años.

Cuándo elegirlo: En la práctica, solo cuando estás manteniendo una base de código Flow existente. Para cualquier proyecto nuevo, las otras dos opciones son apuestas más sólidas.

Veredicto: adapta la herramienta a la situación

Elige JSDoc con @ts-check cuando quieras tipado incremental sin ninguna herramienta de compilación y compatibilidad total con JavaScript plano. Es la respuesta más infrautilizada y más práctica, ya que es el propio verificador de TypeScript apuntando a archivos .js. Elige ReScript cuando estés empezando desde cero y quieras la máxima solidez de tipos, y aceptes un lenguaje independiente y bindings de interoperabilidad como el precio a pagar. Mantén Flow solo para conservar código ya escrito en él. Si hoy quieres seguridad de tipos sin abandonar JavaScript, añade // @ts-check a un archivo y observa cómo emergen los errores.

Preguntas Frecuentes

¿Se puede usar la verificación de tipos de JSDoc sin instalar TypeScript como dependencia?

Editores como VS Code incluyen el servicio de lenguaje de TypeScript de forma integrada, por lo que añadir // @ts-check a un archivo .js te proporciona verificación de tipos sin ningún npm install. Para ejecutar la misma verificación en la línea de comandos o en CI, instala el paquete typescript y ejecuta tsc con allowJs y checkJs habilitados. Los tipos permanecen en los comentarios JSDoc, por lo que en ningún caso se añade nada al JavaScript que distribuyes.

¿Cuál es la diferencia entre el tipado estructural de TypeScript y el tipado nominal de ReScript?

El tipado estructural, utilizado por TypeScript, trata cualquier objeto con la forma correcta como satisfactor de un tipo, por lo que dos tipos no relacionados con campos idénticos son intercambiables. Los registros y variantes de ReScript son nominales, lo que significa que dos tipos estructuralmente idénticos se tratan como distintos a menos que declares explícitamente una relación entre ellos. El tipado nominal previene la sustitución accidental de tipos con apariencia similar, lo que explica en parte por qué el sistema de ReScript es sólido donde el de TypeScript es intencionalmente no sólido.

¿Por qué Deno no se considera una alternativa a TypeScript en esta comparativa?

Deno es un entorno de ejecución de JavaScript y TypeScript, no un sistema de tipos superpuesto sobre JavaScript. Ejecuta TypeScript directamente al incluir el compilador de TypeScript, por lo que depende de TypeScript en lugar de reemplazarlo. Una alternativa genuina debe o bien verificar tipos en el código fuente JavaScript, o bien compilar un lenguaje tipado a JavaScript. El mismo razonamiento excluye a Dart y Kotlin/JS, que son lenguajes independientes que tienen a JavaScript como uno de varios backends de compilación.

¿La migración a TypeScript 7.0 rompe los proyectos JavaScript tipados con JSDoc existentes?

En su mayor parte no, pero TypeScript 7.0 basado en Go reescribió la verificación de tipos de JavaScript desde cero y eliminó algunas etiquetas JSDoc de uso menos frecuente, concretamente @enum y @constructor, que la versión 7.0 ya no reconoce. Los proyectos que dependen de esas etiquetas deben migrarlas a patrones compatibles. Las etiquetas comunes como @param, @returns, @typedef y @template siguen funcionando, por lo que la mayoría de las bases de código tipadas con JSDoc se mantienen sin cambios. TypeScript 7.0 es la versión estable desde julio de 2026, así que ejecuta tu proyecto contra ella para ver exactamente qué diferencias hay.