Sharp Dressed Web: Playing with the newest frameworks

Posted by Phil on August 06, 2018

Microsoft's latest experimental framework (their words; not mine) is managed code that runs natively in the browser. Named Blazor, it uses C# and Razor right alongside HTML playing nicely together using the black magic that is WebAssembly.

I've been messing around with this since a former coworker came back from a Microsoft event a year or so ago raving about a cool new technology he'd seen in one of the sessions. Microsoft make no secret that this is a very early iteration and will likely see plenty of changes before it's considered mature, so like all good developers everywhere, I immediately decided that this was the new promised land and I was going to write all my code on this framework for the rest of my life now.

A quick intro

To give you a quick one-liner, Blazor doesn't use plugins or transpilers (and despite the cynical comparisons, it is absolutely not "Java applets all over again"). It runs in the browser on a real .NET runtime (Mono) implemented in WebAssembly that executes normal .NET assemblies.

Essentially, WebAssembly ("Wasm" for short) is a technology link between the JavaScript API and the web API. Loosely described, it allows us to write managed "back end" code and embed that as part of a browser page to operate with front end technologies like JavaScript and HTML.

The core of WebAssembly itself is actually completely independent of the web. The browser is a particular environment that Wasm is embedded in, but that's not actually required to use wasm.

Some probable questions

"Is it a JavaScript killer?"

No.

"Is it a JavaScript framework killer?"

Potentially? Much of what we see in JS frameworks today (e.g. Angular, KnockOut, Aurelia) tries to solve the problem of two-way data binding between the front end UI and a server side data source. Blazor brings these closer together by allowing us to work directly with JavaScript and HTML APIs without having to duplicate a pile of services, models, controllers and other artifacts in two places.

Essentially, I don't have to replicate my whole architecture in JavaScript, which is something commonly seen at least for Angular solutions. Also, I don't need to download a truck ton of dependencies just to wire up a basic starter site. Having managed code running directly on my pages reduces the quantity of assets I need to concurrently manage on my site.

Having said that, it's possible we'll see new JS frameworks that are designed around Wasm architectures and new friction points they yield.

"Do I still work with JavaScript in the same way?"

Not quite. The Blazor runtime needs to be made aware of JavaScript functions so that it can - if necessary - work with them. To accomplish this, Microsoft introduces the JavaScript Interop: conceptually akin to a register of functions that your managed code needs to pass to Wasm in order for those functions to have visibility of all the browser APIs. It's worth pointing out at this point just how "under active development" the Blazor framework is. In the time it's taken to write this post (started editing a couple of days ago), Microsoft have already changed the JavaScript Interop implementation.

The code looks like this:

window.exampleJsFunctions = {
  showPrompt: function (message) {
    return prompt(message, 'Type anything here');
  }
};

And in the Blazor functions (i.e. what was traditionally the "server-side" code):

public static Task<string> Prompt(string message)
    {
        // Implemented in exampleJsInterop.js
        return JSRuntime.Current.InvokeAsync<string>(
            "exampleJsFunctions.showPrompt",
            message);
    }

According to the announcement post, "Blazor promises to greatly simplify the task of building fast and beautiful single-page applications that run in any browser". They've achieved that (in my view). Granted the framework is still in a very infantile stage, but Steve Sanderson and Microsoft have made a huge effort to point that out: it's still regarded as "experimental" until the powers that be figure out whether a supported, shipping product has legs.

Tools and Support

I've been moving more and more to Visual Studio Code as my primary IDE of choice but still fall back to VS 2017 from time to time. The experience of working with Blazor in VS Code is very good, although the intellisense isn't always as reliable as Visual Studio proper. This doesn't really get in the way though, and I've found I'm just as efficient regardless of any assistance that may or may not be available in my IDE.

Blazor does require a restart of the dotnet debugging process for any changes applied to a page or its components. Because pages are effectively compiled down to components and sent to the browser, non-cosmetic changes (including structural HTML content changes) are cached and a recompile needs to happen first before new changes are picked up. The Roslyn compiler makes this process much cleaner in Visual Studio.

One simultaneously hilarious and ominous things I've seen from the project so far is the cross-platform support: Firefox and Chrome seem to have no problem running all aspects of Blazor, but wouldn't you know it, IE11 struggles. Promises aren't supported in IE and it looks like the ASP.Net team aren't interested in trying to shoe-horn polyfills in there either, so there's yet more evidence suggesting that Internet Explorer has run its natural course.

 

I'm thoroughly enjoying writing apps against this framework. I genuinely believe this could be a significant change in the application / SPA landscape for the web. Much like the introduction of MVC fundamentally changed the way ASP.Net applications were written on its introduction in 2009, Blazor may be about to pave the way forward for a whole new generation of application architectures. I definitely recommend having a look soon.

 

Photo Credit

Olu Eletu