Microsoft fusionó windows reactor en windows-rs, una biblioteca que lleva un modelo de componentes similar a React al desarrollo nativo de Windows con Rust, con promesas de menor tamaño, mejor arranque y una experiencia moderna para WinUI 3.
***
- windows-reactor ofrece UI declarativa sin macros, hooks, componentes de función, temas, accesibilidad y más de 55 widgets para WinUI 3.
- Los benchmarks iniciales mostraron ventajas de Rust frente a C#, aunque varios desarrolladores cuestionaron las cifras de AOT y Microsoft dijo que publicará números actualizados.
- El proyecto también impulsó mejoras en windows-rs, windows-bindgen, windows-reference y windows-time, con impacto más allá de las interfaces gráficas.
Microsoft sumó una pieza relevante a su ecosistema de desarrollo para Windows con la fusión de windows reactor en el repositorio windows-rs. La propuesta, presentada por Kenny Kerr el 28 de mayo de 2026, busca que los desarrolladores de Rust creen experiencias nativas, eficientes y modernas sobre WinUI 3.
El movimiento llega en un momento de creciente interés por Rust en entornos de alto rendimiento. Aunque el lenguaje suele asociarse con infraestructura, seguridad, blockchain y sistemas críticos, Microsoft lo está empujando también hacia aplicaciones de escritorio. En este caso, el foco no está en reemplazar Windows, sino en ofrecer una forma más liviana de construir interfaces nativas.
La biblioteca, llamada windows-reactor, adopta un modelo de componentes similar a React. Su objetivo es permitir que la interfaz se exprese como una función del estado, pero sin depender de macros. Esa decisión apunta a una experiencia más explícita para quienes ya trabajan con el sistema de tipos de Rust.
un modelo inspirado en react, pero para winui 3 y rust
La descripción del proyecto destaca una UI declarativa basada en una DSL de constructores e hijos organizados mediante tuplas. También incorpora componentes de función, props tipadas, propagación de contexto y límites de error. El paquete incluye hooks como use_state, use_reducer, use_effect, use_context, use_memo, use_callback y use_resource.
El paralelismo con React resulta evidente, pero el entorno cambia por completo. En lugar de aplicaciones web, la biblioteca apunta a escritorio nativo en Windows. Para quienes vienen del mundo de front-end, esto puede hacer más familiar el desarrollo con WinUI 3, sin abandonar las garantías de compilación de Rust.
La primera versión integrada también llega con más de 55 widgets. Entre ellos figuran Button, TextBlock, NavigationView y Grid. Además, incluye listas virtualizadas como ListView, GridView y FlipView, con renderizado de filas mediante plantillas.
El soporte asincrónico aparece mediante use_resource y use_mutation. Estos hooks permiten cargar datos en segundo plano. El proyecto también incluye cambio de tema claro y oscuro en tiempo de ejecución mediante enlaces de pincel ThemeRef.
La accesibilidad forma parte del paquete inicial. La biblioteca incorpora modificadores de propiedades de automatización, aceleradores de teclado y tooltips. Según la descripción publicada en GitHub, la huella de despliegue apunta a un único binario de unos 3 MB, sin framework de runtime adicional que distribuir.
requisitos, ejemplos y primeros pasos
Para utilizar windows-reactor se requiere Windows 10 versión 1809 o superior, o Windows 11. También hace falta Windows App SDK Runtime 2.0.1 o posterior. La instalación inicial consiste en añadir la dependencia windows-reactor desde el repositorio de Microsoft en el archivo Cargo.toml.
El ejemplo mínimo presentado por Kerr crea una aplicación con título “sample”. En ella, un botón incrementa un contador mediante use_state, y un text_block muestra el valor actualizado con tamaño de fuente de 18 y estilo en negrita. Es un ejemplo simple, pero muestra la intención del proyecto: hacer que la UI se lea como una composición de funciones.
El repositorio también incluye ejemplos para explorar la biblioteca. Los comandos publicados permiten ejecutar una galería con cargo run -p gallery, además de ejemplos como solitaire y calculator. Esto sugiere que Microsoft quiere mostrar casos más completos que un contador básico.
El pull request fue fusionado en master el 28 de mayo de 2026 con el commit 65066a7. Antes de la fusión, Kerr realizó force-push sobre la rama reactor, primero de 5474ac5 a 766fba6, y luego de 766fba6 a a213f1d. La rama fue eliminada después de la integración, y 29 verificaciones pasaron correctamente.
benchmarks iniciales y debate por las cifras
Uno de los puntos más llamativos fue la tabla de rendimiento. Kerr comparó una app de galería equivalente de C# Reactor con la implementación en Rust, usando mediciones del 27 de mayo de 2026. Los resultados publicados favorecieron a Rust en todas las métricas reportadas.
| Métrica | Rust | C# JIT | C# PublishAOT |
|---|---|---|---|
| Tiempo de compilación limpia | 11,0 s | 23,9 s | 50,8 s |
| Tamaño de despliegue | 3,34 MB | 128 MB | 163 MB |
| Tiempo hasta la primera ventana | 160 ms | 465 ms | 364 ms |
| Working set tras estabilizarse | 109,5 MB | 162,6 MB | 128,4 MB |
| Memoria privada | 101,0 MB | 121,0 MB | 117,3 MB |
| Tiempo de CPU en inicio y estabilización | 594 ms | 1.063 ms | 906 ms |
| Reconciliación de 4.900 celdas al 10% | 3,1 ms | 27,0 ms | 29,4 ms |
Las cifras abrieron una discusión inmediata. El usuario dongle-the-gadget afirmó que los números de C# AOT no tenían sentido para él. Dijo que su aplicación WinUI 3 AOT no trivial, compilada para tres arquitecturas, tarda 6 minutos en compilarse y ocupa unos 50 MB en disco.
Ese comentario sugirió que la versión AOT comparada podría haber sido self-contained, y no realmente compilada con AOT. SaverinOnRails coincidió en que las estadísticas eran “graciosas”. Aun así, señaló que Rust superaría a C#, aunque no necesariamente por un margen tan amplio.
Kerr respondió que ya había conversaciones internas sobre el tamaño de despliegue tras la publicación de la tabla. También matizó la discusión. Indicó que los números reales no eran tan importantes como el hecho de que todos se midieron en la misma máquina, a la que calificó como vieja.
El 29 de mayo, David Fowler intervino para decir que el tema se estaba arreglando. Según explicó, Microsoft trabaja con el equipo de Reactor para publicar números actualizados. Esto deja los benchmarks iniciales como una señal interesante, pero todavía sujeta a revisión.
preguntas sobre memoización, multiplataforma y el futuro del proyecto
La conversación también tocó temas de diseño. Tusharsnx preguntó si windows-reactor seguirá el mismo “viaje salvaje” de React, desde use_memo y use_callback hasta la memoización automática con React Compiler. La pregunta apunta a un tema central para cualquier framework declarativo: cuándo optimizar y cuánto debe automatizarse.
Kerr respondió que el sistema de tipos de Rust elimina algunas clases de errores que React Compiler detecta, como usos después de mover valores o carreras de datos. También señaló que el reconciliador ya omite subárboles sin cambios mediante un diff basado en PartialEq. Aun así, dejó abierta la posibilidad de explorar más automatización en tiempo de compilación cuando la biblioteca madure.
Nicoburns planteó otra pregunta relevante. Quería saber si existe una API para usar los widgets sin la capa de reactividad. Su interés era construir UI multiplataforma, donde un framework más amplio controle la reactividad y la gestión de estado.
Kerr contestó que windows-reactor está construido sobre windows-bindgen. Ese componente proporciona los bindings para las APIs utilizadas en todo lo visible. La respuesta sugiere que las capas inferiores podrían servir como base para otros enfoques, aunque la biblioteca presentada mantiene su foco en WinUI 3.
El pull request también quedó vinculado a discusiones más amplias. Scottj1s lo mencionó en una propuesta sobre soporte de Rust para WinUI 3. Mominshaikhdev lo conectó con otra propuesta para crear un framework nativo de Windows de próxima generación, con UI declarativa moderna y automatización de IA.
mejoras técnicas más allá de la interfaz
Kerr agradeció especialmente a Chris Anderson y Rafael Rivera. Describió a Anderson como quien puso en marcha el proyecto y lo convenció de darle otra oportunidad a WinUI. También recordó que Anderson está detrás de Reactor para C#.
Sobre Rivera, Kerr destacó su conocimiento de los internos de Windows y WinUI. Ese reconocimiento muestra que windows-reactor no es solo una capa superficial de componentes. El proyecto requirió trabajo profundo en generación de código, bindings y ergonomía del ecosistema Rust para Windows.
La integración se apoya en una montaña de mejoras dentro de windows-rs. En semanas recientes, la canalización de bindgen recibió filtrado a nivel de método, listas mixtas de allow y deny, y degradación de vtable. Con esto, windows-reactor puede generar solo la superficie COM exacta que necesita.
También se redujo la generación de código de delegados. Los handlers con retorno void ahora pueden emitir retornos directos S_OK. Además, el registro de eventos acepta closures directamente con un EventRevoker no genérico.
El trabajo incluyó dos nuevos crates. windows-reference permite boxing IReference<T> de sobrecarga cero, usado en Reactor para valores de propiedad anulables. windows-time ofrece conversiones idiomáticas para TimeSpan y DateTime.
El lector de metadatos también se simplificó al fusionar TypeIndex e ItemIndex. El tokenizador cambió al crate quote. Ambas modificaciones reducen el tiempo de compilación de bindgen, según la explicación del proyecto.
Para la comunidad técnica, el valor de windows-reactor podría ir más allá de la UI. Incluso quienes no desarrollen aplicaciones de escritorio podrían beneficiarse de las optimizaciones aplicadas a los crates principales windows-*. En ese sentido, la biblioteca funciona como producto y como banco de pruebas para mejorar Rust en Windows.
La noticia también encaja con una tendencia más amplia. Rust sigue ganando espacios donde la eficiencia, la seguridad de memoria y el control del binario importan. Para desarrolladores de blockchain, infraestructura e IA, este tipo de avance muestra cómo el lenguaje se expande hacia capas de producto final, no solo hacia servicios de bajo nivel.
ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.
Suscríbete a nuestro boletín
Artículos Relacionados
Empresas
Microsoft enfrenta indignación por amenaza legal contra investigador de seguridad
Bitcoin
Ejecutivo cripto emite alerta sobre Strategy: El bucle de capital con Bitcoin se está rompiendo
Bancos y Pagos
Stablecoin USAT de Tether crece más de 500% en un mes
Empresas