Artikel Blazor, een inleiding

Ik wil mij graag verdiepen in nieuwe technieken en af en toe kom ik iets tegen wat mij erg aanspreekt. In dit geval is dat Blazor. Hoe het komt dat Blazor mij zo aanspreekt, wil ik graag in deze post beschrijven. Ik experimenteer al met Blazor vanaf versie 0.1.0 uitgebracht in maart 2018. Omdat Blazor nu officieel onderdeel uitmaakt van het .NET framework wordt het tijd om Blazor eens goed onder de aandacht te brengen. In deze eerste post over Blazor leg ik uit wat Blazor is en wat het verschil is tussen Blazor webassembly en Blazor server.

Alweer een nieuw frontend framework?

Alweer een nieuw frontend framework? Er is toch al Angular, Vue and React? Deze vragen hoor ik vaker, maar toch is Blazor anders. Waar een framework zoals bijvoorbeeld Angular een typisch javascript framework is, kan ik als .NET ontwikkelaar met Blazor 'gewoon' C# code blijven schrijven. Of beter gezegd, ik maak webapps met C#, HTML en CSS in plaats van met javascript of typescript. Het voordeel is dat je niet van scratch af aan weer een nieuwe taal en syntax hoeft te leren. Blazor voelt, voor mij als .NET ontwikkelaar, natuurlijk aan. Bijkomend voordeel is dat de leercurve laag is. Toch zijn er ook overeenkomsten met de al bestaande frameworks. Net zoals bijvoorbeeld Angular en React is Blazor 'component based'. Wanneer ik nu een webapp maak in Angular, ontwikkel ik de backend veelal op het .NET Core platform met Web API of gRPC met C# als primaire ontwikkeltaal. Met Blazor kan ik één codebase houden en vanuit mijn Blazor frontend project rechtstreeks gebruik maken van de libraries dit zich in mijn solution bevinden. Met Blazor is het mogelijk om zowel client- als serverside apps te maken.

Wat is Blazor?

Met Blazor kun je webapps ontwikkelen met behulp van C#, HTML en CSS in plaats van javascript. Blazor komt in twee smaken; Blazor webassembly (clientside) en Blazor server (serverside). Blazor webassembly draait in de browser; C# code wordt als bytecode gecompileerd naar webassembly. Dit is in onderstaande afbeelding te zien. Beide varianten worden volledig ondersteunt vanaf het .NET 5 framework.

Blazor webassembly

Met Blazor server wordt de HTML gerenderd op de server en naar de client gestuurd. Dus, UI updates, event handling en javascript calls worden verzorgd door een actieve SignalR connectie naar de server. Blazor server apps worden gehost op de server. Deze apps draaien en gebruiken dus de resources van de server.

Blazor server

Blazor is een mix van Browser en Razor. Blazor gebruikt de Razor syntax voor de views; C# wordt gecompileerd naar webassembly bytecode. Dus, in de browser wordt webassembly bytecode uitgevoerd in plaats van javascript. Op deze manier is de performance van Blazor webapss een stuk beter in vergelijking met javascript. Webassembly wordt door alle moderne browsers ondersteund en is hierdoor niet afhankelijk van een plug-in zoals dat vroeger wel het geval was met Silverlight en Flash. Blazor is een framework dat onderdeel uitmaakt van het .NET framework en draait op de .NET runtime. De tooling voor het ontwikkelen van een Blazor app is goed. Je kan gebruik maken van zowel Visual Studio als Visual Studio Code. In de voorbeelden gebruik ik Visual Studio 2019 (16.8).

Blazor server

Vaak is het niet duidelijk wat het verschil is tussen Blazor webassembly en Blazor server. Dat zal ik hieronder uiteenzetten. Simpel gezegd komt het hierop neer: Blazor server is een app die wordt gehost op een server. Hiervoor is het nodig dat de server is voorzien van het .NET Core (5) framework. De resources van de server worden gebruikt om de app uit te voeren. De pagina word gerenderd op de server en als één geheel naar de client verzonden. Het voordeel hiervan is dat de grootte van de te downloaden pagina klein is en serverside Blazor apps werken op browsers die geen webassembly ondersteunen. Nadeel is dat er sprake kan zijn van een hogere latency, wat de gebuikerservaring nadelig kan beïnvloeden. Iedere interactie veroorzaakt een request naar de server. Een Blazor server app heeft een actieve verbinding naar de server nodig en kan daarom dan ook niet offline functioneren. Blazor server is dan ook goed toe te passen in een thinclient omgeving.

Voordelen

  • De code wordt uitgevoerd op de server, de resources van de server worden gebruikt.
  • De app laadt snel.
  • De client heeft geen browser nodig die webassembly ondersteund.

Nadelen

  • Er is een actieve connectie naar de server nodig.
  • Er is een server nodig die onderhouden moet worden.
  • De app heeft een hogere latency omdat er meer requests over de lijn gaan.

Blazor webassembly

