Blazor for skeptikere

I lang tid så jeg ikke meningen bag Blazor. Hvad skal vi bruge det til, og er det ikke bare ligesom Razor, WPF og andre lignende frameworks?

Siden 2018 har mine kollegaer, især de der har deres primære fokus på C#, snakket meget om Blazor, hvor vildt det var og at det skulle være fremtiden for frontend-udvikling.

Jeg må indrømme, at jeg altid har været skeptisk. Da jeg først hørte om det var alle mine associationer knyttet til Razor pages fra ASP.NET, som jeg ikke havde de bedste erfaringer med. Hvis man gerne ville have den typestærke tilgang, hvorfor ikke bare bruge Typescript. Hvad er problemet i at snakke med et GraphQL API gennem en JS klient?

Hvis du har det som jeg, er du kommet til det rette sted. I det følgende vil jeg forsøge at redegøre for hvilke dele af Blazor hypen der kan retfærdiggøres, og hvor jeg tror evangelisterne tager fejl, samt hvor vi som skeptikere måske har misforstået Blazor.

Det bliver ikke en lang gennemgang, men jeg linker løbende videre til en del kilder hvis du er interesseret i at lære mere.

Hvad er Blazor?

Blazor udnytter introduktionen af WebAssembly (WASM) i 2015, til at muliggøre eksekvering af C# på klient-siden af en webapplikation.

Blazor er et frontend framework for SPA (Single-Page Applikation), som bruger C# som fullstack. Blazor gør det dermed muligt at skrive klient-side applikations-kode i C#, uden at skulle gøre brug af JavaScript, som du ellers ville gøre det med jQuery, Angular, React og lignende. Tanken er at Blazor i din webapplikation skal erstatte disse JS-frameworks.

Kombineret med en .NET Core backend, muliggør det at have .NET kode end-to-end. En .NET backend udvikler bliver pludselig en fullstack udvikler, i stand til også at skrive klient-koden i webapplikationen.

Hvordan virker Blazor?

Der er som udgangspunkt to udgaver af Blazor. Der er den server-side renderede udgave, og så er der den klient-side renderede. Hver har sine fordele og ulemper, men fordelen ved dem begge er at det er samme kode, der bruges begge steder.

Ved server-side rendering sendes alle UI ændringer fra serveren til browseren via SignalR. På den klient-renderede udgave, sendes DLL’er til klienten, som så renderes af dotnet.wasm. Klientudgaven (WebAssembly udgaven) er hvad vi bedst kan sammenligne med moderne JS frameworks så som Angular & React.

Debugging oplevelsen

Debugging af koden kan ofte være en stor del af arbejdet. Derfor er det også meget relevant for os at se på hvordan den oplevelse egentligt vil være i Blazor i forhold til traditionel frontend (JavaScript).

Med frameworks som Angular & React vil en stor del af debugging oplevelsen foregå direkte i browseren med de indbyggede værktøjer der er at finde her. Det er også muligt at debugge direkte i browseren med Blazor, men det kræver lidt ekstra opsætning, og er ikke en lige så lækker oplevelse som det er det for JavaScript/TypeScript. En uddybende gennemgang af hvordan debugging af Blazor fungerer kan findes på StackOverflow.

Fordelene ved Blazor

Blazor introducerer, sammen med WebAssembly, et nyt paradigmeskifte for den måde vi tænker frontendudvikling.

Gør det muligt at eksekvere C# i din frontend
- Bryder JS monopolet på frontend
- Hvis du allerede kender C# har du lynhurtigt også en frontend, uden at du behøver være programmerings polyglot
Hurtig udvikling, kort Time To Market
- Det er nemt for en enkelt udvikler at producere både frontend og backend, og sende begge dele til produktionsserveren
Baseret på WebAssembly
- Muligt at dele forretningslogik & validering i både front og backend
.NET IL har potentialet for at være hurtigere end JavaScript kode. Dette kan gøre Blazor til det foretrukne værktøj ved udvikling af spil og andre performance-afhængige applikationer
Hvis du ikke er glad for WPF, kan du forholdsvist nemt bruge Blazor sammen med WPF i .NET6
Blazor applikationer er natively stateful
Samme kodebase for web, desktop & mobil
Samme kodebase for WPA, native & hybride cross-platform apps

