TypeScript 10 veces más rápido
(devblogs.microsoft.com)- Microsoft anunció una mejora de rendimiento de 10x en TypeScript mediante la portación nativa del compilador y las herramientas
- Gran mejora en el tiempo de inicio del editor, reducción de 10x en el tiempo de build y fuerte disminución del uso de memoria
- Planea lanzar una versión preliminar de
tsca mediados de 2025 y ofrecer builds completos de proyectos y servicio de lenguaje hacia finales de 2025
Antecedentes de la mejora de rendimiento de TypeScript
- El valor central de TypeScript es ofrecer una experiencia de desarrollador sobresaliente
- A medida que crece la base de código, el valor de TypeScript aumenta, pero en proyectos grandes aparecen problemas de rendimiento
- Surgen problemas de tiempos largos de carga y verificación
- Se necesita equilibrio entre un inicio rápido del editor y el análisis de toda la base de código
- Las funciones basadas en IA requieren información semántica rápida y precisa
- Aumenta la necesidad de verificar el estado de la base de código mediante builds por línea de comandos
Plan para la portación nativa
- Comenzó el trabajo de portación nativa del compilador y las herramientas de TypeScript
- Objetivos de mejora de rendimiento:
- Reducir drásticamente el tiempo de inicio del editor
- Reducir el tiempo de build hasta 10x
- Disminuir el uso de memoria
- Mediados de 2025: planean lanzar una versión preliminar de
tsccon verificación de tipos por línea de comandos - Finales de 2025: planean ofrecer builds completos de proyectos y servicios de lenguaje
Ejecución y pruebas del código
- El código se puede compilar y ejecutar desde el repositorio de código TypeScript Go
- El repositorio incluye instrucciones para compilar y ejecutar
tscy el servidor de lenguaje - Habrá actualizaciones periódicas sobre nuevas funciones
¿Qué tan rápido se volvió?
- Al probar el tiempo de build del proyecto actual de TypeScript en varias bases de código populares, aparecieron estas mejoras de rendimiento:
- El proyecto VS Code, con aproximadamente 1.5 millones de líneas de código, pasó de 77.8 segundos a 7.5 segundos, cerca de 10.4x más rápido
- El proyecto Playwright, con aproximadamente 350 mil líneas de código, pasó de 11.1 segundos a 1.1 segundos, una mejora de alrededor de 10.1x
- El proyecto TypeORM, con aproximadamente 270 mil líneas de código, pasó de 17.5 segundos a 1.3 segundos, una mejora de alrededor de 13.5x
- El proyecto date-fns, con aproximadamente 100 mil líneas de código, pasó de 6.5 segundos a 0.7 segundos, una mejora de alrededor de 9.5x
- El proyecto tRPC, con aproximadamente 18 mil líneas de código, pasó de 5.5 segundos a 0.6 segundos, una mejora de alrededor de 9.1x
- El proyecto rxjs, con aproximadamente 2 mil líneas de código, pasó de 1.1 segundos a 0.1 segundos, una mejora de alrededor de 11x
- Aunque todavía no está completo en funcionalidades, se espera una mejora de rendimiento de más de 10x en la mayoría de las bases de código
- Ahora será posible una verificación de tipos y navegación de código más rápidas
- También será posible la integración con herramientas de IA y el soporte para refactorización avanzada
Mejora del rendimiento del editor
- Mejora en la velocidad de carga y respuesta del editor
- Tiempo de carga tomando como referencia la base de código de Visual Studio Code:
- Actual: 9.6 segundos → versión nativa: 1.2 segundos (aprox. 8x de mejora)
- El uso de memoria también se reduce en alrededor de 50%
- Se espera una mejora de rendimiento en tareas del servicio de lenguaje (autocompletado, información rápida, ir a definición, etc.)
- La migración se está realizando con base en el protocolo Language Server Protocol (LSP)
Hoja de ruta de versiones
- Ya se lanzó TypeScript 5.8 y TypeScript 5.9 llegará pronto
- La base de código de TypeScript basada en JS seguirá desarrollándose en la versión 6.x
- Cuando la base de código nativa se estabilice, se lanzará como TypeScript 7.0
- TypeScript 6 → versión basada en JS
- TypeScript 7 → versión basada en nativo
- Incluso después del lanzamiento de TypeScript 7, la versión 6.x se mantendrá durante cierto tiempo
Próximos pasos
- Planean publicar más información sobre rendimiento, la API del compilador y LSP
- Se pueden consultar preguntas frecuentes en el GitHub FAQ
- Hay un AMA programado para el 13 de marzo de 2025 en el Discord de la comunidad TypeScript (10 a. m. PDT | 5 p. m. UTC)
24 comentarios
Sentí que mucha gente lo proponía sin pensar en el
structural typing.Reescribirlo en un lenguaje de
nominal typingcomo C# o Rust seguramente no habría sido fácil, porque habría que cambiar demasiadas cosas de la estructura fundamental del proyecto.Entre los lenguajes que adoptan
structural typing, los únicos que podrían dar un mejor rendimiento que una base existente en JS probablemente serían C++ o Go, pero si también se considera la productividad, no hay una alternativa real.Desde hace un tiempo empecé a meterle menos mano a TS, pero viendo noticias así me vuelve a llamar la atención, ¿no?
En
ts, si se abusa deanysalvo en casos realmente inevitables, no es muy distinto de usar vanilla... jajaParece que la polémica está bastante candente, porque Anders Hejlsberg dejó un comentario personalmente.
https://github.com/microsoft/typescript-go/…
Alguien que quisiera que al compilar con TypeScript, el resultado saliera directamente como binario
No sé mucho de frontend... ¿es diferente de
swc?SWC se enfoca en generar código JavaScript compatible, como Babel, e incluso en el bundling; esto, en cambio, se enfoca en convertir código TypeScript a JavaScript o en revisar errores.
Dicen que hay que "comer tu propia comida para perros": usar directamente lo que uno mismo creó. Pero en el caso de un lenguaje, sí da un poco para pensarlo.
En lo personal, como los runtimes de JS en los que se basa TS (p. ej., spidermonkey, v8) en su mayoría están escritos en C++ y no existe un runtime implementado en JS,
y viendo que incluso la compilación de JS -> JS, si se hace con JS puro, es demasiado lenta y por eso todos terminan pasándose a cosas como esbuild,
me hace pensar si en TS realmente hace falta insistir tanto con dogfooding
Me preocupa que más adelante se descuide el mantenimiento de la base de código existente de TypeScript.
¡Es una noticia muy bienvenida! Curiosamente, el lenguaje TypeScript de MS parece tomar muchas decisiones realmente inesperadas, más de lo que uno imaginaría. Desde la perspectiva de MS, al ser casi su primer proyecto de código abierto, también se sintió muy acertada la decisión de complementar JavaScript, a diferencia de Dart de Google, que intentaba reemplazar JS; y ahora también sorprende que, aunque seguramente tenían varios lenguajes propios para elegir en este port nativo, hayan optado por Go de Google.
Vaya, pero ya debía haber algo del lado de deno que hizo un toolchain basado en Rust... ¿de repente ahora es Go?
Parece que te refieres a un runtime como Node, pero aquí se está hablando del compilador del propio lenguaje TS.
Ah, al leer un poco más el artículo, creo que me confundí porque hablaba de que el editor se volvía más rápido y cosas así.
tscse volvió 10 veces más rápido. Es decir, se reduce muchísimo el tiempo de transpilación dets->js.ts, como VSCode, la velocidad mejora mucho. O sea, la lógica que comparte las funciones detsc, como la revisión de sintaxis dets, se volvió más rápida.Eso era lo que decía.
He usado tipos genéricos construidos con recursión y se volvían lentos, así que terminé usando alternativas. Si realmente es 10 veces más rápido, me ilusiona pensar que también podrían mejorar esas partes.
Está interesante el hilo de discusión sobre por qué Go.
https://github.com/microsoft/typescript-go/discussions/411
Y también hay muchas cosas que pensar...
Claro, también entiendo cómo se sienten los desarrolladores de .NET...
Los desarrolladores de .NET y Rust están bastante enojados.
Entiendo lo de .NET, pero me parece que Rust está en una posición similar a la de Go; supongo que los proyectos y bibliotecas de JS relacionados con Go que ya existían también influyeron en la decisión.
No es que el desarrollo del lenguaje C# se haya detenido, pero siento demasiado que los frameworks que usan C# están siendo descuidados.
Escribe en Go~
Tengo muchas expectativas.
Comentarios en Hacker News
tscrápido con Ruststc: descontinuadoezno: sigue en desarrollo activo y no busca una correspondencia 1:1 contsc