Quando se trata de tomar uma decisão entre várias coisas-de objetos físicos a software-você precisa garantir que os objetos estejam todos relacionados entre si ou ajudem a alcançar objetivos semelhantes e, portanto, são comparáveis.
Isso é especialmente verdadeiro quando se trata de comparar estruturas. Para fazer uma comparação excelente e justa, é necessário comparar coisas na mesma categoria, com as mesmas características básicas. Todas as bibliotecas/estruturas do SPA têm o mesmo objetivo e Blazor não é exceção.
Mas existem algumas diferenças que podem fazer você reconsiderar compará-lo a outras estruturas JavaScript. Aqui está o porquê.
O que é Blazor?
Blazor é uma estrutura da web para a construção de interfaces de usuário modernas e interativas baseadas na web com C # e Razor. O Blazor pode ser executado em WebAssembly ou no servidor. É também a primeira e única estrutura de front-end com suporte comercial que utiliza WebAssembly.
Normalmente, quando falamos de desenvolvimento de front-end, as pessoas pensam imediatamente em JavaScript, mas com o Blazor as coisas são diferentes. Como? Porque:
- Você escreve seu aplicativo em C # e Razor
- O compilador.NET compila seu código em.NET CIL (intermediário comum Idioma)
- Seu aplicativo é fornecido com Mono WASM Runtime (BlazorWASM)
- Seu navegador executa binários do Mono e seu aplicativo Assemblies
Vou cobrir o BlazorServer posteriormente neste artigo, vamos nos limitar ao WebAssembly primeiro.
Execução de códigos.NET no Blazor e WebAssembly
Para ver as diferenças na ação, estou usando um modelo padrão do Blazor. Tenho .NET 5 instalado em minha máquina. Você pode fazer o scaffold do projeto pela linha de comando abaixo:
dotnet new blazorwasm
Para ver como ele compila o projeto, execute o seguinte comando:
dotnet publish-c Release-o./output
Ele compila e apara os assemblies de saída.NET para reduzir o tamanho do aplicativo. Dentro da pasta de saída, pasta _framework , você verá todos os assemblies. Para pessoas com experiência em.NET, a maioria desses arquivos DLL são familiares.
Você pode perguntar onde está o WebAssembly. Observe que ao lado dessas DLLs, existe o arquivo dotnet.wasm com o tamanho de 2,65 MB; esse é o próprio tempo de execução dotnet. Para ver como o aplicativo se parece e funciona, assista ao seguinte vídeo:
Ele carrega tudo o que é necessário e executa códigos.NET na parte traseira.
Razões para evitar comparação direta com outras estruturas do SPA
1. WASM
A saída do Blazor é WASM, ao contrário de outros frameworks/bibliotecas SPA (Angular, Vue, React, etc.). WASM é o novo padrão e o futuro. Em vez de executar seus códigos no mecanismo JS do navegador, o navegador executa seu aplicativo em um formato binário .
O runtime do.NET/Mono é compilado para WASM e o resto do seu projeto ainda são arquivos DLL do.NET Assembly. A equipe e a comunidade.NET estão trabalhando muito para fornecer WASM AOT para que você pode compilar todo o projeto em bytecode WASM.
WASM é rápido e já está compilado. Não precisa ser analisado ou interpretado e o navegador o executa como está. É tão rápido quanto o código nativo. É excelente para casos de alto desempenho, como edição de imagem, renderização 3D, videogames, criptografia e assim por diante.
2. Benefícios do.NET e C #
Um rico conjunto de bibliotecas no ecossistema.NET : Existem toneladas de bibliotecas poderosas que os desenvolvedores estão usando em aplicativos de desktop ou back-end. Com o Blazor, você também pode utilizá-los em seu aplicativo de front-end.
C #, linguagem digitada estaticamente : C # fala por si-não preciso promovê-lo. É poderoso e, graças à sua natureza e às ferramentas que já existem, refatorar a base de código C # e.NET é fácil como uma torta de maçã e com menos chance de falha.
Siga a arquitetura do padrão de design e um código mais limpo : já está usando várias bibliotecas para melhor estrutura e design do aplicativo? Você precisa de injeção de dependência ? Reflexão? Que tal o padrão MediatR ? Analisadores estáticos? Tudo já existe no Blazor. É maduro, testado em batalha e padrão do setor.
Base de código compartilhada : o benefício de usar.NET e WASM mostra seus valores aqui. Você já tem diferentes camadas e serviços em seu aplicativo.NET de back-end. Usar o código compartilhado do back-end para o front-end não será problema.
Por exemplo, considere um cenário no qual você já tem uma camada de validação e segurança para suas entradas porque você já as escreveu para seu back-end. Por que você deve reescrevê-los para o seu front-end? Com o Blazor, basta fazer referência ao mesmo projeto e usá-lo como foi escrito para o front-end.
Remova a lacuna entre o desenvolvimento de front-end e back-end : com a mentalidade de compartilhar a base de código, o desenvolvimento do front-end não deve ser tão diferente do back-end-pelo menos em teoria.
Quase sem JavaScript : você pode escrever todo o seu aplicativo no mesmo idioma para o back-end e front-end. Você pode pensar: “ Ok, mas isso também é possível com aplicativos Node; tanto o backend quanto o frontend são escritos em ES/TS/JS. O navegador em si entende JS/ES, então sua linguagem de back-end e front-end será a mesma para os desenvolvedores de Node. ”
Mas o que é diferente com o Blazor é que você escreve seu aplicativo em C # e ele será executado como WASM e.NET no navegador-o mesmo código, sem nenhuma mágica como o que o babel e o webpack fazem. Não usar JS pode beneficiar os aplicativos padrão e os desenvolvedores que não estão familiarizados com o desenvolvimento de front-end porque ele usa a mesma linguagem para quase tudo.
Há um motivo para eu dizer “quase”. O código WASM não pode acessar o DOM diretamente (ainda), mas existem algumas soluções alternativas para obtê-lo. Blazor suporta JS interoperabilidade ; com isso, é fácil chamar JS do.NET dentro do navegador.
3. Possibilidade de portar um aplicativo legado ou desktop para a web
Com o Blazor, tudo gira em torno de WASM e.NET. Para empresas e desenvolvedores que têm aplicativos significativos que ainda não são aplicativos da web, eles podem, com algum esforço para reprojetar a parte da GUI, portar seu aplicativo para a web!
Mesmo em outras linguagens, como C ++, Rust, etc., há suporte nativo para WASM.
4. BlazorServer
BlazorServer é diferente de ServerSide Render. Você pode ativá-lo em seu projeto BlazorWasm com a ajuda do modo de servidor, o que significa que toda a lógica será executada no servidor e as alterações refletirão no frontend.
Não sou muito fã desse recurso, mas é uma grande ajuda em muitos casos. É mais seguro porque tudo está sendo executado no servidor, mas há latência.
Este recurso ajuda desenvolvedores e empresas a economizar tempo no desenvolvimento de aplicativos. Eles desenvolvem front-end e back-end ao mesmo tempo e podem ser hospedados em um contêiner do Docker.
Se quiser saber mais, leia este documento da equipe.NET.
Conclusão
WASM e.NET são duas funcionalidades do Blazor que tornam difícil a comparação com outros frameworks e bibliotecas SPA. Cada ferramenta tem contras e pontos positivos, mas no final, eles tentam fornecer um conjunto de ferramentas de alta qualidade para permitir que os desenvolvedores façam produtos excelentes.
Na minha opinião, o Blazor é excelente, especialmente para empresas que desejam migrar seu aplicativo legado para a web. Ele dá aos desenvolvedores a opção de aproveitar todo o poder do.NET em seus aplicativos para criar aplicativos robustos.
Trabalhar com o Blazor não é tão diferente de outras estruturas, mas lembre-se de que, com o Blazor, você desenvolverá em C # e poderá enfrentar problemas ao usar algumas bibliotecas JavaScript em seu projeto.
Esperançosamente, a comunidade e as empresas que criaram componentes Blazor excelentes continuarão a adicionar ferramentas robustas. O futuro é brilhante para o desenvolvimento web. Não importa se é WASM ou aplicativos da web JS/ES modernos. O resultado é um aplicativo robusto produzido por você e sua equipe.
A postagem Por que você deveria compare o Blazor com outras estruturas JavaScript SPA apareceu primeiro no LogRocket Blog .
