Blazor van de Grond Af: Hoofdstuk 1 — Wat is Blazor?

Welkom bij Hoofdstuk 1 van Blazor van de Grond Af. Als je de introductiepost hebt gemist waarin ik uitleg wat deze serie is en voor wie die bedoeld is, begin dan daar — het is kort.

In dit hoofdstuk beantwoorden we de fundamentele vraag: wat is Blazor? Dat klinkt eenvoudig, maar het antwoord heeft meerdere lagen — zeker omdat “Blazor” door de jaren heen iets andere betekenissen heeft gekregen. Aan het einde van dit artikel weet je wat Blazor is, hoe het past in het .NET-ecosysteem, wat de verschillende renderingmodellen zijn en waarom je het wel — of niet — zou kunnen kiezen boven een JavaScript-framework.

Een korte geschiedenis

Blazor begon als een experimenteel project van Steve Sanderson bij Microsoft rond 2017. Het idee was provocatief: C# in de browser uitvoeren via WebAssembly, waarmee de noodzaak voor JavaScript volledig zou worden geëlimineerd. Het was een proof of concept, en de naam was een bewuste samenvoeging van Blazer en Razor — de template-engine waarop Blazor uiteindelijk gebouwd zou worden.

Het experiment genereerde genoeg enthousiasme dat Microsoft het serieus nam. Blazor werd in september 2019 uitgebracht als onderdeel van ASP.NET Core 3.0 — eerst als Blazor Server: een model dat je C#-code op de server uitvoert en een realtime SignalR-verbinding gebruikt om UI-updates naar de browser te sturen. Blazor WebAssembly volgde in mei 2020 als onderdeel van ASP.NET Core 3.1, waarmee echte client-side uitvoering aan het framework werd toegevoegd.

.NET 6 en 7 verfijnden de ontwikkelaarservaring. Vervolgens dacht .NET 8, uitgebracht in november 2023, het renderingmodel fundamenteel opnieuw uit met wat Microsoft full-stack web UI noemde. Statische server-side rendering, streaming rendering, interactieve server, interactieve WebAssembly en een nieuwe Auto-modus leefden nu allemaal onder één dak in een enkel project. .NET 9 bouwde verder op deze basis en effende de ruwe kanten.

Dat is waar we vandaag staan.

Wat Blazor werkelijk is

Blazor is in de kern een op componenten gebaseerd UI-framework voor .NET. Je bouwt je gebruikersinterface op uit componenten — zelfstandige eenheden van C# en HTML-markup die toestand kunnen bewaren, op gebeurtenissen kunnen reageren en tot grotere structuren kunnen worden samengesteld. Als je met React of Vue hebt gewerkt, zal dit mentale model vertrouwd aanvoelen. Het cruciale verschil is dat je in plaats van JavaScript C# schrijft.

Componenten in Blazor worden geschreven in .razor-bestanden. Een .razor-bestand combineert HTML-markup met C#-code met de Razor-syntaxis die je misschien al kent van ASP.NET MVC-views. Zo ziet een eenvoudig component eruit:

@page "/counter"

<h1>Teller</h1>
<p>Huidige stand: @currentCount</p>
<button @onclick="IncrementCount">Klik mij</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

Geen JavaScript te bekennen. De @onclick-directive koppelt de klik op de knop aan een C#-methode. De @currentCount-expressie geeft de huidige waarde weer. Als de toestand verandert, bepaalt Blazor wat er in de DOM bijgewerkt moet worden.

Dat is de kern. Alles andere — routing, dependency injection, formulieren, HTTP-aanroepen — is gebouwd op dit componentmodel.

De renderingmodellen

Hier schuilt veel verwarring, dus laten we precies zijn. “Blazor” verwijst tegenwoordig naar een familie van renderingmodi, niet naar één enkel deploymentmodel. Het verschil begrijpen is belangrijk, omdat het van invloed is op prestaties, infrastructuurvereisten en wat je componenten wel en niet kunnen doen.

Statische SSR

De eenvoudigste modus. Je Razor-componenten worden op de server naar HTML gerenderd en die HTML wordt naar de browser gestuurd. Geen permanente verbinding, geen WebAssembly en standaard geen client-side interactiviteit. Dit is in essentie wat Razor Pages doet, maar met het componentmodel.

Gebruik dit voor contentrijke pagina’s, landingspagina’s, alles wat geen live interactiviteit nodig heeft.

Interactieve Server

Je componentcode wordt op de server uitgevoerd. Er wordt een SignalR WebSocket-verbinding tot stand gebracht tussen de browser en de server. Als je op een knop klikt of in een invoerveld typt, reist de gebeurtenis via de WebSocket naar de server, wordt je C# uitgevoerd, wordt de diff berekend en worden de DOM-updates teruggestuurd naar de browser.

Voordelen: Volledige toegang tot serverbronnen (databases, bestandssysteem, geheimen). Snelle initiële laadtijd. Kleine downloadgrootte. Werkt in browsers zonder WebAssembly-ondersteuning.

