Índice de contenidos
Claves de la noticia
- Cloudflare y VoidZero anuncian su colaboración en tsrs, un port experimental del compilador de TypeScript a Rust dentro de Oxc.
- La empresa comunica hasta ocho veces más velocidad que TypeScript 7.0 con igual número de comprobadores; son resultados iniciales del proveedor.
- Su versión WebAssembly permite comprobar y generar código localmente, pero carece de servidor de lenguaje, vigilancia de archivos y ejecución paralela.
Cloudflare ha presentado este 20 de octubre su colaboración con VoidZero y Max Schwenk, de Owner.com, para desarrollar tsrs. La iniciativa lleva el compilador de TypeScript a Rust y busca reducir tanto las esperas como el consumo de memoria. Su interés va más allá del rendimiento: la documentación permite delimitar qué parte de una herramienta de desarrollo puede trasladarse hoy al navegador.
Otro motor para el mismo TypeScript
El anuncio de Cloudflare sitúa el proyecto en Oxc y describe una colaboración estrecha con el equipo de TypeScript. No anuncia un lenguaje con reglas nuevas. La intención es seguir las decisiones del proyecto original y devolver mejoras cuando sea posible. Tampoco significa que tsrs nazca hoy: la novedad es el respaldo y el trabajo conjunto anunciados, sobre un port que ya existía.
El repositorio de Oxc identifica una implementación en Rust y fija como objetivo una versión estable plenamente conforme con TypeScript 7.1. También declara licencia Apache 2.0 y aclara que no está afiliado ni respaldado por Microsoft. Colaborar con sus ingenieros y convertirse en el compilador oficial son situaciones distintas. La versión que puede probarse sigue siendo experimental.
El antecedente está fechado: el 11 de marzo de 2025, Anders Hejlsberg explicó el port nativo de Microsoft a Go. Aquella transición buscaba acelerar la comprobación y los servicios del editor. tsrs parte de esa implementación, según su documento de compatibilidad; no reescribe las aplicaciones del usuario en Rust. Quien desarrolla una web continúa escribiendo TypeScript.
La comparación necesita fijar los comprobadores
Cloudflare comunica hasta ocho veces más velocidad y alrededor de un 70 % menos de memoria frente a TypeScript 7.0 con el mismo número de trabajadores de comprobación. Son mediciones iniciales de la empresa, no una prueba independiente. El propio anuncio señala que TypeScript 7.1 beta ya mejora a 7.0. Por tanto, el resultado frente a una versión anterior no describe automáticamente la ventaja frente a la más reciente.
La guía de uso explica por qué importa esa condición: tsrs ajusta por defecto los comprobadores a los recursos de la máquina y al tamaño del programa. Más hilos pueden acelerar el trabajo a costa de memoria. Comparar los valores predeterminados sin registrar cuántos hilos trabajaron puede atribuir al port una diferencia que también procede de la configuración.
Una evaluación útil debe conservar el mismo proyecto y su configuración, fijar la revisión de TypeScript y el número de comprobadores, y separar la primera ejecución de las siguientes. La guía ofrece --extendedDiagnostics para obtener tiempos y contadores. Es una propuesta de método, no un ensayo realizado aquí. Como mostró el caso de Headstart y su fallo incremental, una mejora en una construcción limpia no garantiza el mismo resultado al editar y recompilar.
El navegador conserva el análisis, pierde tres capacidades
El paquete @tsrs/wasm utiliza el comprobador Rust compilado a WebAssembly. Puede trabajar con archivos en memoria y emitir JavaScript, declaraciones y mapas de fuentes. Su documentación distingue esas operaciones de las funciones disponibles en la ejecución nativa. El contraste permite evitar una confusión: ejecutar el compilador localmente no equivale a trasladar un entorno de desarrollo entero.
| Función | Nativo | Wasm |
|---|---|---|
| Vigilar cambios, watch | Sí | No |
| Servidor de lenguaje, LSP | Sí | No |
| Varios comprobadores | Sí | Un hilo |
La conclusión del cruce documental es concreta: el port al navegador conserva la comprobación y la emisión, pero no el servidor de lenguaje, la vigilancia ni el paralelismo. Un editor web deberá resolver esas necesidades mediante su integración. Además, la aplicación debe crear un Web Worker para no bloquear la interfaz y aportar los archivos del proyecto y las declaraciones de sus dependencias.
Wasm también impone un máximo de 4 GiB de memoria lineal por instancia, que el entorno puede reducir. Por eso las cifras nativas no permiten prometer el mismo comportamiento en cualquier navegador. Para un equipo español que valore un editor educativo local, la oportunidad es comprobar ejemplos sin enviar cada cambio a un servidor; para un repositorio grande, el tamaño y las dependencias siguen condicionando el diseño.
Conformidad medida frente a una revisión concreta
El documento de compatibilidad registra coincidencia en 13.458 de 13.462 referencias de errores y atribuye las cuatro diferencias al arnés de pruebas. Un cálculo directo, cuatro dividido entre 13.462 y multiplicado por cien, da aproximadamente un 0,030 % de referencias no coincidentes. No es una tasa de fallos en aplicaciones reales ni permite proclamar compatibilidad universal.
La comparación se hace contra una revisión fijada de TypeScript 7.1 en desarrollo. El proyecto considera un fallo cualquier divergencia en mensajes, orden o códigos de salida respecto a esa referencia, aunque el resultado parezca mejor. Esa exigencia explica por qué la estabilidad no se deduce solo de completar una batería de pruebas.
Para adoptar tsrs, la decisión debe basarse en dos resultados del mismo código: qué diagnósticos produce y cuánto cuesta obtenerlos. El balance de optimización del compilador de Rust ya ilustraba otra distinción pertinente: acelerar la herramienta no acelera por sí mismo la aplicación generada. Aquí el beneficio buscado es reducir el coste de verificar y construir software, conservando sus reglas.
Imagen: ilustración conceptual generada con IA para Tecnología Today; no representa una instalación real de Cloudflare ni una captura de tsrs.
