.NET Blazor

Artigo original ↗ Discussão no Hacker News ↗

Blazor, a framework de UI web da Microsoft baseada em .NET que executa C# no navegador ou no servidor, está atraindo tanto entusiasmo quanto ceticismo entre desenvolvedores. Os defensores elogiam sua forte ergonomia para o desenvolvedor, o reaproveitamento de código com backends .NET existentes e os novos recursos do .NET 8, como renderização estática e modos “auto”, que combinam servidor e WebAssembly para apps internos de negócios. Os críticos apontam cargas úteis WASM grandes, dependência de estado persistente no servidor, integração mais fraca com o ecossistema mais amplo de JavaScript e o histórico da Microsoft de abandonar frameworks de UI, argumentando que frontends mais convencionais em JS/TS com APIs desacopladas são uma aposta mais segura no longo prazo.

Full‑stack vs especialização

  • Debate sobre se desenvolvedores de backend e frontend devem convergir para funções “full‑stack”.
  • Alguns argumentam que a especialização é necessária para gestão de risco, confiabilidade e UX; outros observam que equipes pequenas e fundadores solos frequentemente atuam em backend, frontend, operações e mais.
  • Um tema recorrente: mesmo que as pessoas possam fazer tudo, organizações maiores preferem responsabilidade clara e especialistas de domínio.

O ponto ideal percebido do Blazor

  • Muitos veem o Blazor (especialmente o Server) como ideal para ferramentas internas de linha de negócios, painéis de administração e apps de intranet onde polimento de UX, SEO e tamanho de bundle ultrabaixo importam menos.
  • Forte apelo para empresas .NET e devs mais orientados a backend: reutilizar habilidades em C#, compartilhar modelos/validação com o backend e evitar stacks frontend separadas.
  • Alguns relatam rodar com sucesso apps Blazor em produção (geralmente em pequena/média escala) e elogiam a produtividade.

Desempenho, arquitetura e modos de renderização

  • Preocupações com Blazor WASM: downloads iniciais de vários MB, uso de CPU e overhead de interop com JS; outros observam que muitos sites são maiores e que o cache mitiga isso em desktops corporativos.
  • Blazor Server é criticado por estado no servidor por cliente, fragilidade de WebSocket, problemas de reconexão e escalabilidade; defensores dizem que é suficiente para uso típico em intranet.
  • O .NET 8 “static/SSR + enhanced navigation + auto mode” é descrito como uma melhoria importante, combinando renderização no servidor com WASM opcional e reduzindo as compensações de UX anteriores.
  • Alguns ainda veem qualquer estado persistente no servidor como uma “bomba-relógio” arquitetural em comparação com HTTP sem estado.

Experiência de desenvolvedor vs ecossistema JS

  • Vários comentaristas acham o Blazor muito mais simples do que as modernas stacks SPA de JS/TS: menos dependências, menos tooling de build, IDEs melhores e interação mais suave com proxy corporativo/antivírus.
  • Outros preferem fortemente TypeScript + SPAs convencionais, argumentando que, com governança, o tooling de JS é gerenciável e mais portátil entre backends.
  • Reclamações sobre a rotatividade do ecossistema JS e tooling frágil contrastam com reclamações de que os próprios “batteries” do .NET frequentemente ficam 50–90% prontos e depois são superados.

Confiança e longevidade

  • Ceticismo profundo enraizado em tecnologias UI/RIA anteriores da Microsoft: Silverlight, WebForms, UWP, Xamarin etc. Muitos temem outra onda de descontinuação e migrações difíceis.
  • Contraponto: Blazor é open source, construído sobre WebAssembly e padrões, e .NET/WinForms mostram que a Microsoft muitas vezes dá suporte a plataformas por muitos anos.
  • Alguns aconselham desacoplar frontend e backend via APIs de qualquer forma, para que um dos lados possa ser substituído se o Blazor (ou React, Vue etc.) cair em desuso.

Reflexões mais amplas sobre a stack web

  • Vários notam que todos os ecossistemas mudam: frameworks JS, stacks Java EE, toolkits GUI de desktop. Nenhuma escolha garante estabilidade de longo prazo.
  • Alternativas mencionadas incluem SPAs em Vue/React com tipos TS gerados por OpenAPI, SSR + pequenas adições no estilo Hotwire/LiveView, htmx e análogos em Java como GWT ou Vaadin.