Nadelen: Elke gebruikersinteractie vereist een serverreis heen en terug, wat latentie toevoegt. Serverbronnen schalen met het aantal actieve verbindingen. De app degradeert als de verbinding verbreekt.

Gebruik dit voor bedrijfsapplicaties, interne tools, apps waarbij server-side datatoegang belangrijker is dan offline-mogelijkheden.

Interactieve WebAssembly

De .NET-runtime wordt naar de browser gedownload en je app draait volledig op de client. Na de eerste download werkt de app volledig offline en is elke interactie onmiddellijk — geen serverritten voor UI-logica.

Voordelen: Echte client-side uitvoering. Werkt offline. Verminderde serverbelasting zodra de app geladen is.

Nadelen: Grotere initiële download (.NET-runtime + je app). Langzamere eerste laadtijd. Je hebt een API nodig om toegang te krijgen tot server-side gegevens.

Gebruik dit voor offline-capable apps, tools die onmiddellijke responsiviteit vereisen, scenario’s waarbij serververwerking niet nodig is voor de UI.

Auto-modus

Geïntroduceerd in .NET 8. De app start in de Interactieve Server-modus (snelle initiële laadtijd, niet wachten op WebAssembly-download). Zodra de WebAssembly-bestanden op de achtergrond zijn gedownload, schakelen volgende bezoeken automatisch over naar de WebAssembly-modus.

Dit geeft je de snelle eerste laadtijd van de Servermodus en uiteindelijk de volledige client-side uitvoering van WebAssembly. Het is het meest complexe model om over te redeneren, maar een praktische standaard voor veel apps.

Modi mixen in dezelfde app

In .NET 8 en later ben je niet beperkt tot één renderingmodus voor de hele app. Een marketinglandingspagina kan Statische SSR zijn; het geauthenticeerde dashboard kan Interactieve Server zijn; een datavisualisatiewidget kan Interactieve WebAssembly zijn. Het framework beheert de overgangen.

In deze serie beginnen we met Interactieve Server omdat dat het eenvoudigst werkend te krijgen is en het meest directe mentale model heeft. We verkennen de andere modi naarmate we vorderen.

Hoe Blazor zich verhoudt tot JavaScript-frameworks

Als je met React, Angular of Vue hebt gebouwd, is dit waarschijnlijk de vergelijking die je interesseert.

De overeenkomsten zijn reëel. Het componentmodel van Blazor is opzettelijk vergelijkbaar met dat van React. Je hebt props (Parameters in Blazor), lokale toestand (velden in het @code-blok), lifecycle hooks en hetzelfde communicatiepatroon: data omlaag / gebeurtenissen omhoog. Als je React kent, voel je je binnen een paar uur thuis.

Het cruciale verschil is de taal. In Blazor schrijf je C#. Je bedrijfslogica, validatieregels en datamodellen kunnen allemaal gedeeld worden tussen je Blazor-frontend en je ASP.NET Core-backend. Geen User-klasse meer dupliceren in TypeScript als je die al in C# hebt.

De ecosysteemkloof is reëel maar wordt kleiner. Het npm-ecosysteem is enorm. Het NuGet-ecosysteem voor UI-componenten is kleiner, hoewel het aanzienlijk gegroeid is. Als je een specifieke grafiekbibliotheek of een drag-and-drop-widget nodig hebt, heeft JavaScript nog steeds meer opties. Maar voor de meeste bedrijfsapplicaties is wat beschikbaar is in de .NET-wereld meer dan voldoende.

JavaScript-interoperabiliteit bestaat wanneer je het nodig hebt. Blazor stelt je in staat JavaScript vanuit C# aan te roepen en C# vanuit JavaScript. Voor browser-API’s zonder .NET-wrapper, of wanneer je een bestaande JS-bibliotheek wilt gebruiken, is interop beschikbaar. Het voegt een laag toe, maar het is niet pijnlijk.

Het eerlijke antwoord: als je team volledig uit JavaScript-ontwikkelaars bestaat die een publiek product bouwen waarbij SEO, prestaties en het npm-ecosysteem cruciaal zijn, blijf dan bij JavaScript. Als je team uit .NET-ontwikkelaars bestaat, als je interne of bedrijfsapplicaties bouwt, of als het delen van code tussen frontend en backend voor jou belangrijk is, is Blazor een overtuigende keuze.

Wat je nodig hebt om mee te doen

Voor de rest van deze serie heb je nodig:

• .NET 9 SDK — download van dot.net
• Een IDE — Visual Studio 2022 (Community-editie is gratis), VS Code met de C# Dev Kit-extensie, of JetBrains Rider
• Basiskennis van C# — klassen, properties, interfaces, async/await

Dat is alles. Geen Node, geen npm, geen webpack.

Wat hierna komt

In Hoofdstuk 2 zullen we je eerste Blazor-app opzetten, de projectstructuur doornemen en ervoor zorgen dat je hem lokaal kunt uitvoeren. Aan het einde heb je een werkende app en een duidelijk beeld van wat elk bestand doet.

Tot dan.