Por que as empresas decidem utilizar Blazor para seus projetos?

Com Blazor, especialmente utilizando frameworks como Syncfusion, o desenvolvimento fica muito rápido e com uma qualidade impressionante.

Com praticamente um Ctrl+C e Ctrl+V você consegue implementar um painel Kanban incrível e focar apenas nas variáveis de entrada e saída do projeto com C#, sem precisar se preocupar com muitos detalhes como programar eventos e ciclo de vida, consumo de serviços e API.

<SfKanban CssClass="kanban-overview" KeyField="Status" DataSource="@CardData" EnableTooltip="true">
    <KanbanColumns>
    </KanbanColumns>
    <KanbanCardSettings ContentField="Summary" HeaderField="Title" SelectionType="@SelectionType.Multiple">
    </KanbanCardSettings>
    <KanbanSwimlaneSettings KeyField="Assignee"></KanbanSwimlaneSettings>
</SfKanban>

@code{
    private List<KanbanDataModel> CardData = new KanbanDataModel().GetCardTasks();
    private List<ColumnModel> ColumnData = new List<ColumnModel>() 
    {
        new ColumnModel(){ HeaderText= "To Do", KeyField= new List<string>() { "Open" }, AllowToggle= true },
        new ColumnModel(){ HeaderText= "In Progress", KeyField= new List<string>() { "In Progress" }, AllowToggle= true },
        new ColumnModel(){ HeaderText= "In Review", KeyField= new List<string>() { "Review" }, AllowToggle= true },
        new ColumnModel(){ HeaderText= "Done", KeyField= new List<string>() { "Close" }, AllowToggle= true }
    };
}

Resultado:

Documentação: https://blazor.syncfusion.com/demos/kanban/overview?theme=bootstrap5

Uma observação que vale a pena mencionar é que nem estamos falando de Copilot, Claude Code ou Codex ainda.

Muito antes dos agentes de IA existirem, o Blazor já era um hack de produtividade.

Com Blazor, podíamos construir um portal inteiro em apenas duas semanas porque já tínhamos o scaffold das entidades. Bastava criar uma entidade com seus atributos e então gerar automaticamente páginas de Inserção, Atualização, Exclusão e Listagem, já incluindo validações básicas, permissões do ASP.NET Identity e um layout responsivo com Bootstrap.

Depois disso, precisávamos apenas implementar algumas validações de negócio e lógicas específicas da aplicação.

Hoje, quando somamos essa realidade com os agentes de IA, estamos falando de um nível insano de produtividade. A quantidade de software que pode ser produzida está se tornando absurda.

Isso cria um novo desafio: ter energia mental e foco suficientes para acompanhar a velocidade com que as coisas podem ser construídas atualmente. Foi justamente por isso que escrevi um artigo sobre biohacking para energia cerebral utilizando cetonas. https://www.gabrielgregori.com/Articles/Details/dieta-cetogenica-o-biohack-para-a-produtividade-dos-programadores

Uma stack unificada

Outro grande benefício é não precisar se manter atualizado em diversas tecnologias diferentes.

Ao invés de conhecer uma stack de back-end e outra de front-end, você pode utilizar C# em toda a aplicação.

Além disso, é possível reutilizar entidades, validações e regras de negócio diretamente no front-end, compartilhando código entre as camadas do sistema.

Tudo isso trabalhando em uma única IDE, com uma integração extremamente simples.

A cada 6 meses a Microsoft lança uma nova versão do .NET com nova versão do C#, agora imagine ter que ficar se atualizando com todo esse ecosistema e ao mesmo tempo se atualizar com Angular, Javascript e Typescript etc. Se você adotar Blazor, pode focar mais em aprender design patterns e conceitos pois tera  menos carga para se atualizar em framework e linguagens.

Menos camadas, menos complexidade

Dependendo da arquitetura escolhida, você nem precisa criar uma API.

No Blazor é possível injetar serviços e repositórios diretamente na aplicação. Caso exista necessidade de uma API, ela pode ser criada separadamente.

Essa flexibilidade reduz bastante a complexidade inicial de muitos projetos.

Integração com Visual Studio e Azure

A integração com Visual Studio e Azure é excelente.

Com poucos cliques você cria um projeto Blazor utilizando templates prontos da Microsoft e, com mais alguns cliques, publica a aplicação na Azure.

Para equipes que já trabalham com .NET, isso reduz bastante o tempo gasto com configuração e infraestrutura.

O mesmo ecossistema .NET

Os mesmos pacotes que você já conhece e utiliza no back-end podem ser utilizados no front-end.

Tudo é gerenciado através do NuGet.

Isso facilita a manutenção do projeto e reduz a quantidade de tecnologias diferentes que a equipe precisa dominar.

Desenvolvedores back-end produzindo front-end

Um dos pontos que mais gosto no Blazor é que um desenvolvedor back-end consegue produzir interfaces modernas com uma curva de aprendizado muito baixa.

Utilizando bibliotecas como Syncfusion ou Telerik, é possível criar dashboards, grids, gráficos, formulários e interfaces complexas sem precisar se tornar especialista em frameworks JavaScript.

MAUI Blazor Hybrid

Existe um template chamado MAUI Blazor Hybrid.

Com ele você pode reutilizar tanto o back-end quanto o front-end e gerar aplicações para:

• Web
• Windows
• macOS
• Android
• iOS

Tudo utilizando praticamente o mesmo código, a mesma IDE e as mesmas tecnologias.

Em termos de produtividade, é difícil encontrar algo semelhante dentro do ecossistema Microsoft.

Equipes mais flexíveis

Existe também um benefício organizacional.

