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

October 15, 2019 · 4 minute read · Tags: blazor | core

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.)

Unleash Blazor's Potential

Blazor promises to make it much easier (and faster) to build modern, responsive web applications, using the tools you already know and understand.

Subscribe to my Practical ASP.NET Blazor newsletter and get instant access to the vault.

In there you'll find step-by-step tutorials, source code and videos to help you get up and running using Blazor's component model.

I respect your email privacy. Unsubscribe with one click.

    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).

    Join the Practical ASP.NET Newsletter

    Ship better Blazor apps, faster. One practical tip every Tuesday.

    I respect your email privacy. Unsubscribe with one click.

      Next up

      The quickest way to integrate PayPal checkout with Blazor SSR in .NET 8
      JavaScript Interop works differently with Blazor Server-side rendering
      Interactive what now? Deciphering Blazor’s web app project template options
      Create a new Blazor Web App and you’ll be asked how you want interactivity to work, but what does it all mean?
      Should I put my Blazor components in the server project, or the client project?
      .NET 8 gives you a choice of projects, which one should you use?