Blazor con .NET 10 y .NET 11: qué ha cambiado, qué sigue siendo un problema y cuándo usarlo

Blazor lleva varios años intentando convencer al ecosistema web de que C# puede reemplazar a JavaScript en el frontend. Durante mucho tiempo, la respuesta honesta era siempre un "sí, pero...". Los tiempos de carga de WebAssembly, la falta de madurez del SSR (Server Side Rendering) y un ecosistema de componentes que no terminaba de cuajar ponían el "pero" grande.

Con .NET 10 la cosa cambió de forma importante. Y con lo que ya se sabe de .NET 11 (actualmente en preview, con salida prevista para noviembre de 2026), hay razones reales para tomarse a Blazor en serio de una vez por todas si eres desarrollador .NET, como opción de primera clase para ciertos proyectos.

Y lo de "ciertos" proyectos es la palabra clave aquí. Hay escenarios donde seguir con React o Angular sigue siendo la decisión más razonable. Este artículo va precisamente de eso: de las novedades que importan y su impacto, de lo que sigue sin estar resuelto y de cómo decidir si Blazor encaja (o no) en tu próximo proyecto.

¿Qué es Blazor y por qué sigue en el mapa en 2026?

Blazor es el framework de Microsoft para construir interfaces web interactivas usando C# en lugar de JavaScript. Apareció en 2018 como experimento y llegó a producto oficial con .NET Core 3.1. Desde entonces no ha parado de evolucionar, aunque con algún que otro tropiezo de madurez por el camino, y ahora es claramente la apuesta para desarrollo Web de Microsoft desde hace unos años.

Lo que lo hace diferente de otros frameworks es el modelo de ejecución. En vez de compilar a JavaScript como hacen otras herramientas, Blazor ejecuta C# directamente: en el servidor (comunicándose con el cliente con SignalR), en el navegador (usando WebAssembly) o de forma estática renderizando HTML sin interactividad real. Además, desde que salió .NET 8 puedes incluso mezclar todos esos modos dentro de la misma aplicación, para flexibilidad máxima.

Si tu equipo ya trabaja en el ecosistema .NET, la propuesta de Blazor tiene mucho sentido: mismo lenguaje, mismas herramientas, mismo ciclo de build, y modelos de datos que puedes compartir entre frontend y backend sin duplicar código. Además, sin cambiar de contexto mental cada vez que saltas de la API al componente de UI.

El problema es que "mucho sentido" no siempre se traduce en "mejor opción". Los modos de renderizado disponibles son cuatro, y elegir el equivocado tiene consecuencias que van más allá de una mera preferencia personal.

Si quieres entender qué te aporta conceptualmente Blazor, este artículo es un buen punto de partida.

Los modos de renderizado de Blazor: cuál elegir y por qué importa tanto

Esta es la primera fuente de confusión para quien llega a Blazor sin experiencia previa. No hay un solo "Blazor"; hay cuatro formas de ejecutarlo, cada una con sus usos ideales y sus compromisos:

• Blazor Server ejecuta toda la lógica de UI en el servidor y sincroniza los cambios al navegador mediante SignalR. La carga inicial es rápida y tienes acceso directo a todos los recursos del servidor. El inconveniente es que necesita una conexión persistente por usuario, lo que complica el escalado horizontal y lo hace sensible a la latencia de red. Si quieres entender bien cómo funciona por debajo, en este artículo te lo explicamos en detalle.
• Blazor WebAssembly descarga el runtime de .NET al navegador y ejecuta tu código allí, en el lado cliente, sin dependencias del servidor. Es ideal para apps con funcionalidad offline. El problema histórico era el peso de la descarga inicial y el tiempo de arranque. Con .NET 10 esto mejoró muchísimo y ahora es algo mucho más ligero.
• El modo SSR estático renderiza HTML en el servidor sin interactividad alguna. Es básicamente Razor Pages "reimaginado" con sintaxis de componentes. Rápido, SEO-friendly y sin JavaScript. Perfecto para páginas de contenido que no necesitan dinamismo.
• El modo híbrido (Blazor Web App) mezcla los tres anteriores a nivel de componente. Puedes tener, por ejemplo, una página con SSR estático para el contenido y un componente hijo con interactividad con WebAssembly. Esta flexibilidad da mucha potencia, pero requiere entender bien qué modo aplicas a qué parte de la app y hace que una de las grandes ventajas que siempre tuvo Blazor (su sencillez) lo sea menos, ya que complica un poco las cosas. Pero tiene sus aplicaciones y es importante conocerlo.

