.NET Blazor

Artículo original ↗ Discusión en Hacker News ↗

Blazor, el framework de interfaz web basado en .NET de Microsoft que ejecuta C# en el navegador o en el servidor, está generando tanto entusiasmo como escepticismo entre los desarrolladores. Sus partidarios elogian su buena ergonomía para desarrolladores, la reutilización de código con backends .NET existentes y las nuevas funciones de .NET 8 como el renderizado estático y los modos “auto”, que combinan servidor y WebAssembly para aplicaciones internas de negocio. Sus críticos señalan cargas útiles WASM grandes, la dependencia de estado persistente en el servidor, una integración más débil con el ecosistema JavaScript más amplio y el historial de Microsoft abandonando frameworks de UI, argumentando que frontends más convencionales en JS/TS con APIs desacopladas son una apuesta más segura a largo plazo.

Full‑stack vs especialización

  • Debate sobre si los desarrolladores de backend y frontend deberían converger en roles de “full‑stack”.
  • Algunos argumentan que la especialización es necesaria para la gestión de riesgos, la fiabilidad y la UX; otros señalan que los equipos pequeños y los fundadores en solitario abarcan rutinariamente backend, frontend, ops y más.
  • Un tema recurrente: incluso si la gente puede hacerlo todo, las organizaciones grandes prefieren una propiedad clara y expertos de dominio.

El punto óptimo percibido de Blazor

  • Muchos ven Blazor (especialmente Server) como ideal para herramientas internas de negocio, paneles de administración y apps de intranet donde el pulido de UX, el SEO y un tamaño de bundle ultrabajo importan menos.
  • Atractivo fuerte para empresas .NET y desarrolladores orientados al backend: reutilizar habilidades en C#, compartir modelos/validación con el backend y evitar stacks frontend separados.
  • Algunos informan haber ejecutado con éxito apps Blazor en producción (a menudo a pequeña/mediana escala) y elogian la productividad.

Rendimiento, arquitectura y modos de renderizado

  • Preocupaciones sobre Blazor WASM: descargas iniciales de varios MB, uso de CPU y sobrecarga de interop con JS; otros señalan que muchos sitios son más grandes y que la caché lo mitiga en equipos corporativos.
  • Blazor Server es criticado por estado del servidor por cliente, fragilidad de WebSocket, problemas de reconexión y escalabilidad; sus defensores dicen que va bien para el uso típico de intranet.
  • .NET 8 “static/SSR + enhanced navigation + auto mode” se describe como una mejora importante, que combina renderizado en servidor con WASM opcional y reduce las compensaciones de UX anteriores.
  • Algunos siguen viendo cualquier estado persistente en el servidor como una “bomba de tiempo” arquitectónica frente a HTTP sin estado.

Experiencia de desarrollo vs ecosistema JS

  • Varios comentaristas encuentran Blazor mucho más simple que las pilas modernas de SPA en JS/TS: menos dependencias, menos herramientas de build, mejores IDEs e interacciones más fluidas con proxies corporativos/antivirus.
  • Otros prefieren fuertemente TypeScript + SPAs convencionales, argumentando que con gobernanza el tooling de JS es manejable y más portable entre backends.
  • Las quejas sobre la rotación del ecosistema JS y el tooling frágil contrastan con las quejas de que las “baterías incluidas” de .NET a menudo están terminadas al 50–90% y luego son sustituidas.

Confianza y longevidad

  • Escepticismo profundo arraigado en la historia pasada de tecnologías UI/RIA de Microsoft: Silverlight, WebForms, UWP, Xamarin, etc. Muchos temen otra oleada de obsolescencia y migraciones difíciles.
  • Contrapunto: Blazor es de código abierto, está construido sobre WebAssembly y estándares, y .NET/WinForms muestran que Microsoft a menudo da soporte a plataformas durante muchos años.
  • Algunos aconsejan desacoplar frontend y backend mediante APIs de todos modos, para que cualquiera de las dos partes pueda ser reemplazada si Blazor (o React, Vue, etc.) cae en desgracia.

Reflexiones más amplias sobre la pila web

  • Varios señalan que todos los ecosistemas cambian: frameworks de JS, pilas de Java EE, toolkits GUI de escritorio. Ninguna opción garantiza estabilidad a largo plazo.
  • Entre las alternativas mencionadas están SPAs con Vue/React y tipos TS generados desde OpenAPI, SSR + sprinkles al estilo Hotwire/LiveView, htmx y análogos en Java como GWT o Vaadin.