O futuro do Blazor no .NET 11
O Blazor no .NET 11 ganhou um planejamento público, apresentado pelo time de produto e engenharia da Microsoft em um Blazor Community Standup dedicado ao próximo ciclo. Neste artigo, você conhece as direções de investimento discutidas e entende o que cada uma significa para quem desenvolve interfaces web com C#.
Contexto do planejamento do Blazor no .NET 11
O Blazor evoluiu rapidamente nos últimos ciclos e se consolidou como a principal opção da Microsoft para interfaces web modernas dentro do ASP.NET Core. Além disso, o framework expandiu seus modos de renderização e a integração com o restante da plataforma.
O próprio time reforçou que a conversa não representava um roadmap final. Na verdade, tratava-se de uma discussão aberta, feita para coletar sinais, dores e cenários reais antes de fechar as prioridades do ciclo.
O vídeo abaixo traz a apresentação completa.
Como a Microsoft conduz o planejamento do ASP.NET Core
O planejamento do ASP.NET Core inclui Blazor, SignalR, Minimal APIs e gRPC, e a comunidade guia boa parte dessas decisões. Nesse processo, as fontes mais relevantes são as issues do GitHub e seus indicadores, como reações, comentários e descrição de cenários.
Assim, uma issue bem detalhada no repositório dotnet/aspnetcore tem peso real na definição do que será construído. O time organiza as demandas em temas amplos:
- Maiores dores reportadas: pontos que reduzem a produtividade ou geram frustração recorrente.
- Fundamentos da plataforma: performance, segurança, observabilidade e confiabilidade.
- Investimento no modern stack: Minimal APIs, Blazor, SignalR e gRPC.
- Aplicações distribuídas mais simples: com destaque para o Aspire.
- Preparação para a IA: suporte a aplicações e a ferramentas de assistência por IA.
Na prática, a meta é elevar qualidade, consistência e produtividade, e não apenas lançar features. Para o panorama do ASP.NET Core como um todo, o artigo o que vem por aí no ASP.NET 11 complementa esta leitura.
Server rendering como pilar do Blazor no .NET 11
Um dos pilares do Blazor no .NET 11 é o aprofundamento da renderização no servidor. Esse esforço envolve o SSR estático, em que o componente vira HTML e o estado é descartado, e o SSR interativo, em que um circuito SignalR mantém o componente vivo.
Segundo o time, o .NET é extremamente forte no servidor, e esse modelo simplifica decisões arquiteturais em muitas aplicações. Mesmo assim, a estratégia não elimina o investimento em WebAssembly.
Para revisar as diferenças entre os modos, vale ler o guia de render modes do Blazor.
Blazor no .NET 11 sem compromissos em relação ao MVC
O objetivo declarado é que o Blazor, como opção recomendada de UI web, não imponha desvantagens a quem o escolhe no lugar de MVC ou Razor Pages. Para isso, o time descreveu um esforço para fechar lacunas do SSR:
- TempData, para guardar dados até a próxima requisição.
- Session state, para manter valores ao longo da sessão.
- Recursos parecidos com display names, comuns em MVC e Razor Pages.
- Cache equivalente ao Cache Tag Helper, para reaproveitar trechos renderizados.
Parte desse plano já aparece nas notas oficiais de novidades do ASP.NET Core no .NET 11. Por exemplo, o TempData chega como valor em cascata durante o SSR estático:
// Valor em cascata com acesso completo ao TempData
[CascadingParameter]
public ITempData? TempData { get; set; }
// Atalho para ler e gravar um único valor
[SupplyParameterFromTempData]
public string? Message { get; set; }
Da mesma forma, o atributo [SupplyParameterFromSession] lê valores da sessão, e o componente CacheView cumpre o papel do antigo Cache Tag Helper:
@* Guarda o trecho renderizado por cinco minutos, variando pela query string *@
<CacheView VaryByQuery="category" ExpiresAfter="TimeSpan.FromMinutes(5)">
<ProductList Category="@Category" />
</CacheView>
Pause e resume de circuitos
O pause e resume de circuitos surgiu no .NET 10 para o SSR interativo. Hoje, a aplicação consegue pausar um circuito, persistir o estado, liberar recursos e depois retomar a execução.
No entanto, as APIs dependem de chamadas JavaScript no cliente, como Blazor.pauseCircuit(), o que o time considera pouco ergonômico. Por isso, o plano do Blazor no .NET 11 incluiu a pausa disparada pelo servidor, via circuit handlers, e políticas prontas de pausa por inatividade.
Essa direção pesa em escalabilidade, porque melhora o controle de memória em cenários de alta concorrência. De fato, a documentação do .NET 11 já descreve o método Circuit.RequestCircuitPauseAsync, que pede ao cliente o início da pausa controlada.
Validação de formulários no Blazor no .NET 11
No SSR estático, a validação acontece no servidor. Entretanto, quando o projeto precisa de validação no cliente, o desenvolvedor costuma migrar a página para um modo interativo, o que o time chamou de pular o penhasco da interatividade.
A proposta para o Blazor no .NET 11 é oferecer validação client-side baseada em JavaScript, como MVC e Razor Pages já fazem. Consequentemente, páginas de cadastro, login e formulários simples ficam mais baratas no SSR estático.
Segundo as notas do .NET 11, os formulários do SSR estático com DataAnnotationsValidator passam a validar no navegador, sem ida ao servidor. Além disso, o modelo .NET continua como fonte única das regras.
QuickGrid em SSR estático e testes de carga
O QuickGrid é o componente de tabela do Blazor, com ordenação e filtros, mas tinha limitações no SSR estático. Nas notas do .NET 11, ele já ganhou modos de paginação baseados na URL e o evento OnRowClick.
Além disso, o time destacou a dificuldade de executar testes de carga em aplicações com SSR interativo. Hoje, simular muitos usuários exige orquestrar várias instâncias de navegador, então a expectativa é ganhar ferramentas mais acessíveis para stress testing.
Principais dores do Blazor no .NET 11
O time listou itens com alta demanda, que aparecem em issues muito votadas no GitHub. A seguir, você confere os destaques do Blazor no .NET 11 agrupados por tema.
Templates, validação e localização
A unificação no template Blazor Web App trouxe simplicidade conceitual. Por outro lado, a tela com várias opções de render mode confunde iniciantes, e o time pretende oferecer templates mais direcionados para cenários comuns.
O time também citou validação assíncrona, que vale para Blazor e Minimal APIs, e a localização das mensagens de validação. De fato, a documentação do .NET 11 já descreve o suporte a AsyncValidationAttribute e IAsyncValidatableObject nos formulários.
Virtualização, render modes e animações
O componente Virtualize tinha limitações com itens de altura variável e com o controle do scroll. Agora, segundo as notas do .NET 11, ele mede os itens em tempo de execução e consegue rolar até um item específico.
Quando uma aplicação mistura render modes, surgem descontinuidades, como valores em cascata que não fluem entre eles. Embora o problema envolva serialização, a meta é deixar essa transição mais fluida.
Por fim, o time quer oferecer debounce e throttle para event handlers e hooks de transição para animações. Com isso, o Blazor fica mais competitivo frente a frameworks front-end que já oferecem esses padrões.
PWA e roteamento
Os templates antigos do Blazor WebAssembly facilitavam Progressive Web Apps, mas essa experiência se perdeu em parte no Blazor Web App. A proposta é trazer de volta o scaffolding de service worker, manifest e cache, inclusive para apps que não usam WebAssembly.
O artigo sobre como criar um PWA com Blazor WASM mostra o caminho manual atual.
No roteamento, as demandas são rotas aninhadas e restrições de rota. Enquanto isso, o .NET 11 já adicionou o parâmetro RelativeToCurrentUri ao NavigateTo e ao NavLink, para navegar de forma relativa à página atual.
Aspire e o Blazor no .NET 11
O Aspire é um investimento estratégico para simplificar aplicações distribuídas no .NET. Por isso, o time quer que o Blazor no .NET 11 se integre ao Aspire de forma nativa.
O primeiro alvo é o deploy. Afinal, o Blazor Server depende de sticky sessions para reconectar circuitos, e o WebAssembly exige cuidado ao servir arquivos pré-comprimidos.
O segundo alvo é o debugging. Hoje, o dashboard do Aspire abre a aplicação em um navegador comum, enquanto o WebAssembly exige depuração remota habilitada, então o time discutiu abrir o app já configurado.
O terceiro alvo é a telemetria com OpenTelemetry no cliente, incluindo service defaults próprios para WebAssembly. Nas notas do .NET 11, já aparecem métricas de componentes no WebAssembly e o template blazor-wasm-servicedefaults.
Blazor Gateway
Para viabilizar a integração com Aspire, telemetria e service discovery, o time apresentou o conceito de Blazor Gateway. A ideia é oferecer um host padronizado para aplicações Blazor WebAssembly standalone.
Assim, o gateway responde a uma pergunta antiga: onde hospedar um app WebAssembly standalone em produção? Além de servir os assets, ele poderia:
- fornecer endpoints de configuração;
- integrar telemetria;
- fazer proxy de requisições para serviços internos;
- habilitar service discovery sem expor URLs e CORS no navegador;
- hospedar vários apps WebAssembly no mesmo host.
Segundo o time, o gateway deve usar o YARP, sigla para Yet Another Reverse Proxy, com padrões opinativos. Na documentação do .NET 11, o pacote Microsoft.AspNetCore.Components.Gateway já substitui o antigo DevServer.
WebAssembly no Blazor no .NET 11
Para quem usa WebAssembly, o tema mais importante do Blazor no .NET 11 foi a consolidação de runtimes. Hoje, o .NET mantém implementações diferentes, como CoreCLR e Mono, e essa fragmentação aumenta o custo de manutenção.
Por isso, a direção é mover o WebAssembly para uma base CoreCLR. O time deixou alguns pontos claros:
- no .NET 11, o runtime WebAssembly com CoreCLR chega apenas como prévia, sem suporte para produção;
- o Mono continua como runtime oficial do WebAssembly no .NET 11;
- grandes investimentos em features novas no Mono devem diminuir, para evitar retrabalho.
Essa escolha aceita atrasos pontuais para acelerar a evolução estrutural. Nas notas do runtime do .NET 11, o CoreCLR no WebAssembly já executa de ponta a ponta a suíte de testes das bibliotecas.
Multithreading no WebAssembly, um dos pedidos mais frequentes, não deve chegar nesse ciclo. Portanto, a implementação fica para depois que o CoreCLR no navegador amadurecer.
Template de Web Worker para .NET
Como alternativa parcial ao multithreading, o time propôs um template de .NET WebWorker para executar código fora da UI thread. O caso típico envolve desserializar grandes blobs JSON ou processar muitos dados no cliente sem travar a interface.
A Microsoft já usa essa estratégia no Microsoft Copilot Studio, que executa código .NET em Web Workers. Inicialmente, a proposta oferece infraestrutura e troca de mensagens, sem impor um framework de RPC.
Nas notas mais recentes, o template recebeu o nome Blazor Web Worker (blazorwebworker) e ganhou suporte a cancelamento. Para um passo a passo, consulte o artigo sobre Web Workers no Blazor com .NET 11.
IA no Blazor no .NET 11
O Blazor no .NET 11 também recebe investimentos em inteligência artificial. O foco inclui componentes para UI agentic, entradas multimodais e alinhamento com a especificação AG-UI, que define a comunicação entre agentes e interfaces.
Além disso, o time explora contexto específico de Blazor para agentes, suporte a servidores MCP e analyzers que avaliem as sugestões dos copilots. Hoje, o pacote experimental Microsoft.AspNetCore.Components.AI já reúne componentes para chat em streaming e aprovação humana.
O artigo sobre componentes agentic do Blazor detalha esse pacote.
Considerações finais
A discussão sobre o Blazor no .NET 11 mostra que o objetivo não é só lançar novidades. Na verdade, a meta é elevar a maturidade do framework onde ele ainda precisa igualar os modelos tradicionais do ASP.NET Core.
Os temas convergem para quatro movimentos:
- Consolidar o Blazor como UI web recomendada, removendo lacunas de SSR em relação a MVC e Razor Pages.
- Melhorar a ergonomia em render modes mistos, validação, virtualização e roteamento.
- Integrar o Blazor ao Aspire, com telemetria e deploy consistente.
- Preparar o WebAssembly e a IA, mesmo com o adiamento do multithreading.
Por fim, a comunidade tem papel decisivo na priorização do Blazor no .NET 11. Participar com issues e feedback detalhado no GitHub faz parte do processo que define o que o ciclo entrega.
O vídeo abaixo serviu de fonte para este conteúdo.
FAQ
O planejamento apresentado é um roadmap oficial?
Não. O time apresentou direções de investimento e pediu feedback da comunidade, deixando claro que as prioridades ainda podiam mudar.
O Blazor WebAssembly vai deixar de ser suportado?
Não. O foco do ciclo está no servidor, mas o WebAssembly continua recebendo investimento, inclusive com a migração para o CoreCLR.
O .NET 11 traz multithreading no WebAssembly?
Não. O time adiou o recurso até o CoreCLR no WebAssembly amadurecer e oferece o template de Web Worker como alternativa.
O que é o Blazor Gateway?
É um host leve, baseado em ASP.NET Core e YARP, para servir aplicações Blazor WebAssembly standalone com configuração, proxy e telemetria.
Como influenciar as prioridades do Blazor?
Abrindo issues detalhadas, reagindo às existentes e descrevendo cenários reais no repositório dotnet/aspnetcore no GitHub.