Blazor zou hier wel eens verandering in kunnen brengen. Het biedt namelijk de mogelijkheid om een front-end te ontwikkelen, geschreven in een backend taal.  Om specifiek te zijn met behulp van .Net C#. Dit geeft ontwikkelaars met  minder UI ervaring een laagdrempelige instap om een user interface te implementeren in een voor hen bekend ecosysteem.

Wat is Blazor?

Blazor is een front-end framework van Microsoft. Dit framework maakt het mogelijk om .Net te gebruiken in de browser. De front-end wordt geïmplementeerd met behulp van C# en Razor (markup language).

De term Razor zal bekend voorkomen vanuit de MVC-hoek. Het verschil is dat bij MVC Razor wordt toegepast om pagina’s te definiëren. Bij Blazor wordt Razor gebruikt om webcomponenten te maken. Bij Blazor worden daardoor geen full page postbacks gebruikt, maar worden slechts die componenten, die daarvoor in aanmerking komen, in de front-end geüpdatet, bijvoorbeeld na gebruikersinteractie.

Hoe werkt Blazor?

Blazor komt in grofweg 2 smaken, ook wel Hosting Models genoemd. De eerste variant is Blazor Server.

Bij dit hosting model draait er een lichtgewicht front-end in de browser (gegenereerde HTML, CSS en Javascript) en wordt alle logica op de serverzijde uitgevoerd:

Wanneer er iets wijzigt in de front-end door bijvoorbeeld gebruikersinteractie dan wordt dit gecommuniceerd met de server. De server voert vervolgens code uit en stuurt het resultaat terug naar de front-end. Op dat moment verwerkt Blazor het resultaat en bepaalt welke onderdelen in de front-end ververst dienen te worden. De communicatie tussen front-end en server vindt plaats door middel van SignalR.

Het tweede model is Blazor WebAssembly. Dit is te vergelijken met een Single Page Application. In tegenstelling tot de bekende webframeworks maakt Blazor in dit model geen gebruik van Javascript, maar van WebAssembly.

Bij dit model wordt alle logica uitgevoerd in de browser:

Om de front-end te laten functioneren, wordt de .Net runtime gedownload die vervolgens bovenop de WebAssembly laag draait. Het resultaat is een .Net applicatie die binnen de browser draait. Interopabiliteit met Javascript is mogelijk.

Communicatie met een backend kan bewerkstelligd worden door middel van bijvoorbeeld een REST Api, RPC of GraphQL. Dit staat los van de in-browser Blazor applicatie.

Voor- en nadelen

De voordelen van Blazor

  • De codebase kan in 1 taal geschreven worden. Ontwikkelaars met minder kennis van populaire front-end frameworks kunnen toch relatief eenvoudig met Blazor een front-end ontwikkelen. Ook kunnen eenvoudig front- en eventueel backend binnen 1 solution geplaatst worden, wat het ontwikkelen eenvoudiger maakt.
  • Code en componenten kunnen gedeeld worden. Denk bijvoorbeeld aan validatieregels. Een domeinmodel met bijbehorende validatieregels kan zowel in de front- als de backend gebruikt worden.
  • Verder kunnen voorzieningen in het .Net framework gebruikt worden, waardoor het bijvoorbeeld mogelijk is om Dependency Injection toe te passen in de front-end.
  • Daarnaast zijn er volop  componenten beschikbaar binnen de zogenaamde community.
  • Tot slot zal Webassembly bij complexere berekeningen en logica sneller zijn dan Javascript.

De nadelen van Blazor

  • Bij gebruik van de servervariant is er altijd een actieve verbinding vereist anders werkt de applicatie niet meer (dit heeft te maken met de SignalR communicatie).
  • Ook de schaalbaarheid bij de servervariant is een uitdaging. Wederom heeft dit te maken met de SignalR verbinding tussen browser en server. Voor elke verbinding moet de server een state bijhouden. Bij veel gebruikers loopt het geheugengebruik op de server op. Daarnaast moet er extra werk verzet worden om bij meerdere serverinstanties de verbinding naar de juiste instantie te routeren.
  • De webassembly-variant heeft als nadeel dat de laadtijd van de site toeneemt, omdat de .Net runtime mee moet naar de browser (vraag is of dit nu nog een nadeel is, gezien de standaard snelle internetverbindingen + mobiel 4g/5g).
  • Daarnaast is  heeft het debuggen van de webassembly-variant iets meer voeten in de aarde.

