There's a buzz about Blazor - Here's why

Blazor has landed (albeit only officially supported in “Server” mode for now) and with it comes renewed optimism that javascript isn’t going to be the only front end game in town for the rest of eternity.

But can it, will it, should it ever replace Javascript?

If you’re currently committed to building Web APIs and applications using Vue/Angular/React are you destined to chuck everything in the bin and start all over again from zero?

Honestly? Probably not.

But, having seen the enthusiasm for Blazor at recent conferences and “out there” (the Internet, not aliens), I’m increasingly of the opinion that Blazor is a very good thing;

Here are three reasons why.

Alternatives are important

It’s tempting to assume that everyone has got over their objections to JS, embraced the ecosystem in its entirety and are now happily spinning round on their JS framework treadmill, churning out PWAs and SPAs to their heart’s content.

But, as one person succinctly outlined on /r/dotnet…

“I hate everything about javascript”

Who knows how this person really feels… but it’s fair to assume that some people have not jumped on the JS bandwagon and aren’t exactly happy about the prospect of doing so in the near future.

If you know C# and you’re comfortable operating within the .NET ecosystem, having a JS alternative which enables you to be productive, spin up “modern” web applications which are performant, using the tools you already know and love, sounds like a pretty good option to have up your sleeve.

Web Assembly isn’t just Microsoft

You’ve probably read about the two “modes” which Blazor can run in.

Blazor Server, available now, does all the heavy lifting on the server, transmitting a small amount of data up to the browser to tell it what to render in response to things happening within your application (button clicks etc.)

But Blazor Server is just the start. When Blazor WebAssembly drops next year, you’ll be able to deploy actual .NET DLLs to the browser.

Those DLLS will run on a version of the .NET runtime (in the browser) making it a fully-fledged SPA which happens to be written using C#.

This is enabled thanks to WebAssembly which is built into all modern browsers.

WebAssembly opens up the browser to run languages other then JS, and you can be sure Microsoft aren’t the only company exploring what this means and how they can best make use of it.

Chances are we’re going to see the browser move into areas it previously couldn’t, running more diverse applications as the technology matures and improves.

JS is still a big part of this picture, with WebAssembly able to call into and out of the JS context, but the options will be there to bring the tools and languages you already know to the party.

Shared models between browser and server is a BIG deal

If there’s one pain point which springs up again and again with full stack development it’s the problem of multiple versions of the same model.

With a typical JS based application you’re likely to end up with one version of your Model on the backend (strongly typed, in C# land) and then a completely separate representation of it in javascript (possibly typed if you’re using Typescript).

Keeping these in sync is a royal pain in the ass. It’s really only a matter of time before something changes on the back end causing a breaking change in the front end.

Code generation partially solves this problem, or at least removes the manual process otherwise required to keep the two in sync but still leaves you with two versions of the same model.

Blazor removes the problem entirely.

@inject HttpClient _httpClient

<h3>People</h3>

@foreach (var person in people)
{
    <h1>Hello @person.Name</h1>
}

@code {
    protected List<Person> people { get; set; } = new List<Person>();

    protected override async Task OnInitializedAsync(){
        await LoadPeople();
    }

    private async Task LoadPeople(){
        people = await _httpClient.GetJsonAsync<List<Person>>("http://yourapi.com/people");
    }
}

This is an example of Blazor Client (Web Assembly) using a model Person which is retrieved via an HTTP call to an API.

Just the ability to deserialise the API response into the Person model removes any realistic chance of breaking this application simply by making changes to its models.

(you also get intellisense, which is nice).

Next up