Quando um membro da equipe se afasta por férias, licença, problemas de saúde ou qualquer outro motivo, outro profissional consegue assumir suas responsabilidades com muito mais facilidade.

Como toda a aplicação gira em torno do mesmo ecossistema, o custo de transição de conhecimento tende a ser menor.

Evolução constante da plataforma

Ao utilizar Blazor, você está utilizando uma tecnologia apoiada diretamente pela Microsoft.

Novos recursos surgem constantemente.

Um exemplo foi o lançamento dos Render Modes no .NET 8.

Com eles, você pode decidir se determinado componente será executado no servidor ou no cliente.

Isso permite criar arquiteturas muito mais inteligentes, equilibrando produtividade, experiência do usuário e consumo de recursos.

Lista concisa de vantagens do Blazor

• Maior produtividade no desenvolvimento
• Desenvolvimento rápido utilizando Syncfusion, Telerik e outros componentes
• Criação de interfaces complexas com pouco código
• Stack unificada utilizando apenas C#
• Reutilização de entidades entre front-end e back-end
• Reutilização de validações e regras de negócio
• Curva de aprendizado reduzida para desenvolvedores .NET
• Compartilhamento de código entre camadas da aplicação
• Possibilidade de injetar serviços diretamente no front-end
• Integração nativa com Visual Studio
• Criação rápida de projetos através de templates
• Publicação simplificada para Azure
• Ecossistema totalmente integrado ao .NET
• Utilização dos mesmos pacotes NuGet no front-end e no back-end
• Menos duplicação de código
• Desenvolvimento full stack com uma única linguagem
• Facilidade de depuração em toda a aplicação
• Aproveitamento do conhecimento já existente em C#
• Redução de custos com treinamento
• Alta produtividade para sistemas corporativos
• Foco nas regras de negócio em vez da infraestrutura do front-end
• Use Scaffold for entities and gere páginas de CRUD para a entidade com validações básicas e permissões identity.

Então por que algumas empresas falham com Blazor?

Pude presenciar empresas desistindo do Blazor.

Também tenho amigos em grandes empresas, inclusive do setor automotivo, que abandonaram a tecnologia principalmente por questões de performance.

No ano passado, quando meu contrato em um cliente foi encerrado, participei de entrevistas internas e externas.

Achei curioso que várias empresas demonstraram interesse justamente por um motivo: entender como fazer projetos Blazor funcionarem em produção.

O problema real

Sem marketing e sem conversa furada, o problema normalmente é muito simples:

Websocket do SignalR escalando para milhares de usuários.

Vi arquitetos, engenheiros de software seniores e profissionais com décadas de experiência ignorando completamente esse detalhe.

Uma aplicação JavaScript tradicional trabalha principalmente através de requisições HTTP.

Já o Blazor Server mantém uma conexão SignalR ativa entre cliente e servidor.

Cada usuário conectado representa uma conexão persistente.

O custo de escalar Blazor Server

Enquanto uma aplicação tradicional trabalha majoritariamente com requisições GET, POST, PUT e DELETE, o Blazor Server mantém um fluxo constante de comunicação.

Se existem 1.000 usuários conectados, existem aproximadamente 1.000 conexões WebSocket ativas que estão enviando eventos e recebendo para atualizar o DOM.

Existe toda uma engenharia por trás disso.

Não preciso conhecer todos os detalhes internos para entender o resultado final: consumo de CPU, memória e recursos do servidor.

É nesse ponto que muitos projetos começam a apresentar problemas.

O erro mais comum

O profissional vê problemas de performance e conclui:

"Blazor não escala."

Então abandona a tecnologia e migra para algum framework JavaScript.

Mas essa conclusão nem sempre está correta.

Outro erro é colocar desenvolvedores javascript para trabalhar com Blazor são ecosistemas diferentes.

Como contornar isso

Hoje existem diversas formas de aproveitar os benefícios do Blazor sem depender exclusivamente do Blazor Server.

Podemos utilizar:

• Blazor WebAssembly consumindo APIs
• Render Modes, deixe páginas com muitos acessos que precisam escalar no webassembly consumindo API e Dashboards com Blazor Server.
• Arquiteturas híbridas utilizando Razor Pages para páginas de alto tráfego.
• Componentes executando no cliente utilizando render modes.
• Componentes executando no servidor utilizando render modes.

O framework mais subestimado do ecossistema .NET

Agora vem o insight mais interessante.

ASP.NET Razor Pages

Provavelmente o Razor Pages é um dos frameworks mais subestimados da comunidade .NET.

Ele possui praticamente todas as características que atraem desenvolvedores para o Blazor.

Apenas para exemplo algumas delas que foram citadas na lista de cima:

• C#
• .NET
• Componentes Razor
• Compartilhamento de código
• Bibliotecas como Syncfusion

Mas com um custo computacional muito menor para cenários públicos de alta escala.

Isso acontece porque não existe a mesma dependência de conexões SignalR persistentes.

Como funciona

Ao criar páginas utilizando Razor Pages, você possui uma estrutura nativa baseada em HTTP.

Cada página possui sua View e sua camada responsável pelas requisições.

É uma abordagem extremamente eficiente para páginas públicas com grande volume de acessos.

Como construí este projeto

O site que você está acessando utiliza uma arquitetura híbrida.

As páginas públicas foram construídas utilizando Razor Pages.

Já o dashboard utiliza Blazor Render Modes.

Gráficos e recursos mais pesados ficam executando no cliente quando faz sentido.

Funcionalidades administrativas, como gerenciamento de artigos, utilizam Server Side para proporcionar uma experiência mais próxima de uma SPA.

E, se necessário, ainda posso integrar bibliotecas JavaScript e sincronizá-las com C# com pouca dificuldade.