Qué viene en .NET 11: SSR a la altura de MVC, WebAssembly con CoreCLR y más cositas buenas

.NET 11 llega en noviembre de 2026. Con cinco previews ya disponibles, el roadmap es bastante claro y hay dos líneas de trabajo que merecen atención especial.

La primera es completar el SSR estático. Blazor 11 añade soporte para TempData en SSR (ese mecanismo de MVC para pasar mensajes entre navegaciones, como las confirmaciones de formulario), validación client-side sin necesidad de WebAssembly ni SignalR, y soporte para validación asíncrona en EditContext.

Este último punto es importante: hasta ahora, si querías validación en el cliente, necesitabas interactividad. Con .NET 11 ya no:

@* Formulario con validación client-side en SSR estático — sin WebAssembly ni SignalR *@
<EditForm Model="registro" OnValidSubmit="ProcesarRegistro" FormName="registro-form">
    <DataAnnotationsValidator />

    <div class="campo">
        <label>Email</label>
        <InputText @bind-Value="registro.Email" />
        <ValidationMessage For="() => registro.Email" />
    </div>

    <div class="campo">
        <label>Nombre de usuario</label>
        <InputText @bind-Value="registro.NombreUsuario" />
        <ValidationMessage For="() => registro.NombreUsuario" />
    </div>

    <button type="submit">Registrarse</button>
</EditForm>

@code {
    [SupplyParameterFromForm]
    private RegistroModel registro { get; set; } = new();

    private async Task ProcesarRegistro()
    {
        await UsuariosService.CrearAsync(registro);
    }
}

También aparecen nuevos componentes (Label, DisplayName, BasePath) que cubren huecos que cualquier desarrollador venido de MVC o Razor Pages notará de inmediato. Y QuickGrid gana paginación y ordenación en modo SSR estático, algo que hasta ahora requería interactividad.

El Blazor Gateway que llega en .NET 11 también merece una mención: actúa de proxy entre el navegador y el backend para apps WASM en producción, eliminando los problemas de CORS y simplificando el despliegue en arquitecturas distribuidas. No es glamuroso, pero elimina una fuente habitual de dolores de cabeza.

La segunda línea de trabajo del equipo ha sido la transición de WebAssembly de Mono a CoreCLR. Este es el cambio más estructural de todos. Mono es el runtime que ha utilizado Blazor WASM desde el principio: funcional, pero con limitaciones en multithreading y acceso a memoria. CoreCLR es el runtime principal de .NET, el mismo que usa tu API o tu aplicación de escritorio.

.NET 11 sienta las bases de esta transición. La versión completa, con multithreading real mediante Web Workers y modelo de memoria de 64 bits, llegará realmente en .NET 12. Cuando esté completada, Blazor WASM podrá ejecutar tareas pesadas (procesamiento de imágenes, cálculo de datos, lógica compleja) en hilos de fondo sin bloquear la UI. Eso abre la puerta a un tipo de aplicaciones web que hoy simplemente no son viables en cliente.

Una aclaración: .NET 11 ya tiene dotnet new webworker, una plantilla que genera el scaffolding necesario para ejecutar código .NET en un Web Worker del navegador. Microsoft Docs ya documenta cómo usar .NET en Web Workers con Blazor WASM para tareas intensivas en CPU. Sin embargo, el multithreading completo e integrado nativamente en CoreCLR (modelo "Deputy Thread" y memoria de 64 bits unificada) sí va a tener que esperar a .NET 12.

