Blazor do Zero: Capítulo 1 — O que é Blazor?
Bem-vindo ao Capítulo 1 de Blazor do Zero. Se perdeu o post de introdução onde explico o propósito desta série e a quem se destina, comece por lá — é curto.
Neste capítulo vamos responder à pergunta fundamental: o que é Blazor? Parece simples, mas a resposta tem várias camadas — especialmente porque “Blazor” passou a ter significados ligeiramente diferentes ao longo dos anos. No final deste post saberá o que é Blazor, como se encaixa no ecossistema .NET, quais são os diferentes modelos de renderização e por que razão poderá — ou não — escolhê-lo em vez de um framework JavaScript.
Um breve historial
O Blazor começou como um projeto experimental de Steve Sanderson na Microsoft por volta de 2017. A ideia era provocadora: executar C# no navegador usando WebAssembly, eliminando completamente a necessidade de JavaScript. Era uma prova de conceito, e o nome era uma mistura deliberada de Blazer e Razor — o motor de templates sobre o qual o Blazor viria a ser construído.
O experimento gerou entusiasmo suficiente para que a Microsoft o levasse a sério. O Blazor foi lançado como parte do ASP.NET Core 3.0 em setembro de 2019, primeiro como Blazor Server — um modelo que executa o seu código C# no servidor e usa uma conexão SignalR em tempo real para enviar atualizações de interface ao navegador. Blazor WebAssembly seguiu em maio de 2020 como parte do ASP.NET Core 3.1, trazendo execução verdadeiramente do lado do cliente ao framework.
O .NET 6 e 7 refinaram a experiência do desenvolvedor. Depois, o .NET 8, lançado em novembro de 2023, repensou fundamentalmente o modelo de renderização com o que a Microsoft chamou de UI web full-stack. Renderização estática do lado do servidor, streaming rendering, servidor interativo, WebAssembly interativo e um novo modo Auto viviam todos sob o mesmo teto num único projeto. O .NET 9 construiu sobre esta base e eliminou as arestas.
É aqui que estamos hoje.
O que o Blazor realmente é
No seu núcleo, o Blazor é um framework de UI baseado em componentes para .NET. Constrói a sua interface a partir de componentes — peças autocontidas de C# e marcação HTML que podem manter estado, responder a eventos e compor-se em estruturas maiores. Se trabalhou com React ou Vue, esse modelo mental vai parecer familiar. A diferença fundamental é que em vez de JavaScript, escreve C#.
Os componentes em Blazor são escritos em ficheiros .razor. Um ficheiro .razor mistura marcação HTML com código C# usando a sintaxe Razor que pode já conhecer das views do ASP.NET MVC. Aqui está como fica um componente simples:
@page "/counter"
<h1>Contador</h1>
<p>Contagem atual: @currentCount</p>
<button @onclick="IncrementCount">Clique aqui</button>
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
Não há JavaScript à vista. A diretiva @onclick associa o clique do botão a um método C#. A expressão @currentCount renderiza o valor atual. Quando o estado muda, o Blazor determina o que atualizar no DOM.
Esse é o núcleo. Tudo o resto — routing, injeção de dependências, formulários, chamadas HTTP — é construído sobre este modelo de componentes.
Os modelos de renderização
É aqui que reside muita confusão, por isso sejamos precisos. “Blazor” hoje refere-se a uma família de modos de renderização, não a um único modelo de implantação. Compreender a diferença importa porque afeta a performance, os requisitos de infraestrutura e o que os seus componentes podem ou não fazer.
SSR Estático
O modo mais simples. Os seus componentes Razor renderizam no servidor para HTML e esse HTML é enviado ao navegador. Não há conexão persistente, sem WebAssembly e sem interatividade do lado do cliente por padrão. É essencialmente o que o Razor Pages faz, mas usando o modelo de componentes.
Use para páginas com muito conteúdo, landing pages, qualquer coisa que não precise de interatividade em tempo real.
Servidor Interativo
O código do seu componente corre no servidor. Uma conexão WebSocket SignalR é estabelecida entre o navegador e o servidor. Quando clica num botão ou escreve num campo, o evento viaja pelo WebSocket até ao servidor, o seu C# executa, o diff é calculado e as atualizações do DOM são enviadas de volta ao navegador.
Vantagens: Acesso total aos recursos do servidor (bases de dados, sistema de ficheiros, segredos). Carregamento inicial rápido. Tamanho de download reduzido. Funciona em navegadores sem suporte a WebAssembly.
Desvantagens: Cada interação do utilizador requer uma viagem de ida e volta ao servidor, o que adiciona latência. Os recursos do servidor escalam com o número de conexões ativas. A app degrada se a conexão cair.
Use para aplicações empresariais, ferramentas internas, apps onde o acesso a dados do servidor importa mais do que a capacidade offline.
WebAssembly Interativo
O runtime .NET é descarregado para o navegador e a sua app corre completamente no cliente. Após o download inicial, a app funciona completamente offline e cada interação é imediata — sem viagens ao servidor para lógica de interface.
Vantagens: Execução verdadeiramente do lado do cliente. Funciona offline. Carga do servidor reduzida após a app estar carregada.
Desvantagens: Download inicial maior (runtime .NET + a sua app). Primeiro carregamento mais lento. Precisa de uma API para aceder a dados do servidor.
Use para apps com capacidade offline, ferramentas que precisam de reatividade imediata, cenários onde o processamento do servidor não é necessário para a interface.
Modo Auto
Introduzido no .NET 8. A app começa no modo Servidor Interativo (carregamento inicial rápido, sem esperar pelo download do WebAssembly). Assim que os ficheiros WebAssembly tiverem sido descarregados em segundo plano, as visitas subsequentes mudam automaticamente para o modo WebAssembly.
Isto dá-lhe o carregamento inicial rápido do modo Servidor e eventualmente a execução completa do lado do cliente do WebAssembly. É o modelo mais complexo de compreender, mas é um padrão prático para muitas apps.
Misturar modos na mesma app
No .NET 8 e posteriores, não está limitado a um único modo de renderização para toda a app. Uma landing page pode ser SSR Estático; o dashboard autenticado pode ser Servidor Interativo; um widget de visualização de dados pode ser WebAssembly Interativo. O framework gere as transições.
Nesta série começaremos com o Servidor Interativo por ser o mais simples de colocar a funcionar e ter o modelo mental mais direto. Exploraremos os outros modos à medida que avançamos.
Como o Blazor se compara com frameworks JavaScript
Se desenvolveu com React, Angular ou Vue, esta é provavelmente a comparação que lhe interessa.
As semelhanças são reais. O modelo de componentes do Blazor é deliberadamente semelhante ao do React. Tem props (Parâmetros no Blazor), estado local (campos no bloco @code), hooks de ciclo de vida e o mesmo padrão de comunicação dados para baixo / eventos para cima. Se conhece React, vai sentir-se em casa em poucas horas.
A diferença fundamental é a linguagem. No Blazor escreve C#. A sua lógica de negócio, regras de validação e modelos de dados podem todos ser partilhados entre o seu frontend Blazor e o seu backend ASP.NET Core. Sem duplicar uma classe User em TypeScript quando já a tem em C#.
A lacuna do ecossistema é real mas está a fechar. O ecossistema npm é enorme. O ecossistema NuGet para componentes de UI é menor, embora tenha crescido substancialmente. Para uma biblioteca de gráficos específica ou um widget de drag-and-drop, o JavaScript ainda tem mais opções. Mas para a maioria das aplicações empresariais, o que está disponível no mundo .NET é mais do que suficiente.
A interoperabilidade JavaScript existe quando precisa dela. O Blazor permite chamar JavaScript a partir de C# e C# a partir de JavaScript. Para APIs do navegador sem wrapper .NET, ou quando quer usar uma biblioteca JS existente, o interop está disponível. Adiciona uma camada mas não é doloroso.
A resposta honesta: se a sua equipa é totalmente de developers JavaScript a construir um produto público onde SEO, performance e o ecossistema npm são críticos, fique com JavaScript. Se a sua equipa é de developers .NET, se está a construir aplicações internas ou empresariais, ou se a partilha de código entre frontend e backend lhe importa, o Blazor é uma escolha convincente.
O que precisa para acompanhar a série
Para o resto desta série vai precisar de:
- .NET 9 SDK — descarregue em dot.net
- Um IDE — Visual Studio 2022 (a edição Community é gratuita), VS Code com a extensão C# Dev Kit, ou JetBrains Rider
- Conforto básico com C# — classes, propriedades, interfaces, async/await
Só isso. Sem Node, sem npm, sem webpack.
A seguir
No Capítulo 2 vamos montar a sua primeira app Blazor, percorrer a estrutura do projeto e garantir que consegue executá-la localmente. No final terá uma app a funcionar e uma imagem clara do que cada ficheiro está a fazer.
Até lá.