Technology Radar
Blazor
Wat is Blazor?
Blazor is Microsofts framework voor het bouwen van interactieve web-UI's met C# in plaats van JavaScript. Het kent meerdere render-modi: Blazor Server (UI-events lopen via een SignalR-verbinding naar de server), Blazor WebAssembly (de .NET-runtime draait in de browser via WASM) en sinds .NET 8 een hybride model met server-side rendering en per component te kiezen interactiviteit. De belofte: full-stack ontwikkeling binnen één taal en één ecosysteem, met herbruikbare componenten en zonder aparte frontend-stack.
Voordelen
- Eén stack, één taal : Teams met sterke C#/.NET-kennis kunnen frontend en backend bouwen zonder JavaScript-specialisten. Modellen, validatielogica en DTO's zijn deelbaar tussen client en server.
- Volwassen tooling : Visual Studio/Rider, NuGet, vertrouwde test-frameworks en een eersteklas integratie met ASP.NET Core (authenticatie, DI, configuratie).
- Actief doorontwikkeld : Microsoft positioneert Blazor als zijn primaire web-UI-investering; .NET 10 bracht verbeterde JS interop, persistent state en performancewinst.
- Componentmodel : Razor-componenten zijn goed herbruikbaar en libraries als MudBlazor en Telerik bieden een redelijke basis.
Nadelen
- Foutgevoelige JS interop : Zodra je buiten het componentmodel moet (en dat moet je vrijwel altijd: focus, scroll, charts, third-party widgets), beland je in JS interop. In de praktijk levert dit structureel fouten op.
- Fragiel runtime-model (Server) : Blazor Server hangt aan een permanente SignalR-verbinding. Netwerkonderbrekingen, server-restarts en deployments betekenen verbroken circuits, verloren UI-state en reconnect-schermen voor de gebruiker.
- WebAssembly-kosten : Blazor WASM kent een forse initiële download en merkbaar tragere interop dan native JavaScript;
- Complexe render-modi : Sinds .NET 8 moet je per component redeneren over SSR, prerendering, Server- of WASM-interactiviteit. Dit maakt gedrag moeilijk voorspelbaar.
- Kleiner ecosysteem en arbeidsmarkt : Het aanbod aan componenten, tooling en ervaren ontwikkelaars is een fractie van dat van React, Vue of Angular.
Conclusie
Wij plaatsen Blazor op Hold. De belofte "geen JavaScript nodig" blijkt in de praktijk niet houdbaar: elke niet-triviale applicatie eindigt alsnog bij JS interop, maar dan via een abstractielaag die extra foutklassen introduceert in plaats van wegneemt. De onderhoudslast en onvoorspelbaarheid die dit oplevert wegen voor ons zwaarder dan het voordeel van één taal.
Voor nieuwe projecten adviseren wij een bewezen frontend-framework (React, Vue of Angular) met een ASP.NET Core API. Daarmee behouden teams hun .NET-kracht op de backend en krijgen ze een frontend met een groter ecosysteem, betere debugbaarheid en ruimer beschikbare expertise.
Uitzonderingen zijn denkbaar: interne tools met beperkte interactiviteit, een team dat uitsluitend uit .NET-ontwikkelaars bestaat zonder ruimte om frontend-kennis op te bouwen, of bestaande Blazor-applicaties waar herbouw niet opweegt tegen doorontwikkelen. In die gevallen geldt: kies bewust voor één render-modus, minimaliseer JS interop en isoleer interop-code achter een eigen abstractie met defensieve foutafhandeling.
Voor bestaande Blazor-projecten is migratie niet urgent — het framework wordt actief onderhouden — maar wij raden aan nieuwe investeringen kritisch te bezien.