Nå kommer C# også i nettleseren – for forretningsapplikasjoner

Webassembly-teknologien, som gjør det mulig å kjøre nær sagt alle former for kode og kjøremiljøer i moderne nettlesere, er nå kommet så langt at det er mulig å overveie å skifte ut Javascript på klienten med det språket som utvikleren foretrekker – og kanskje allerede bruker på serversiden.

Det kan være språk som C# og Java, som er populære valg til forretningsapplikasjoner.

Det mener i hvert fall Ed Charbeneau fra firmaet Telerik, som utvikler kommersielle og ikke-open source brukergrensesnitt-biblioteker til Javascript og .Net.

På Øredev-konferansen som ble avholdt i Malmø nylig, fortalte han om åpen kildekode-rammeverket Blazor, som Microsoft har utviklet. Det gjør det mulig å utvikle klientprogrammer som kjører i en nettleser, med språket C# og .Net, og med en serverbasert Plan B i bakhånd. Det siste skal vi komme tilbake til.

– Jeg kan gjenbruke de ferdigheter jeg allerede har, så jeg ikke trenger å skifte mentalt fra C# til noe helt annet, svarer Ed Charbeneau på spørsmålet om hva som er så bra med Blazor.

Mental tilstand bevares

– Verktøyene er de jeg allerede bruker, som MS Build, Visual Studio, osv. Før Blazor kom, måtte du skrive serverkoden din i C# og skifte til Javascript, Webpack og Npm for frontend-utviklingen. Noen ganger bruker folk også forskjellige kodeverktøy til de to forskjellige oppgavene. Forskjellen mellom de to teknologiene er så stor, at du skifter til en helt annen mental tilstand.

Men begge språk, Javascript og C#, er likevel objektorienterte – påpeker Version2s utsendte reporter. Så forskjellen kan vel ikke være så stor?

– Syntaksen er forskjellig, det ene bruker typer og det andre ikke. Javascript fungerer annerledes enn C#, hvor du kan kompilere en DLL-fil og regne med at det virker i kjøremiljøet. Det er mange nyanser som gjør det forskjellig. Feedback fra feil er helt annerledes. C# har typer, så når noe går galt kan man gå gjennom stacken med kall for å finne feilen, og man får en intelligent og meningsfylt feilmelding. I Javascript får man ofte noe i stil med «undefined», og så prøver du å finne ut av hvor denne «undefined» kommer fra. Det er vanskeligere å feilrette.

Men det er ikke fordi Charbeneau har noe imot Javascript, eller språk som «transpileres» – altså oversettes til Javascript, som for eksempel Typescript.

– Det er ikke noe galt med det. Det er heller ikke noe galt med Javascript. Det er bare annerledes. Typescript prøver å legge et type-lag på toppen av Javascript. Det er et slags kompromiss mellom C# og Javascript. Med Blazor er det ikke noe kompromiss – jeg bruker de verktøy jeg hadde fra før.

Runtime på 2 megabyte

Første gang brukeren kjører en Blazor-applikasjon, må nettleseren laste ned et bibliotek på 2 megabyte – og det er en del, innrømmer Charbeneau.

– Microsoft ser på om firmaet kan gjøre det mindre ved å for eksempel fjerne kode som ikke brukes. Firmaet ser på kompresjon, caching og Content Distribution Network (CDN). Det fulle .Net-rammeverket endrer seg kun én gang i året.

Nettleseren kan cache rammeverket, og når det er lastet ned første gang så kjører den neste applikasjonen også på den – og krever altså ikke nedlasting på 2 megabyte. Man kan også skape progressive web-apper, som er web-apper som lastes ned og kjøres lokalt på klienten. Det kan også caches, og man kan bruke det som et vanlig skrivebordsprogram, og installere det på samme måte.

Det gamle spørsmålet om nettleser-kompatibilitet spøker imidlertid i bakgrunnen.

– Det er et innviklet problem. Mange virksomheter bruker eldre nettlesere. Det vil alltid være et problem. Men Blazor er kompatibel med alle «eviggrønne» nettlesere som oppdateres automatisk, det vil si Chrome, Firefox, Edge og Safari.

På serversiden er Blazor kompatibel med Internet Explorer 11 via såkalte «polyfills». Serverside-Blazor kjører med kun en liten smule Javascript-kode og en websocket-forbindelse.

Serverside-kjøring med litt binær diff

Serverside-Blazor er en annen måte å kjøre applikasjoner i rammeverket på, uten Webassembly. Det gir nettopp utvidet kompatibilitet.