Todo esto pinta muy bien en papel. Pero antes de dejarse llevar, conviene ver el cuadro completo.

Las ventajas reales de Blazor frente a React y Angular

Más allá del muy potente argumento de "todo en C#", hay ventajas concretas que se traducen en productividad real para equipos .NET.

1. Compartir modelos entre frontend y backend sin duplicar código: si tienes una clase de modelo de datos con sus validaciones en el servidor, ese mismo modelo funciona en el componente Blazor. Sin escribir el tipo dos veces (una en C# y la otra, por ejemplo, en TypeScript) y sin tener que mantener schemas sincronizados.
2. Tipado fuerte de extremo a extremo: el compilador de C# te avisa cuando rompes un contrato entre componentes. En ecosistemas JS esto depende de que hayas activado TypeScript, de que los tipos estén actualizados y de que nadie haya puesto un any donde no debía. En Blazor es el comportamiento por defecto.
3. El ecosistema de herramientas de Visual Studio y VS Code es muy maduro: depuración de componentes, hot reload (que en .NET 10 funciona también en WebAssembly), integración nativa con EF Core, Azure y ASP.NET Core... todo en el mismo entorno que ya conoces.
4. Sin cambio de contexto cognitivo: personalmente este es el argumento que más me gusta: no tener que alternar entre el modo de pensar de C# y el de JavaScript (o incluso TypeScript) reduce errores y acelera el desarrollo más de lo que la gente espera. Por hacer un símil, a mí me pasa algo parecido cuando echo un par de días trabajando con mi Mac y vuelvo a Windows o al revés: me cuesta acertar con las teclas rápidas, cierro ventanas que no debo y cosas así todo por "cambiar el chip" entre las teclas rápidas de uno y otro sistema. Aquí es algo parecido: poder pensar todo el tiempo igual evita pequeños errores y ahorra tiempo (por no hablar de la paz mental).

Lo que Blazor no tiene es el ecosistema de componentes de React ni la comunidad de Angular. Y eso, según el proyecto, puede ser un factor decisivo.

Los problemas que Blazor todavía no ha resuelto

A ver, por mucho que me guste el framework, hay que reconocer que Blazor tiene algunas limitaciones, y pasarlas por alto sería hacerte un flaco favor:

1. El ecosistema de componentes sigue siendo pequeño comparado con React: si necesitas un componente específico de terceros (un editor de texto enriquecido avanzado, una librería de gráficos interactiva...), es más probable que exista para React que para Blazor. Hay opciones comerciales de componentes muy maduras (Telerik, Syncfusion) y algunas alternativas gratuitas populares (MudBlazor), pero la diversidad no es la misma, ni de lejos. Ahora bien, dado que puedes interactuar entre Blazor/C# y JavaScript, también es cierto que muchas de las bibliotecas de JavaScript populares se pueden utilizar sin problema con Blazor también, pero es un poco más complejo. Y hablando precisamente de esto...
2. La interoperabilidad con JavaScript, aunque ha mejorado, sigue teniendo algo de fricción: si tu app necesita integrarse a fondo con librerías JS existentes, Blazor puede volverse un poco incómodo. El JS interop funciona bien, pero añade una capa de complejidad que simplemente no existe en un proyecto React puro ya que por debajo es JavaScipt. No es un problema grave ni va a suponer un bloqueo para nada, pero es otra cosa a tener en cuenta.
3. Blazor Server no escala bien en muy alta concurrencia: la conexión SignalR persistente por usuario se convierte en un problema cuando tienes muchos miles de usuarios simultáneos. No es un problema sin solución, pero requiere pensar bien la arquitectura desde el principio, algo que con frameworks SPA tradicionales no es tan importante. Ojalá tengas ese problema, porque supondrá que tu aplicación lo está petando, pero debes saberlo desde el principio para anticiparte a cuando ocurra.
4. El SEO en modo WASM sin SSR sigue siendo un problema: si no usas prerender o SSR estático, los buscadores pueden tener dificultades para indexar tu contenido. Con las opciones híbridas de .NET 10 esto es manejable, pero requiere configurarlo conscientemente. Con Next.js o Angular Universal este escenario está resuelto de forma mucho más automática.

Ahora que ya conocemos los pros y los contras de Blazor...

¿Cuándo deberías usar Blazor (y cuándo claramente no)?

La respuesta a esta pregunta depende de tres factores: tu equipo, el tipo de app que quieres crear y las restricciones del proyecto.

Usa Blazor si:

• Tu equipo ya trabaja con .NET y C#. La curva de aprendizaje se reduce drásticamente y el beneficio de compartir código entre capas es inmediato.
• Estás construyendo una aplicación de gestión interna: dashboards, ERPs, herramientas de backoffice, portales de datos... Son exactamente el tipo de app donde Blazor es una maravilla. Si tienen formularios complejos, lógica de negocio compartida y poca dependencia de SEO, son candidatos perfectos para Blazor.
• Te viene bien compartir lógica de validación o modelos de dominio entre backend y frontend sin duplicar código ni mantener dos representaciones del mismo tipo.
• Estás muy metido en el stack de Microsoft (EF Core, ASP.NET Core, Azure...) y quieres una integración natural.

Evita Blazor si:

• Tu equipo viene de JavaScript y TypeScript y no tiene experiencia en .NET. El coste de aprender Blazor más C# más el ecosistema .NET es demasiado alto como para obtener los mismos resultados que ya logran con Angular o React.
• Necesitas máximo rendimiento en la carga inicial para una aplicación pública con muchos usuarios. .NET 10 ha mejorado mucho, pero los frameworks JS más maduros siguen ganando en este aspecto.
• El SEO es crítico y no puedes invertir el tiempo de configurar correctamente el SSR y la hidratación. Con Next.js o Astro, este escenario funciona de forma más transparente.
• Tu app depende de librerías JavaScript específicas sin equivalente en .NET.

El futuro de Blazor: ¿apuesta segura o tecnología de nicho?

Depende de quién seas.

Para equipos .NET, Blazor ya es una apuesta segura. Microsoft lo ha situado como pieza central de su estrategia web con .NET. Ahora mismo .NET 10 es la última LTS (versión con soporte a largo plazo), el roadmap de .NET 11 muestra inversión sostenida, y la transición a CoreCLR para WebAssembly cambiará el juego para aplicaciones exigentes en cliente cuando llegue la próxima LTS con .NET 12.

Para equipos que vienen del mundo JavaScript, sigue siendo tecnología de nicho. No porque sea mala, sino porque el coste de adopción no se justifica si ya tienes productividad alta con Angular o React.

Lo que sí se está ampliando es el conjunto de aplicaciones en las que Blazor puede ser la primera opción. El SSR estático que alcanza paridad de características con MVC en .NET 11, la validación sin interactividad o el Blazor Gateway para despliegues distribuidos son características que empujan a Blazor hacia casos de uso que antes eran territorio exclusivo de otros frameworks.

Un dato a tener en cuenta: en la encuesta de Stack Overflow de 2025, Blazor apareció por primera vez entre los frameworks web más queridos por los desarrolladores que lo usan, con una valoración positiva superior al 60%. Sigue muy lejos de React o Angular en adopción, pero la satisfacción de los usuarios activos es alta.

Es evidente que el ecosistema web no se va a mover a C# de forma masiva. Pero para quienes ya viven y respiran .NET, construir la UI con el mismo lenguaje que el resto del stack es cada vez menos un experimento arriesgado y más una decisión técnica razonable.

Si eres desarrollador .NET y si quieres tomarte Blazor en serio, en campusMVP tenemos un curso de Blazor actualizado a la última que cubre desde los fundamentos hasta una aplicación real completa.

En cambio, si tu camino es JavaScript y quieres dominar alguno de los frameworks con más peso en el mercado, en campusMVP también te tenemos cubierto con cursos completos y actualizados de React y de Angular con proyectos reales incluidos.