Met Blazor webassembly, wordt de code uitgevoerd op de client. De code wordt gebouwd als .NET Standard dll en is hierdoor herbruikbaar. De code wordt gecompileerd naar een .wasm bestand en wordt uitgevoerd naast de javascript runtime van de browser. De dll wordt geheel inclusief afhankelijkheden en de .NET runtime door de client gedownload en in de browser uitgevoerd. Doordat alle assemblies in de sandbox omgeving van de browser aanwezig zijn, is het mogelijk om een Blazor webassembly app offline, dus zonder actieve verbinding naar een server, uit te voeren.

Het hosten van een Blazor webassembly app is eenvoudig en goedkoop. De app kan gehost worden op een CDN, een eigen server of als static website in Azure.

Voordelen

  • De app is snel, de performance is hoog. De app biedt een 'near native' ervaring.
  • De app werkt offline.
  • Deployment is simpel en goedkoop.

Nadelen

  • De app wordt door de browser beperkt; deze draait in een 'sandbox'.
  • Alle assemblies en afhankelijkheden moet worden gedownload, dit kost tijd.
  • De configuratie wordt opgeslagen in de assemblies die worden gedownload. Hierdoor bestaat het risico dat er gevoelige informatie op een client wordt opgeslagen.

Blazor in actie

Ik laat nu in een voorbeeld zien wat de verschillen zijn tussen een Blazor server en Blazor webassembly app. Wij beginnen met het selecteren van de Blazor app template in Visual Studio.

Blazor template

In de volgende stap kan er gekozen worden voor een Blazor webassembly of een Blazor server app. Ik heb Visual Studio 2019 solution gemaakt waar beide apps in zitten. Dit zijn beide standaard apps, er is geen code gewijzigd. Aan de hand van dit voorbeeld laat ik de verschillen zien tussen beide varianten.

Blazor verschil

Het Blazor server project bevat in de wwwroot directory alleen CSS en javascript; het Blazor webassembly project bevat naast CSS ook een index.html. In de index.html zit een referentie naar een blazor.webassembly.js javascript bestand. Deze referentie zorgt ervoor dat de afhankelijkheden en de bytecode versie van de .NET runtime door de app kunnen worden gedownload en zorgt er tevens voor dat de app wordt geïnitialiseerd en gestart.

Ditzelfde verschil zie je in de Razor componenten in de Pages map. Het Blazor serverproject heeft een _Hosts.cshtml bestand waarin eenzelfde verwijzing zit naar de blazor.webassembly.js. Dit zorgt voor een websocketconnectie waarmee met behulp van SignalR de communicatie verzorgd wordt tussen de client en de server.

Verder zie je dat beide projecten dezelfde Razor componenten bevatten. Het is dus mogelijk om code te delen tussen het server project en het webassembly project.

Een ander verschil is te zien in de Startup class in het Startup.cs bestand. In het Blazor server project worden de services, middleware voor het opzetten van de SignalR connectie en configuratie geladen. In het webassembly project is de Startup class afwezig.

Ten slotte gaan wij kijken wat het verschil is tussen een Blazor server een Blazor webassembly app in de browser.

Server demo

Zoals te zien is in de afbeelding hierboven kan de teller in de app worden verhoogd door op de 'Click me' button te klikken. De UI wordt door middel van een actieve SignalR connectie bijgewerkt. Zoals je kan zien in het developer tools venster, onder in de afbeelding, is er alleen wat CSS en javascript geladen. Er zijn geen afhankelijkheden naar webassembly of het .NET frameork te zien. Dit maakt dat een Blazor server app snel geladen is; nadeel is, zoals eerder gezegd, dat er een active SignalR connectie naar de server moet zijn.

In de afbeelding hieronder is te zien dat er in het geval van een Blazor webassembly app alle .NET afhankelijkheden worden geladen. Dit maakt dat het voor de eerste keer opstarten van de app langer duurt, maar dat de app wel een native performance biedt omdat deze gebruik maakt van de resources van client. De .NET afhankelijkheden worden opgeslagen in de cache van de browser. Dit maakt dat een Blazor webassembly app alleen de eerste keer een langere opstarttijd nodig heeft.

Client demo

Tot slot

Met deze blogpost heb ik laten zien wat er in potentie met Blazor mogelijk is en wat het verschil is tussen Blazor webassembly en Blazor server. Ik heb een aantal handvaten willen geven die je helpen een goede afweging te kunnen maken, bij je keuze voor een Blazor server app of Blazor webassembly app. Blazor is nog volop in ontwikkeling en ik hoop dat Blazor zich in de komende tijd gaat bewijzen als serieus alternatief voor de bestaande frameworks zoals Angular, React en Vue.js.

Links

WebAssembly - https://webassembly.github.io/
SignalR - https://docs.microsoft.com/en-us/aspnet/core/signalr/introduction?view=aspnetcore-5.0
.NET Standard - https://dotnet.microsoft.com/platform/dotnet-standard