A finales de marzo de 2025, Microsoft anunció algo que sonaba casi provocador: iba a portar el compilador de TypeScript, escrito durante años en el propio TypeScript, a Go. El proyecto se llamó Corsa, y la promesa era brutal, una mejora de rendimiento de un orden de magnitud en algunos de los proyectos TypeScript más grandes del mundo.
Aquel anuncio generó bastante ruido y unas cuantas dudas razonables: ¿por qué abandonar TypeScript para escribir el propio TypeScript? Año y medio después, con TypeScript 7 ya estable, tenemos los números encima de la mesa. Y los benchmarks hablan solos.
Qué significa realmente ese «10x»
La frase «10 veces más rápido» describe la magnitud de la mejora que Microsoft ha demostrado, no una garantía de que cualquier proyecto vaya a multiplicar por diez su velocidad de la noche a la mañana. El resultado depende del tamaño del proyecto, del tipo de trabajo que se esté haciendo y del hardware disponible. Algunos proyectos verán una mejora de 5x, otros de 8x, 10x, 12x o incluso más.
Esto no convierte a ningún desarrollador en un «programador 10x» por arte de magia, pero sí significa que compilar un proyecto TypeScript, cargarlo en el editor y recibir diagnósticos puede volverse dramáticamente más rápido tras pasar al toolchain nativo. Y «dramáticamente» no es ninguna exageración aquí, como veremos en los benchmarks.
Dicho esto, hay matices importantes antes de lanzarse a migrar una aplicación empresarial entera a TypeScript 7.
Cómo se llegó hasta aquí
El anuncio de Project Corsa desató las preguntas típicas: ¿por qué no Rust? ¿Por qué no C#? ¿Microsoft está abandonando sus propias tecnologías? La explicación real es bastante menos dramática que esas preguntas: fue una decisión de ingeniería pragmática, centrada en rendimiento, compatibilidad y mantenibilidad.
Una evaluación a fondo, no una elección al azar
El equipo de TypeScript no eligió Go tras una comparación superficial. Evaluó varios lenguajes, construyó prototipos con distintas representaciones de datos, investigó arquitecturas híbridas y estudió herramientas nativas ya existentes para TypeScript, como swc, oxc y esbuild.
Una opción sobre la mesa era mover solo los componentes críticos en rendimiento a un lenguaje nativo, dejando los algoritmos de comprobación de tipos en JavaScript. Al final, el equipo concluyó que un port nativo completo daría más beneficios. Eso no convierte a Go en el mejor lenguaje posible para escribir un compilador en abstracto, varios lenguajes podrían haber servido igual de bien para una reescritura desde cero. Go simplemente encajó mejor con los requisitos concretos de este proyecto.
La prioridad era la compatibilidad, no la velocidad pura
El requisito más importante no era el rendimiento en bruto, era la compatibilidad. Microsoft espera que la implementación existente y la nativa convivan durante un tiempo, y durante ese periodo los fixes y las nuevas funciones tendrán que moverse entre ambas bases de código. Un lenguaje que permita una estructura de programa parecida hace ese trabajo mucho más llevadero.
Un lenguaje que obligara al equipo a replantear ownership, mutación, polimorfismo, laziness o las estructuras de datos fundamentales podría dar como resultado un compilador nuevo muy elegante, pero ya no sería un port directo. Y da la casualidad de que el Go idiomático se parece bastante al estilo orientado a funciones y datos que ya usaba el compilador de TypeScript.
¿Por qué no Rust?
Rust podría haber sido una opción muy sólida para un compilador diseñado desde cero, pero ese no era el objetivo del equipo. El compilador existente depende mucho de la gestión automática de memoria y de estructuras de datos cíclicas. El modelo de ownership de Rust habría obligado a rediseñar esas estructuras y a repensar partes importantes de la implementación. En palabras del propio Anders Hejlsberg, reescribir el compilador en Rust quizá era posible, pero portarlo fielmente no era práctico.
¿Por qué no C#?
También se evaluó C#, y esto tiene su miga: C# es el lenguaje principal de Microsoft, y Hejlsberg es su diseñador original. Aun así, describió C# como un candidato posible cuyo modelo orientado a objetos y de más alto nivel no encajaba tan bien con el compilador existente. La base de código de TypeScript sigue un estilo más procedural, construido alrededor de funciones y estructuras de datos. De hecho, su compilador principal ni siquiera usa clases.
Hejlsberg también señaló que C# no tenía una historia de generación de código nativo tan madura como las alternativas que estaban valorando. Go, en cambio, llevaba más de una década desplegándose de forma nativa en todas las plataformas principales y encajaba mejor con el estilo de programación que ya tenía el compilador.
Por qué Go encajaba con el compilador existente
Go ofrece recolección de basura, soporta estructuras de datos cíclicas y con muchos punteros, da control sobre el layout de memoria y las asignaciones, y permite concurrencia con memoria compartida. Es además un lenguaje procedural, construido principalmente alrededor de funciones y datos. No tiene clases tradicionales ni herencia, pero sí interfaces, funciones de primera clase, closures y otros patrones que ya se usaban a fondo en la implementación en JavaScript.
TypeScript hace además una cantidad inusual de procesamiento de grafos, con recorridos ascendentes y descendentes por árboles de nodos polimórficos. Go soporta bien estos patrones, lo que permite que la implementación nativa se mantenga reconocible frente a su equivalente en JavaScript.
Un port, no una simple traducción
Llamar a este trabajo una simple traducción sería quedarse corto. El equipo desarrolló herramientas para convertir parte de la sintaxis TypeScript a Go, pero estructuras importantes, como los nodos del árbol de sintaxis abstracta, los símbolos, los tipos y los datos de flujo de control, necesitaron mucha ingeniería adicional por su cuenta.
La compatibilidad sigue siendo la prioridad. El comportamiento y la salida del compilador nativo se comparan de forma continua con la implementación existente a través de unos 100.000 tests. El objetivo es preservar la semántica de TypeScript, sus diagnósticos y años de optimizaciones cuidadosamente desarrolladas, no reinventar el lenguaje.
De dónde sale el rendimiento
El famoso 10x publicitado viene de dos fuentes principales: ejecución nativa y procesamiento en paralelo.
Ejecución nativa
El código nativo elimina buena parte del overhead de arranque, compilación JIT, asignación de memoria y runtime que arrastra JavaScript. En una demostración, compilar unas 250.000 líneas tardaba alrededor de siete segundos con el compilador existente. La implementación nativa, en un solo hilo, hizo el mismo trabajo en unos dos segundos.
Procesamiento en paralelo
Go permite además que operaciones como el parsing, el binding, la emisión y parte de la comprobación de tipos corran de forma concurrente. Con la paralelización activada, esa misma compilación de 250.000 líneas bajó a menos de un segundo.
En la base de código de Visual Studio Code, mucho más grande, con cerca de 1,5 millones de líneas, el tiempo de compilación pasó de más de un minuto a unos seis segundos. Anders Hejlsberg describió la mejora global como aproximadamente mitad código nativo, mitad paralelismo, aunque el equilibrio exacto depende lógicamente del proyecto y del hardware disponible.
Memoria y proyectos grandes
La gestión de memoria fue otro factor decisivo a la hora de elegir Go. El lenguaje da al equipo control sobre el layout de objetos, campos y asignaciones sin obligar a gestionar la memoria a mano en todo el compilador. Go usa recolección de basura, sí, pero sus inconvenientes habituales pesan menos en la carga de trabajo de TypeScript de lo que cabría esperar.
Las compilaciones por lotes pueden reservar lo que necesitan y terminar antes de que la recolección de basura se convierta en un problema real. En procesos de larga duración, estructuras como los árboles de sintaxis abstracta suelen sobrevivir toda la vida del programa, y el compilador tiene suficiente conocimiento de dominio para elegir buenos momentos para recolectar.
Las cadenas UTF-8 de Go, las operaciones de subcadena sin asignaciones, los layouts de datos compactos y las técnicas de pooling de objetos reducen todavía más la presión sobre la memoria. Esto importa porque los fallos por falta de memoria han sido históricamente una de las categorías de problemas más reportadas al equipo del compilador.
El resultado no es solo un compilador más rápido. Es una herramienta capaz de procesar proyectos que antes rozaban o superaban los límites prácticos de memoria de la implementación en JavaScript.
Los benchmarks
Microsoft publicó estos benchmarks de build completo en el anuncio oficial de TypeScript 7. Ambas versiones se probaron en la misma máquina, con TypeScript 7 usando su configuración por defecto de cuatro workers de comprobación de tipos.
Proyecto | TypeScript 6 | TypeScript 7 | Mejora |
VS Code | 125,7 s | 10,6 s | 11,9x |
Sentry | 139,8 s | 15,7 s | 8,9x |
Bluesky | 24,3 s | 2,8 s | 8,7x |
Playwright | 12,8 s | 1,47 s | 8,7x |
tldraw | 11,2 s | 1,46 s | 7,7x |
La mejora relativa más grande del grupo es la de VS Code, que pasa de 125,7 a 10,6 segundos, un 11,9x. Sentry es el que más tiempo absoluto ahorra, más de dos minutos en una sola ejecución. Y ojo, no son proyectos de juguete montados para hacer quedar bien al compilador nuevo: son bases de código grandes y maduras, con las relaciones de tipos complejas, la estructura de proyecto y los grafos de dependencias que de verdad ponen a prueba a TypeScript.
Conviene interpretar estos resultados con cabeza. Miden el rendimiento del tooling de TypeScript en un entorno de benchmark concreto, no significan que el JavaScript generado por TypeScript 7 vaya a ejecutarse 10 veces más rápido. Los resultados también van a variar según la configuración del proyecto, el hardware, los núcleos de CPU disponibles y cuánto tiempo del pipeline de build se gasta fuera del propio compilador de TypeScript.
Uso de memoria
Proyecto | TypeScript 6 | TypeScript 7 | Diferencia |
VS Code | 5,2 GB | 4,2 GB | -18% |
Sentry | 4,9 GB | 4,6 GB | -6% |
Bluesky | 1,8 GB | 1,3 GB | -26% |
Playwright | 1,0 GB | 0,9 GB | -11% |
tldraw | 0,6 GB | 0,5 GB | -15% |
Las mejoras en memoria son menos espectaculares que las de tiempo de compilación, pero siguen siendo relevantes. Bluesky usa un 26% menos de memoria, y VS Code baja de 5,2 a 4,2 GB. En máquinas de desarrollo o agentes de CI que corren varios jobs a la vez, ahorrarse cientos de megas, o hasta un gigabyte entero, puede notarse bastante.
La variación entre proyectos también tiene su lógica. La ejecución en paralelo necesita algo más de memoria de trabajo, mientras que los layouts de datos compactos de Go, sus cadenas UTF-8, la estrategia de asignación y el pooling de objetos la reducen. El resultado final depende de la forma de cada base de código y de cuánta concurrencia se esté usando.
El precio a pagar: la API de JavaScript
Hay un terreno donde Go plantea un trade-off real: la interoperabilidad con JavaScript. La API actual de TypeScript permite a quien la consume acceder, y a veces modificar, una buena parte del estado interno del compilador directamente dentro del mismo proceso. Esa flexibilidad también ha limitado históricamente la capacidad del equipo para cambiar representaciones internas e introducir nuevas optimizaciones.
La implementación nativa no puede exponer objetos de Go a JavaScript de la misma manera. Por eso TypeScript 7.0 no incluye una API de compilador. Microsoft espera que TypeScript 7.1 traiga una API nueva, diseñada deliberadamente, en lugar de reproducir el acceso sin restricciones a los objetos internos del compilador antiguo.
Las aplicaciones que dependen mucho de la API del compilador de TypeScript o de sus internals no documentados van a tener que adaptarse. Hasta que llegue la nueva API, Microsoft ofrece el paquete de compatibilidad @typescript/typescript6, para que las herramientas puedan seguir usando la API de TypeScript 6 junto al compilador de TypeScript 7.
¿Sigue siendo TypeScript?
Sí. El lenguaje sigue siendo TypeScript, y se sigue escribiendo el mismo código de siempre. Lo que corre por debajo es completamente distinto, pero no hay nada especialmente raro en eso. A fecha de agosto de 2026, TypeScript 7.0 es estable y está disponible a través del paquete estándar typescript. Sigue siendo un port, no un lenguaje nuevo: se sigue escribiendo el mismo TypeScript, mientras que la maquinaria detrás de la compilación, los diagnósticos y el tooling del editor ha cambiado por completo.
La analogía del Fórmula 1
McLaren usó motores Ford-Cosworth durante buena parte del periodo entre 1968 y 1983. Esa alianza ayudó al equipo a ganar su primer Campeonato de Constructores en 1974, junto con los títulos de pilotos de 1974 y 1976. El coche, con todo, seguía siendo un McLaren: el chasis, la aerodinámica, los mandos, la estrategia y la identidad del equipo eran suyos. El motor, la pieza que convertía toda esa ingeniería en movimiento, venía de Ford porque era la herramienta adecuada para ese trabajo. No es que McLaren no pudiera fabricar motores, es que los de Ford eran muchísimo mejores para correr en F1.
TypeScript 7 sigue una lógica parecida. El lenguaje, la sintaxis, el sistema de tipos y la experiencia de desarrollo siguen siendo TypeScript. El motor de debajo cambia porque la implementación nativa en Go encaja mucho mejor con esta carga de trabajo concreta. No es una guerra de lenguajes, ni una rivalidad corporativa, ni una señal de que Microsoft esté abandonando C# por Go. Es, sin más, un equipo de ingeniería eligiendo la herramienta adecuada para un problema concreto.
Grandes empresas ayudaron a probar TypeScript 7
Microsoft no se apoyó solo en su propia batería de tests. Según el anuncio oficial de TypeScript 7, el equipo trabajó con empresas como Bloomberg, Canva, Figma, Google, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel y VoidZero. Equipos internos de Microsoft, como Loop, Office, Power BI, Teams y Xbox, también probaron el compilador contra sus propias bases de código.
Ese testeo expuso a TypeScript 7 a monorepos complejos, pipelines de build a medida, patrones de resolución de módulos poco habituales y cargas de trabajo difíciles de reproducir con tests aislados. Los resultados fueron más allá de los benchmarks controlados: Slack redujo el tiempo de type-checking en CI de unos 7,5 minutos a 1,25 minutos, y reportó una reducción del 40% en el tiempo de la cola de merges. Canva redujo el tiempo hasta mostrar el primer error en el editor de unos 58 segundos a 4,8 segundos.
Ese tipo de feedback importa, porque el rendimiento solo sirve de algo cuando el compilador se mantiene estable y compatible bajo cargas de trabajo reales de producción.
¿Merece la pena actualizar?
La respuesta corta es sí, pero conviene tratarlo como una migración de versión mayor, no como un parche de rendimiento que se instala y ya está.
TypeScript 7 ya está disponible a través del paquete estándar:
npm install --save-dev typescript@7 npx tsc
El flag --save-dev, que también se puede escribir como -D, registra TypeScript 7 como dependencia de desarrollo. Ejecutar npx tsc usa entonces la versión instalada localmente en el proyecto, en vez de tirar de una instalación global.
Funciones clave como el parsing, la comprobación de tipos, la emisión de JavaScript y de declaraciones, el watch mode, la compilación incremental, las referencias de proyecto y el language server están listas para producción. Aun así, el paso a una implementación nativa trae consideraciones de compatibilidad: TypeScript 7.0 no incluye API de compilador, adopta los nuevos valores por defecto y las deprecaciones estrictas de TypeScript 6.0, e incluye diferencias intencionadas en algunos comportamientos de JSDoc y de JavaScript.
Los proyectos que usan TypeScript sobre todo a través de tsc probablemente tendrán el camino de migración más sencillo. Los que importan directamente la API del compilador, dependen de internals no documentados, usan plugins de language service a medida o se apoyan mucho en comportamientos heredados de JavaScript y JSDoc necesitarán pruebas más cuidadosas, o puede que tengan que correr TypeScript 6 y 7 en paralelo durante un tiempo.
Un proceso de evaluación razonable pasa por:
- Ejecutar el build actual con TypeScript 6 y anotar sus diagnósticos, salida, tiempo de ejecución y memoria pico.
- Actualizar el proyecto a TypeScript 7, ejecutar
npx tscy comparar los resultados. - Probar por separado el watch mode, los builds incrementales, las referencias de proyecto y la generación de declaraciones.
- Activar el soporte de TypeScript 7 en el editor y probar navegación, diagnósticos, autocompletado y refactorizaciones.
- Mantener a mano el paquete de compatibilidad con TypeScript 6 para las herramientas que todavía necesiten la API antigua.
TypeScript 7 es, sin duda, el futuro del ecosistema, pero un compilador más rápido solo vale la pena si sigue siendo compatible con los flujos de trabajo construidos alrededor de él. Conviene actualizar con cabeza, probar lo que de verdad necesita cada proyecto y mantener el tooling de compatibilidad donde haga falta, no lanzarse solo porque el titular diga «10 veces más rápido».
Conclusión
Cuando Microsoft anunció Project Corsa, el objetivo de un 10x sonaba tremendamente ambicioso. TypeScript 7 ha convertido esa promesa en resultados medibles: builds más rápidos, menos memoria y una experiencia de desarrollo bastante más ágil.
La lección de fondo es sencilla: las tecnologías son herramientas, no identidades, y la buena ingeniería consiste en elegir la adecuada para cada trabajo. TypeScript se volvió más rápido dejando de estar escrito en TypeScript, y no hay nada malo en eso. Todo lo contrario.
Vía: Dev.to
Imagen: Pexels / O?uzhan eken