O futuro do ASP.NET e Blazor

Por que ainda usamos o ASP.NET hoje

Antes de falar do Blazor no .NET 8, vale alinhar alguns conceitos. O C# é a linguagem de programação, e o .NET é o framework, ou seja, o conjunto de bibliotecas que torna o desenvolvimento mais rápido.

A Microsoft escreve o próprio .NET em C#. Por sua vez, o ASP.NET é o principal framework da Microsoft para criar aplicações web, APIs e websites, e ele roda em cima do .NET.

Assim como o C# e o .NET, o ASP.NET tem mais de 20 anos de existência e evoluiu muito nesse período. Atualmente, ele aparece entre os frameworks mais rápidos do mercado, à frente com folga de vários concorrentes em benchmarks de desempenho.

Qual era o problema do ASP.NET

Sendo sincero, não era bem um problema, e sim uma expansão que faltava e que só o Blazor no .NET 8 completou. O ASP.NET sempre foi muito popular no backend, principalmente para criar APIs.

Porém, com a popularização dos frameworks SPA (Single Page Applications), o ASP.NET acabou deixado de lado em diversos cenários. Isso acontece porque os navegadores executam apenas HTML, CSS e JavaScript, o que tornava o JavaScript quase obrigatório no frontend.

O ASP.NET consegue servir muito bem a parte de SSR (Server Side Rendering), a renderização do lado do servidor. No entanto, ele parava por aí.

Na verdade, antes do Blazor no .NET 8, ele só fazia isso. Toda aplicação web, e não API, que você criava com ASP.NET passava pela renderização do lado do servidor.

Na prática, se você quisesse atualizar um simples contador na tela, precisava enviar uma requisição ao servidor. Em seguida, o servidor gerava HTML, CSS e JavaScript de novo e devolvia tudo para o navegador.

Já nas aplicações SPA, o navegador carrega a interface uma vez e, depois disso, o navegador busca somente os dados no servidor. Normalmente isso acontece por meio de uma requisição para uma API que devolve JSON, e o JavaScript gera o HTML necessário.

SSR vs SPA

Tanto o SSR quanto o SPA têm um papel único no cenário web, e cada um tem suas características. Entender essa diferença é essencial para entender o que o Blazor no .NET 8 resolve.

Server Side Rendering

Do lado do SSR, existem diversos pontos fortes e fracos, mas em resumo eu elegeria dois principais:

• Carregamento mais rápido, já que o servidor envia só o que a página precisa.
• Melhor otimização para SEO, porque o Google e outros buscadores recebem o HTML pronto.

A ilustração abaixo mostra como funcionam as requisições e respostas em uma aplicação baseada em SSR.

Repare que a relação é extremamente simples. Ela aproveita a base de toda aplicação web, que é uma requisição seguida de uma resposta.

Single Page Application

Do lado do SPA, também existem pontos fortes e fracos, e em resumo eu elegeria três características principais:

• Carregamento inicial mais demorado.
• Melhor interação com o usuário.
• Interface mais responsiva.

A ilustração a seguir mostra como funcionam as requisições e respostas em uma aplicação SPA.

Nesse modelo, o carregamento inicial é parecido com o do SSR. Depois, porém, o navegador faz apenas requisições assíncronas, recebe JSON como retorno e gera o HTML necessário.

AJAX é a sigla para Asynchronous JavaScript and XML, um termo muito usado nos primórdios das requisições assíncronas. Hoje podemos chamar apenas de "requisição", já que o XML praticamente não é mais utilizado nesse contexto.

Apresentando o Blazor

Há alguns anos, a Microsoft chegou com uma proposta legal e ousada, que inclusive eu comparei com o Silverlight na época. Embora simples, a ideia do Blazor era trazer o que o SPA tem de bom, como responsividade e interação com o usuário, e unir isso ao carregamento rápido do SSR.

Mas a proposta mais ousada foi outra: levar o C# para o frontend. Não no lugar do JavaScript, já que você ainda pode usar JS e até interoperar com C#, mas como um complemento a ele.