Blazor lifecyle

Blazor componenten kennen een zogenaamde lifecyle. Dit stelt de ontwikkelaar in staat om daar waar nodig in te haken op lifecyle-events en custom code uit te voeren.

Meer informatie over de Blazor lifecyle is hier te vinden.

Hello Blazor

Hoe ziet een component in Blazor eruit? De volgende afbeelding is afkomstig van de out-of-the box applicatie, wanneer een Blazor project wordt gecreëerd in Visual Studio:

Op de pagina is een navigatiemenu te zien met een Counter component.

Het Counter component ziet er in Blazor als volgt uit:

Wat je hier ziet is dat de onclick handler geschreven is in C#. Dit is een simpel voorbeeld van hoe een component in Blazor geschreven kan worden. In de Microsoft Blazor Tutorial is dit terug te zien met nog meer voorbeelden.

Een uitgebreider voorbeeld met Dependency Injection (bron):

Door het gebruik van het keyword @inject kan gevraagd worden om de implementatie van een interface. Vervolgens wordt in het ‘lifecycle event OnInitializedAsync’ deze service gebruikt om data op te halen die uiteindelijk in markup gebruikt worden. Uiteraard dienen alle te injecteren services wel eerst geregistreerd te worden. Dit kan op de in .Net bekende manier in Startup.cs.

Een laatste voorbeeld dat illustreert hoe parameters kunnen worden doorgegeven aan componenten. Het eerder beschreven Counter component kan dusdanig herschreven worden, zodat het totaal van de teller in een apart component getoond wordt. Het totaal wordt vanuit het Counter component via een parameter doorgegeven aan een child component die het totaal toont.

Via de TotalCount parameter wordt het totaal doorgegeven aan het CounterTotal component. Via het [Parameter] attribuut kan worden aangegeven dat de property TotalCount wordt gevuld door middel van de parameter die vanuit een parent component wordt meegegeven. Door de databinding via de TotalCount parameter zal in het TotalCount component de teller opgehoogd worden wanneer er in het Counter component op de knop wordt geklikt.

Het TotalCount component:

Unit testing Blazor components

Ondanks het feit dat er (nog) geen officieel Microsoft testframework is voor Blazor is het wel mogelijk om componenten te unit testen. Dit kan bijvoorbeeld met bUnit.

De volgende unit test wordt gebruikt om het correcte functioneren van het incrementeren van het eerder beschreven Counter component te testen:

Meer informatie over unit testen voor Blazor is hier te vinden.

.NET MAUI Blazor – Build Hybrid Mobile, Desktop, and Web apps

Tijdens ons bezoek aan de techorama 2022 editie hebben we ook veel geleerd over de combinatie tussen Blazor en .NET

To Blazor or not to Blazor?

De populariteit van Blazor blijft nog ver achter bij die van bekende front-end technologieën als React, Angular of Vue.js. Blazor is relatief nieuw en veel bedrijven kiezen liever voor een bewezen technologie met een uitgebreid portfolio.

Wel is er een opwaartse trend waarneembaar in het gebruik en toepassen van Blazor, voornamelijk in Amerika.

Wanneer er .Net en C# kennis aan boord is, kan het wellicht lonen om een webapplicatie met Blazor te ontwikkelen. De leercurve is behoorlijk laag vergeleken bij andere front-end technologieën en de afstand tussen front-end en backend development wordt behoorlijk verkleind, omdat er één taal gebruikt wordt. Ook het uitgebreide aanbod aan al bestaande componenten vergemakkelijkt de implementatie. Hierdoor kan er sneller business value geleverd worden.

Of Blazor de komende tijd echt voet aan de grond gaat krijgen, is moeilijk te voorspellen. Veel bedrijven zullen vasthouden aan het bekende. Het zou interessant kunnen zijn om Blazor bij een klein, behapbaar project toe te passen om een duidelijker beeld te krijgen van de (on)mogelijkheden die Blazor biedt.

Samenvatting:

Bij het ontwikkelen van een webapplicatie kom je al snel uit bij het verdelen van werkzaamheden voor front- en backend. Dit heeft te maken met het feit dat binnen een ontwikkelteam bepaalde leden zich comfortabeler voelen om met de UI te werken en andere leden weer wat sterker zijn in het servergedeelte (full stack developers daargelaten)

Inhoud van blog