Ulemperne ved Blazor

Desværre kommer Blazor ikke uden sine egne udfordringer.

Blazor kan ikke arbejde med DOM elementerne direkte. Derfor vil der fra tid til anden være brug for JavaScript Interop, til at udfylde de huller denne manglende funktionalitet resulterer i. Det er derfor i mange tilfælde ikke muligt helt at droppe javascript.
Blazor er i øjeblikket (2021) langsommere end JavaScript. Microsoft har dog en god track record i forhold til performance optimeringer, så dette skulle gerne være et mindre problem på længere sigt
Debugging er ikke en lige så god oplevelse som den er det ved etablerede JS frameworks.

Renderingsspecifikt

Alt efter hvilken renderings-tilgang du bruger, har de også hver deres ulemper.

WASM renderer:

Stor payload.
- Ud over at skulle downloade applikationens WASM og .NET biblioteker til browseren, skal Mono.wasm også hentes ned.
- En “Hello World” applikation har en payload på ca. 1Mb i .NET 6, men det løber efter sigende hurtigt op i 5-6Mb når man først har en færdig applikation. Nogle melder om +10Mb.
- 1Mb for en “Hello World” applikation er meget når man sammenligner med størrelsen på andre frontend frameworks: https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1
- Lazy loading kan løse lidt af disse problemer, men det er stadig noget begrænset og omstændigt

Serverside renderer:

Kræver konstant adgang til backend.
- Hvis forbindelsen brydes, stopper applikationen med at virke, indtil forbindelse kan genetableres
- Hvis serveren genstartes, vil applikationen stoppe med at virke og state tabes
Svært at skalere, klienten vil kun fungere med den server som gemmer dens state. Kan løses med Sticky Sessions i SignalR
Ikke muligt at lave til en PWA
Introducerer en del crosstalk frem og tilbage mellem klient og server. Kan give store problemer hvis responstid er høj / hvis du er en mobil-bruger

Kombinering af serverside & WASM

Med ulemperne ved henholdsvis klient-rendering og serverside-rendering, kan det være svært at finde det oplagte sted at bruge Blazor. Især hvis man er afhængig af at applikationen starter hurtigt op.

Det er dog muligt at køre en hybrid af de to renderinger, ved at køre en hybrid løsning. Sergey Zaikin har lavet en gennemgang af hvordan han formåede at løse denne hybrid Blazor opsætning i et demoprojekt.

Konklusion

Blazor er et stærkt værktøj, i den rette usecase.

Som landskabet for Blazor ser ud lige nu, er Blazor rigtigt stærkt hvis du laver enterprise applikationer, hvor du er sikker på at dine brugere altid tilgår applikationen med en computer. Hvis dine brugere bruger mobile enheder, skal du være villig enten til at:

Lade dine brugere vente et stykke tid på at applikationen er indlæst (WASM)
Acceptere at applikationen ikke kan virke offline (ServerSide)

Blazor viser rigtigt sine styrker når der er tale om at størstedelen af applikationen består af CRUD operationer mod en .NET backend. Især fordi man så har muligheden for at dele forretningslogik mellem backend og frontend gennem webassembly. Denne centralisering af fx valideringslogik gør det noget nemmere at vedligeholde komplekse forretningsgange.

I fremtiden vil payload på download af mono.wasm, .NET DLL’er samt applikationens DLL’s blive mindre og mindre. Vi har allerede set dette da vi gik fra .NET core til .NET5. Og .NET6 ser også ud til at give massive performance forbedringer.

Hvis Blazor skal blive bredt accepteret som en platform for webudvikling, er der dog stadig et behov for nedbringelse af payload. Det er en hård konkurrence at skulle kæmpe med JavaScript, når JavaScript eksekverer direkte i browseren, uden at være afhængige af at skulle køre ovenpå en runtime skrevet i WebAssembly (som skal hentes ned som det allerførste i applikationens levetid).

Jeg kan ikke forestille mig en fremtid hvor Blazor erstatter JavaScript. Blazor vil derimod sikkert blive som så mange andre frameworks, biblioteker og værktøjer. Nogle vil undgå det, andre vil omfavne det. Uagtet vil internettet forsætte sin vante udvikling, præcis som vi har set det med udviklingen af de forskellige JavaScript frameworks.