Com isso, a Microsoft começou a fechar um ciclo que só se completaria com o Blazor no .NET 8, com ASP.NET no backend e no SSR e Blazor para SPA. De quebra, ela abriu a possibilidade de trabalhar com C# no frontend.

A Microsoft ainda dividiu o Blazor em dois modelos de hospedagem, o Blazor Server e o Blazor WebAssembly, cada um com propósitos diferentes. Se quiser uma visão mais ampla, o artigo uma visão geral do Blazor complementa esta seção.

Blazor Server

A ideia principal do Blazor Server é rodar no servidor, mas de um jeito diferente do que o ASP.NET faz com Razor Pages. Enquanto o ASP.NET renderiza a página inteira de novo, o Blazor foi mais esperto.

Ele mantém uma conexão aberta com o servidor e atualiza apenas o componente que o usuário manipula. Segundo a documentação, essa conexão usa SignalR sobre WebSockets, e o estado de cada cliente conectado fica em um circuit no servidor.

Ou seja, o servidor entrega a aplicação de forma rápida na primeira carga. Depois, os componentes passam a ser atualizados por um socket, uma conexão que fica aberta direto com o servidor e responde muito mais rápido.

Blazor WebAssembly

Na outra mão temos o Blazor WebAssembly, ou Blazor WASM, que faz um trabalho bem diferente do seu irmão. O WebAssembly não é exclusividade da Microsoft, e outras tecnologias como Rust também se beneficiam dele.

Basicamente, o WebAssembly permite executar código compilado no navegador usando linguagens que não são necessariamente JavaScript. Isso implica não só maior desempenho, mas também mais flexibilidade, como reaproveitar regras de negócio escritas em C#.

Em resumo, o Blazor WASM é literalmente o .NET rodando dentro do navegador. Além de entregar os arquivos estáticos, o servidor não precisa processar nada.

Então, depois do carregamento inicial, temos ótimo desempenho, algo que o Blazor no .NET 8 preserva no modo WebAssembly, e, claro, o uso e abuso do nosso querido C#.

Os problemas do Blazor antes do .NET 8

Como nem tudo são flores, tanto o Blazor Server quanto o Blazor WASM tinham seus defeitos. Enquanto o Blazor WASM oferece ótimo desempenho, sua fraqueza é o tamanho da aplicação, que precisa baixar o runtime do .NET e por isso fica bem maior que uma aplicação convencional.

No Blazor Server, manter a conexão sempre aberta com o servidor pode sair caro. A documentação lembra que cada aba do navegador exige um circuit separado, o que dificulta a escala com muitos usuários.

Além disso, renderizar os componentes novamente nem sempre é o caminho mais performático. Em aplicações puramente cliente, também perdíamos parte do SEO, já que o navegador recebia inicialmente só o "esqueleto" da página, o que deixa o Google triste.

Para finalizar, até o .NET 7 não era possível usar Blazor Server, WASM e SSR juntos no mesmo projeto. E essa é justamente a grande novidade do Blazor no .NET 8.

O que muda com o Blazor no .NET 8

Com o lançamento do .NET 8, a Microsoft passou a tratar o Blazor como um framework web full stack. Na prática, cada componente ou página pode escolher seu modo de renderização.

As notas oficiais de novidades do ASP.NET Core no .NET 8 listam quatro modos de renderização:

• Static Server: gera HTML estático no servidor, sem interatividade, no estilo do SSR tradicional.
• Interactive Server: gera componentes interativos no servidor, com a conexão em tempo real do Blazor Server.
• WebAssembly interativo (Interactive WebAssembly): gera componentes interativos no cliente, com o runtime do .NET no navegador.
• Interactive Auto: começa no servidor e passa a usar WebAssembly assim que o pacote do Blazor termina de baixar.

Os modos interativos também fazem pré-renderização por padrão. Com isso, o servidor envia o HTML inicial rapidamente, o que ajuda tanto a percepção de velocidade quanto o SEO.

