.NET 11 Vista Previa 1: Grandes logros de tiempo de ejecución, preguntas más grandes sobre dirección

TL;DR

• Async pasa al tiempo de ejecución: más rápido, más optimizado y más fácil de depurar. Buenas noticias para nuestros productos universales.
• CoreCLR es compatible con WASM: sustituye a Mono, por lo que el código .NET compilado en el navegador debería ejecutarse notablemente más rápido.
• Compresión nativa Zstandard: estamos estudiando su adopción en el fondo de IronZIP.

Microsoft ha lanzado oficialmente .NET 11 Preview 1, el primer hito en el ciclo de desarrollo de la próxima versión con soporte técnico estándar, prevista para noviembre de 2026.

Asíncrono a nivel de tiempo de ejecución: el gran cambio silencioso

Una de las actualizaciones más importantes de la Preview 1 es que el seguimiento asíncrono se está integrando más profundamente en el propio tiempo de ejecución, en lugar de ser gestionado íntegramente por el compilador.

Para contextualizar, la programación asíncrona es el patrón que permite a las aplicaciones ejecutar tareas en fragmentos sin bloqueo, de modo que el hilo completo no se congele mientras espera una llamada de red, la lectura de un archivo o una respuesta de la base de datos. Es fundamental para el desarrollo moderno de .NET. La mayoría de las API, los servicios y las cargas de trabajo basadas en la interfaz de usuario dependen en gran medida de ello.

Al acercar la coordinación asíncrona a la capa de tiempo de ejecución, Microsoft puede abordar estos dos puntos débiles a la vez:

Depuración: flujos asíncronos reconstruidos. El depurador debería ser finalmente capaz de rastrear las rutas de ejecución a través de los "await", restaurando el contexto que actualmente se pierde.

Rendimiento: Menor sobrecarga de coordinación. La optimización a nivel de tiempo de ejecución puede ser más agresiva que las máquinas de estados generadas por el compilador por sí solas, lo que reduce el coste por tarea.

En el caso de los servicios distribuidos, las API nativas de la nube y las aplicaciones de interfaz de usuario, esto podría traducirse en mejoras cuantificables en todos los ámbitos.

CoreCLR llega a WebAssembly

Hasta ahora, las aplicaciones .NET compiladas para WebAssembly dependían de Mono, el antiguo entorno de ejecución diseñado originalmente para la compatibilidad multiplataforma. Mono funciona, pero tiene límites de rendimiento bien conocidos y no se beneficia de la misma inversión en optimización que CoreCLR.

Con esta versión preliminar, CoreCLR gana compatibilidad con WebAssembly, lo que aporta varias mejoras concretas: las capacidades JIT mejoran la velocidad de ejecución en tiempo de ejecución. La gestión de la memoria se vuelve más eficiente. Las aplicaciones .NET alojadas en el navegador se acercan cada vez más a la paridad con la ejecución nativa. Para los equipos que crean aplicaciones Blazor WebAssembly o experimentan con cargas de trabajo .NET en el navegador, esta es una de las mejores actualizaciones de toda la versión preliminar.

Esto también es importante para el ecosistema en general. Bibliotecas y herramientas orientadas a WASM, incluyendo el procesamiento de documentos, la representación y la manipulación de datos basados en navegador.

Compresión nativa Zstandard

.NET 11 añade compatibilidad de primer nivel con el algoritmo de compresión Zstandard (Zstd) a través de una nueva implementación ZstandardStream. Zstd se ha convertido en un estándar en los sistemas de alto rendimiento porque ofrece mejores ratios de compresión que Gzip, una descompresión significativamente más rápida y un gran rendimiento para el procesamiento de datos a gran escala.

Para los desarrolladores de bibliotecas y herramientas, esto elimina las complicaciones de los enlaces de terceros. Los productos con gran carga de compresión ahora pueden utilizar Zstd de forma nativa. Es fácil ver que esto resultará útil en el fondo para herramientas como IronZIP o flujos de trabajo similares en los que tanto el rendimiento como el tamaño de los archivos son fundamentales.