– På serversiden er det samme rammeverk, men kan kjøre som en .Net-applikasjon på serveren, og nettleseren brukes som en tynnklient.

Første «push» består av hele view-et, og når forbindelsen er etablert sender Blazor deretter en «diff» – kun de dataene som skal oppdateres – i et binært format som ikke tar mye plass, ofte kun få bytes.

Det gjør det mulig å unngå den tidligere nevnte payload av rammeverket på 2 megabyte. Utover dette har man mulighet for å utføre oppgaver på serveren som kanskje er for tunge for klienten. Serversiden har også mindre abstraksjon mellom data og applikasjonen, så det er for eksempel ikke behov for eksterne HTTP-kall. Det er effektivt, spesielt i forbindelse med utviklerhastighet og -omkostninger.

Blazors rammeverk kjører på Mono, som er en åpen kildekode-versjon av .Net, og et rammeverk til Webassembly. Det er ikke mye adgang fra Webassembly til nettleseren og dens dokument- og event-modell, så her brukes det små biter Javascript som binder Webassembly sammen med nettleser og web-side.

– Det er skjult i en abstraksjon, så jeg ser det ikke som utvikler – jeg skriver kun i C#. Hvis jeg skulle ha bruk for Javascript, har jeg imidlertid mulighet for det.

Det er et godt grensesnitt mellom Javascript og rammeverket, som kjøres i Webassembly, mener Charbeneau.

Det er så enkelt som å kalle en Javascript-funksjon, som knyttes til dokument-modellens Window-objekt. Det kan for eksempel være å tilknytte en event som skal utløses når brukeren endrer størrelsen på nettleservinduet. Det krever kun litt Javascript.

Tiden er inne for Webassembly for forretningsapplikasjoner

Nå blir intervjuet litt pikant, for Version2 snakket med Ed Charbeneaus gode kollega TJ VanToll fra samme firma på Gotocph-konferansen for 12 måneder siden. Den gang sa TJ VanToll:

– Jeg har hørt snakk om Webassembly i åresvis, og jeg har ennå ikke sett en praktisk situasjon der det blir brukt. Det kommer nok til å spille en større rolle i forbindelse med for eksempel spill, hvor ytelse er kritisk, men til de fleste forretningsapplikasjoner er Javascripts ytelse ikke et problem. Det er viktigere å være produktiv, og Typescript gjør nettopp det. De fleste utviklere vil ofre litt ytelse, hvis det betyr at de kan få tingene gjort litt raskere.

Charbeneau kommer seg ut av den kollegiale kattepinen på diplomatisk vis:

– Det var et korrekt utsagn på daværende tidspunkt. Tingene har endret seg en hel del i løpet av det siste året, og Blazor er en av de tingene. Det jobbes også mye andre steder i Webassembly-miljøet som det er verdt å kikke nærmere på, som innenfor programmeringsspråket Rust.

Tidligere har spill vært et fokus for Webassembly, da de ytelsesmessige fordelene er innlysende – men forretningsapplikasjoner er det nyeste bruksområdet på plattformen. Her går Blazor foran, mener Charbeneau.

– Kommer vi til å se mer C# og Java i nettleseren, og vil Javascript bli skjøvet ut?

– Jeg tror Javascript nok vil forbli trygt der det er i dag. Jeg tror også vi vil se mange utviklere som bruker .Net-teknologi som vil skifte til Blazor.

Det gjelder særlig de som har jobbet med .Net-teknologier som Silverlight, WPF, MVC og Webforms, sier Charbeneau.

Kanskje er det noen C#-utviklere som har vært tvunget til å utvikle frontends med Javascript, og som ikke er glade for det – og heller vil tilbake til C#.

– Mange sier at eksempelvis Angular-biblioteket til Javascript kan være skremmende, så noen vil gjerne tilbake. Jeg tror dog ikke vi kommer til å se et stort skifte, der alle bare forlater Javascript, mener Charbeneau.

Men det er en tendens. Det er enklere for en virksomhet kun å satse på ett sett ferdigheter hos utviklerne. Det samme har vi sett med mobil-kryssplattformsmiljøet Xamarin.

– Folk tvilte på det først, men flere år senere er Xamarin fortsatt her – og det spiller en stor rolle for Microsoft i dag.

Saken ble først publisert på danske Version2/Ingeniøren, og gjøres tilgjengelig på norsk for abonnenter av Digi Ekstra gjennom vår samarbeidsavtale med Teknologiens mediehus/Ingeniøren.