var builder = WebApplication.CreateBuilder(args);

// Registra os componentes Razor e os modos interativos
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents()
    .AddInteractiveWebAssemblyComponents();

var app = builder.Build();

app.UseStaticFiles();
app.UseAntiforgery();

// Mapeia o componente raiz e habilita os modos de renderização
app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode()
    .AddInteractiveWebAssemblyRenderMode();

app.Run();

@page "/counter"
@rendermode InteractiveServer

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount() => currentCount++;
}

Como fica o ASP.NET com o Blazor no .NET 8

Mas se agora podemos usar SSR, WASM e os recursos do Blazor Server juntos, por que ainda precisamos do ASP.NET? Nos últimos anos, o ASP.NET recebeu diversas melhorias significativas, desde os top-level statements, que não foram só para ele, até a chegada das Minimal APIs.

Sendo assim, eu encaro o ASP.NET com mais foco em APIs a partir do .NET 8, sendo mais específico nas Minimal APIs. Se ainda não conhece o modelo, o artigo sobre Minimal APIs no ASP.NET é um bom ponto de partida.

Para aplicações SSR, como websites, você ainda pode manter o Razor Pages. No entanto, o Blazor já resolve muita coisa.

Para o MVC, o cenário é um pouco menos favorável. A arquitetura costuma ser considerada mais complexa para iniciar um projeto e consome mais recursos que as Minimal APIs.

Então, o MVC fica mais para projetos que realmente precisam dessa arquitetura. E antes de dizer que não dá para organizar bem as Minimal APIs, confira este repositório:

https://github.com/balta-io/3001

Vale lembrar que o Blazor no .NET 8 também é ASP.NET. Afinal, o Blazor Web App roda sobre o pipeline do ASP.NET Core, com o mesmo WebApplication, o mesmo sistema de injeção de dependência e os mesmos middlewares.

Unificação dos projetos

Indo além, o .NET 8 também unificou os templates. Para criar uma aplicação com suporte a SSR, WASM e Blazor Server, basta usar o comando abaixo:

dotnet new blazor -o BlazorApp

Esse novo projeto combina recursos do ASP.NET, do Blazor Server e do Blazor WASM. Com ele, você cria Razor Components, páginas Blazor com SSR, componentes interativos e até partes da aplicação rodando em WebAssembly.

O template também aceita a opção --interactivity, com os valores None, Server, WebAssembly e Auto. Por padrão, ele usa Server.

dotnet new blazor -o BlazorApp --interactivity Auto

Conclusão

Essa é uma mudança significativa no ASP.NET, que leva o Blazor para um novo patamar. Com o Blazor no .NET 8, é possível criar aplicações SSR, SPA e WASM com o mesmo framework.

Isso torna o Blazor uma opção simples e direta para quem gosta de .NET e quer usar C# no frontend. Enquanto isso, o ASP.NET se fortalece como a base para APIs, especialmente com as Minimal APIs.

FAQ

Quando o .NET 8 foi lançado?

O .NET 8 foi lançado em 14 de novembro de 2023. Ele é uma versão LTS e trouxe o novo modelo unificado do Blazor.

Qual a diferença entre Blazor Server e Blazor WebAssembly?

O Blazor Server executa os componentes no servidor e atualiza a tela por uma conexão SignalR. Já o Blazor WebAssembly baixa o runtime do .NET e executa tudo no navegador.

O que é o template Blazor Web App?

É o template criado pelo comando dotnet new blazor. Ele combina SSR, interatividade no servidor e WebAssembly em um único projeto.

O Blazor substitui o ASP.NET?

Não, porque o Blazor roda sobre o ASP.NET Core. Na prática, o ASP.NET segue como base, com foco forte em APIs e Minimal APIs.

Ainda posso usar Razor Pages e MVC no .NET 8?

Sim, os templates razor e mvc continuam disponíveis. Eles fazem sentido quando o projeto realmente precisa desse modelo de arquitetura.