Blazor e o Futuro da Web
Blazor e o futuro da web viraram assunto frequente depois que publiquei meu primeiro conteúdo sobre o framework, um vídeo em que mostro algumas funcionalidades básicas em menos de 15 minutos. O vídeo provocou vários comentários e perguntas nas minhas redes sociais, desde pessoas odiando a ideia até pessoas querendo colocar em produção.
Vale lembrar que, quando escrevi este texto, a versão WebAssembly do Blazor ainda estava em preview. Por isso, este artigo discute o Blazor, o WebAssembly e o que essa alternativa traz de benefícios, sem tratá-la como substituta imediata de nada.
JavaScript é ruim?
Todo mundo já fez alguma piadinha infame com o JavaScript, e isso é fato. Outra realidade é que a linguagem realmente não nasceu para ser o que é hoje.
Em 1995, a Netscape criou o JavaScript apenas para manipular alguns elementos na tela, e pronto. Ninguém imaginava que ele sustentaria aplicações inteiras dentro do navegador.
Porém, ele é indiscutivelmente uma das linguagens mais utilizadas no mundo. Enquanto um dev Java, C# ou PHP conhece JavaScript por tabela, o contrário quase nunca acontece.
Além disso, aprender JavaScript costuma ser bem menos doloroso para quem está começando do que aprender linguagens tipadas. Se você está nessa fase, vale ler o que é JavaScript antes de seguir.
A chegada do V8 e do Node.js
Em 2008, com a chegada do Chrome, o Google apresentou o V8, uma engine que não apenas interpretava o JavaScript. Ela compilava o código, trazia um profiler e outros recursos que deram um gás na linguagem.
Essa foi a primeira grande mudança, e ela ajuda a entender o debate sobre Blazor e o futuro da web. A partir daí, o JavaScript evoluiu tanto que o Node.js, construído sobre o V8, passou um bom tempo à frente de .NET, PHP e Java em alguns cenários.
Lembro que, em 2012, quando comecei com Node, ele suportava muito mais requisições que essas outras plataformas nos meus testes. E era tudo JavaScript.
SPAs, PWAs e o JavaScript moderno
Outra grande mudança veio com as SPAs. Em vez de processar tudo no servidor e devolver o HTML pronto, passamos a trazer apenas os dados em JSON e processar mais coisas na tela.
Processar mais no cliente significa mais JavaScript, mais processador e mais memória. Particularmente, acho que tivemos uma boa evolução também no hardware, já que existem smartphones com 8 GB de RAM.
Hoje falamos de PWAs, de aplicações com sensação de nativas e de substituir apps nativos por apps web. Então, ainda dá para dizer que JavaScript é ruim?
O JavaScript de hoje não é o mesmo de antigamente. A especificação ECMAScript recebe atualizações anuais, recursos novos chegam todo ano e temos até um superset incrível para ele, o TypeScript.
Na minha humilde opinião, JavaScript é a linguagem do presente e do futuro, sim, e nenhuma discussão sobre Blazor e o futuro da web muda isso. Mesmo com suas limitações, ele continua sendo uma ótima linguagem.
Por que WebAssembly?
Mas, se o JavaScript é bom, por que precisamos do WebAssembly, ou WASM? Para responder a essa pergunta, primeiro precisamos entender o que é o WASM.
Segundo o site oficial do WebAssembly, ele é um formato de instrução binário para uma máquina virtual baseada em pilha. Em outras palavras, ele funciona como um alvo de compilação portátil para várias linguagens.
Sabemos que linguagens interpretadas tendem a ser mais lentas que as compiladas. Então, por que não compilar nossos apps web e executá-los como fazemos com os nativos?
Isso traria um ganho grande de performance para a aplicação, e é aqui que Blazor e o futuro da web se encontram. Além disso, o formato binário tende a ser mais compacto e mais rápido de decodificar do que o texto.
Um detalhe importante é que o WebAssembly não nasceu como projeto de uma única empresa. Pelo contrário, Mozilla, Google, Microsoft e Apple trabalharam juntas no formato, e os quatro navegadores passaram a suportar a primeira versão em 2017.
Essa colaboração explica por que o WASM ganhou tração tão rápido. Afinal, um padrão que todos os navegadores implementam tem muito mais chance de durar.
Então não vou mais usar JavaScript?
No futuro, talvez você possa optar com mais tranquilidade por outra linguagem no lugar do JavaScript. Porém, ainda existe muita coisa escrita em JavaScript, e algumas limitações do WASM vão te obrigar a escrever JavaScript de vez em quando.
Por exemplo, o WebAssembly não acessa o DOM diretamente. Por isso, frameworks como o Blazor usam uma ponte de interoperabilidade com JavaScript para atualizar a tela.
Outro ponto importante para pensar em Blazor e o futuro da web é que o WASM não concorre com o JavaScript. Podemos invocar métodos JavaScript direto de aplicações escritas em outras linguagens e, por exemplo, ter as duas na mesma aplicação.
No Blazor, essa ponte acontece por meio do IJSRuntime. Veja um exemplo simples de um componente chamando uma função do navegador:
@inject IJSRuntime JS
<button @onclick="ShowAlert">Show alert</button>
@code {
private async Task ShowAlert()
{
// Chama a função alert do navegador a partir do C#
await JS.InvokeVoidAsync("alert", "Hello from C#");
}
}
Eu também acredito que a comunidade JavaScript é uma das mais fortes que temos e vai durar um bom tempo. Além disso, a própria linguagem evolui, e cada ano ela melhora.
Concorrência gera coisa boa
Por que falar de Blazor e WASM se defendo tanto o JavaScript? Porque acredito que a concorrência faz as coisas melhorarem, e isso vale para o Blazor e o futuro da web.
Nada como uma linguagem de peso como o C# para dar aquele susto e fazer o JavaScript evoluir para sua melhor versão. Afinal, foi a competição entre engines que transformou a performance do JavaScript a partir de 2008.
Além disso, acredito que o mercado é grande demais para ser dominado por apenas uma linguagem ou uma stack. Então, quanto mais opções, melhor.
O que o Blazor representa para o futuro da web
O Blazor é o projeto da Microsoft que leva o C# para o navegador. Ele tem duas formas de uso: o modelo client/server, que conversa com o servidor via SignalR, e o modelo WebAssembly.
O que estou comparando aqui é a versão WASM, que ainda estava em preview na época deste texto e é a que mais me interessa. Para entender os dois modelos em detalhe, confira esta visão geral do Blazor.
O Blazor nada mais é do que a possibilidade de criar aplicações web usando puramente C#. Mesmo assim, você continua invocando o backend via HTTP, como em qualquer SPA.
Ou seja, o modelo da aplicação não muda, e todas as limitações que temos no cliente continuam. Portanto, o Blazor e o futuro da web dependem mais de produtividade e de reaproveitamento de código do que de mágica.
Onde o Blazor se encaixa no futuro da web
Na minha visão, o Blazor faz mais sentido para times que já trabalham com C# e .NET. Nesse caso, a mesma linguagem atende backend e frontend, o que reduz a troca de contexto no dia a dia.
Além disso, o Blazor permite compartilhar código entre servidor e cliente. Por exemplo, os mesmos modelos e as mesmas regras de validação podem rodar na API e na tela, sem duplicação em duas linguagens.
Aplicações internas, painéis administrativos e sistemas de linha de negócio são bons candidatos. Afinal, nesses cenários o tamanho do download inicial pesa menos do que a produtividade do time.
Por outro lado, sites públicos que dependem de carregamento instantâneo pedem mais cuidado. Portanto, avalie Blazor e o futuro da web com calma, olhando para o seu contexto e não apenas para a novidade.
Vantagens e limitações do Blazor WebAssembly
A documentação de hosting models do Blazor lista bem os prós do modelo WebAssembly. Por exemplo, o app pode funcionar sem servidor .NET depois do download, aproveita os recursos do cliente e alivia o processamento do servidor.
Além disso, um app standalone pode ficar hospedado como arquivos estáticos em uma CDN. Isso abre caminho para cenários como criar um PWA com Blazor WASM.
Por outro lado, o download inicial fica maior, porque o navegador baixa o runtime .NET junto com a aplicação. Também é preciso lembrar que todo código enviado ao cliente pode ser inspecionado, então regras sensíveis continuam no servidor.
Por fim, o desempenho depende do modo de execução. Na versão que eu testava, o runtime interpretava o IL, e só mais tarde a Microsoft adicionou compilação ahead-of-time para gerar WebAssembly direto a partir do .NET.
Blazor e o futuro da web: isso é o futuro?
WASM, com certeza. Já faz um tempo que dizemos que o WebAssembly é o futuro da web e que o JavaScript conviverá com ele, inclusive como ponte para linguagens de mais baixo nível.
Em dezembro de 2019, o W3C publicou o WebAssembly como recomendação oficial, ao lado de HTML, CSS e JavaScript. Com isso, o formato deixou de ser experimento e virou padrão da web.
Já em relação ao Blazor e o futuro da web, tudo depende da adoção do mercado e do suporte ao WASM nos navegadores. Recentemente tivemos uma grande vitória com a adoção do WASM pela Apple no Safari do iOS, como mostra o Can I use.
Mesmo assim, ainda era cedo para cravar algo sobre o Blazor quando escrevi este texto. Portanto, minha recomendação continua a mesma: estude, teste e acompanhe a evolução antes de apostar tudo nele.
Eu também gravei um vídeo falando o que poderia acontecer de ruim com o Blazor. Embora seja um vídeo antigo e algumas coisas já tenham melhorado, ele ainda traz pontos de vista bem válidos.
Se você quiser explorar mais o lado do WebAssembly, também temos um conteúdo sobre WASM e o futuro da web. Ele complementa esta discussão com o ponto de vista do próprio formato.
Como se preparar para o Blazor e o futuro da web
Independentemente da stack que você escolher, os fundamentos da web continuam valendo. Por isso, HTML, CSS e JavaScript seguem como conhecimento obrigatório para qualquer desenvolvedor front-end.
Se você já trabalha com .NET, experimente o Blazor em um projeto pequeno. Dessa forma, você sente na prática o modelo de componentes, a interoperabilidade com JavaScript e o tamanho final da aplicação.
Também vale acompanhar a evolução da especificação do WebAssembly e o suporte dos navegadores. Afinal, Blazor e o futuro da web dependem diretamente do que os browsers passam a oferecer.
Por fim, não trate nenhuma tecnologia como bala de prata. Na prática, o melhor profissional entende as opções e escolhe a ferramenta certa para cada problema.
Conclusão sobre Blazor e o futuro da web
O JavaScript evoluiu muito desde 1995 e continua sendo a base da web. Ao mesmo tempo, o WebAssembly abre espaço para que outras linguagens rodem no navegador com boa performance.
Nesse cenário, o Blazor é a aposta da Microsoft para levar o C# ao front-end. Em outras palavras, ele não substitui o JavaScript, mas amplia as opções de quem já vive no ecossistema .NET.
Por fim, quando penso em Blazor e o futuro da web, vejo concorrência saudável. Quanto mais alternativas boas existirem, mais todas as stacks evoluem, e quem ganha somos nós, desenvolvedores.
FAQ
O Blazor substitui o JavaScript?
Não, o Blazor convive com o JavaScript e usa interoperabilidade para acessar APIs do navegador. Muitas bibliotecas continuam escritas em JavaScript e podem ser chamadas a partir do C#.
O que é WebAssembly em poucas palavras?
É um formato binário de instruções que os navegadores executam com performance próxima à nativa. Várias linguagens, como C, C++, Rust e C#, podem ter o WebAssembly como alvo.
Quais são os modelos de hospedagem do Blazor?
O Blazor pode rodar no servidor, conectado ao navegador via SignalR, ou no cliente, sobre WebAssembly. O modelo de componentes é o mesmo nos dois casos.
O WebAssembly é suportado em todos os navegadores?
Os principais navegadores modernos suportam WebAssembly, incluindo o Safari no iOS. Você pode conferir o suporte atualizado no site Can I use.
Vale a pena aprender Blazor?
Para quem já trabalha com C# e .NET, o Blazor reduz a troca de contexto entre backend e frontend. Mesmo assim, conhecer JavaScript continua importante para qualquer desenvolvedor web.