Steve Sanderson’s Blazor is an experiment to bring .NET back to the browser using WebAssembly. It isn’t meant to be a full production framework like Flash or Silverlight, but rather a test to see what’s possible.
WebAssembly describes itself as a standard for “a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines.” While it will perform better in browsers that natively support it, WebAssembly can be interpreted by older browsers using a converter and asm.js.
Currently WebAssembly is designed primarily to support C and C++ applications. It acts as a compiler backend for clang/LLVM. To get from C to C#, Blazor used another research project. Chris Bacon’s DotNetAnywhere was a C-based interpreter for .NET’s Common Intermediate Language (a.k.a. IL, CIL, MSIL). The DotNetAnywhere project ended about six years ago.
Blazor makes the following changes to DotNetAnywhere:
- To support building with Emscripten
- To support p/invoke calls from .NET to JavaScript
- To add other interop primitives, e.g., GCHandle
- To receive inbound calls from JavaScript to .NET
- To fix some bugs
- To support loading .NET Core-style assemblies
Blazor applications are built using Razor templates that are executed in the browser rather than on the server. According to the documentation, a simple “hello world” application requires 300KB download. This includes “everything: the small .NET runtime, core libraries, application code, and wrapper libraries needed to bootstrap and interop with the WebAssembly code”.
No effort has been made to strip out code that isn’t actually called, so it's possible to reduce this size even further.
To see this in action, watch the NDC Conference video titled Web Apps can’t really do *that*, can they? - Steve Sanderson.