.NET Blazor

Original Article ↗ Hacker News Discussion ↗

Blazor, Microsoft’s .NET-based web UI framework that runs C# in the browser or on the server, is drawing both enthusiasm and skepticism among developers. Supporters praise its strong developer ergonomics, code reuse with existing .NET backends, and new .NET 8 features like static rendering and “auto” modes that blend server and WebAssembly for internal business apps. Critics point to large WASM payloads, reliance on persistent server state, weaker integration with the broader JavaScript ecosystem, and Microsoft’s history of abandoning UI frameworks, arguing that more conventional JS/TS front ends with decoupled APIs are a safer long-term bet.

Full‑stack vs specialization

  • Debate over whether backend and frontend devs should converge into “full‑stack” roles.
  • Some argue specialization is necessary for risk management, reliability, and UX; others note small teams and solo founders routinely span backend, frontend, ops, and more.
  • A recurring theme: even if people can do everything, larger orgs prefer clear ownership and domain experts.

Blazor’s perceived sweet spot

  • Many see Blazor (especially Server) as ideal for internal line‑of‑business tools, admin panels, and intranet apps where UX polish, SEO and ultra‑low bundle size matter less.
  • Strong appeal for .NET shops and backend‑oriented devs: reuse C# skills, share models/validation with backend, and avoid separate frontend stacks.
  • Some report successfully running Blazor apps in production (often small/medium scale) and praise productivity.

Performance, architecture, and rendering modes

  • Concerns around Blazor WASM: multi‑MB initial downloads, CPU usage, and JS interop overhead; others note many sites are larger and caching mitigates it for corporate desktops.
  • Blazor Server criticized for per‑client server state, WebSocket fragility, reconnection issues, and scalability; defenders say it’s fine for typical intranet usage.
  • .NET 8 “static/SSR + enhanced navigation + auto mode” is described as a major improvement, blending server render with optional WASM and reducing earlier UX trade‑offs.
  • Some still see any persistent server state as an architectural “time bomb” compared to stateless HTTP.

Developer experience vs JS ecosystem

  • Multiple commenters find Blazor far simpler than modern JS/TS SPA stacks: fewer dependencies, less build tooling, better IDEs, and smoother corporate‑proxy/AV interactions.
  • Others strongly prefer TypeScript + conventional SPAs, arguing that with governance JS tooling is manageable and more portable across backends.
  • Complaints about JS ecosystem churn and fragile tooling contrast with complaints that .NET’s own “batteries” are often 50–90% finished and later superseded.

Trust and longevity

  • Deep skepticism rooted in past Microsoft UI/RIA tech: Silverlight, WebForms, UWP, Xamarin, etc. Many fear another deprecation wave and difficult migrations.
  • Counterpoint: Blazor is open source, built on WebAssembly and standards, and .NET/WinForms show that Microsoft often supports platforms for many years.
  • Some advise decoupling frontend and backend via APIs regardless, so either side can be replaced if Blazor (or React, Vue, etc.) falls out of favor.

Broader web stack reflections

  • Several note that all ecosystems churn: JS frameworks, Java EE stacks, desktop GUI toolkits. No choice guarantees long‑term stability.
  • Alternatives mentioned include Vue/React SPAs with OpenAPI‑generated TS types, Hotwire/LiveView‑style SSR+sprinkles, htmx, and Java analogs like GWT or Vaadin.