I’m just going to say it right from the start, .NET running in the browser. No plugins, no add-ons, no weird transpilation voodoo. THIS IS NOT Silverlight. Just .NET running in the browser.
If you’re a .NET developer who’s even remotely interested in web development I should firmly have your attention. Now what if I told you it’s not just an idea. But a reality and you can go and try it for yourself right now?… Say hello to Blazor.
A Word On WebAssembly
Before I go into detail about what the Blazor project is, first let’s cover WebAssembly. If you’ve never heard of WebAssembly or know very little then I recommend checking out the official site for more in depth info. I’m just going to give the 50,000 foot view.
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.
The above description comes from the official WebAssembly site. In summary, high level languages can be compiled down to WebAssembly and run in the browser at native speeds. This is a really exciting advance for web development, now many traditional server based languages can potentially be run in the browser.
What’s more, WebAssembly is now supported by all the major browsers.
But what about legacy browsers? I hear you cry.
No problem WebAssembly has you covered, it will gracefully fall back to JavaScript on older browsers and run as normal.
The reason I wanted to make you aware of WebAssembly is because this amazing piece of work is what makes the Blazor project possible.
What is Blazor?
Blazor is a .NET web framework which runs in the browser. Think Angular or React but powered by C# and Razor. Developers create Blazor applications using a mixture of C#, Razor and HTML. These applications execute .NET assemblies using the Mono .NET runtime implemented via WebAssembly. Blazor uses the latest web standards and requires no additional plugins or add-ons to run, this is a not another Silverlight.
Blazors History
Blazor started off as a personal project created by Steve Sanderson of Microsoft. He showed it off at NDC Oslo in 2017. This first version was built upon a interpreted .NET CIL (Common Intermediate Language) runtime called DotNetAnywhere. While the features were limited the potential of Blazor was obvious right away.
Since this demo Microsoft have added Blazor to their ASP.NET GitHub organisation as an experimental project. What this means is that Microsoft are investigating both the demand, and the technical issues around delivering Blazor as a full product before committing. At the time of writing the repo currently has just over 3300 stars and 17 contributors.
As part of the official adoption Blazor has been rewritten from scratch by the ASP.NET team. DotNetAnywhere has been replaced with Mono which has a much more advanced and fully featured offering in terms of .NET runtime. Mono has been part of Microsoft since 2016 and is the official runtime for client platforms. Powering frameworks such as Xamarin and Unity, it makes a lot sense for it to also power Blazor.
How does all this actually work?
As I mentioned Blazor is a web framework similar to Angular or React. Blazor applications don’t contain the actual .NET runtime, that’s what Mono brings to the party. Mono aims to run in 2 modes via WebAssembly, interpreted and AOT
Interpreted Mode
In this mode the Mono runtime is compiled down to WebAssembly, which can then be loaded and executed by the browser. Blazor application dlls, which are just standard .NET dlls, can then be loaded and executed by the Mono runtime.
Interpreted mode seems likely to be the quickest in terms of development speed as reloading application dlls is very quick.
AOT Mode
In Ahead-of-Time mode thing are slightly different. The blazor application is compiled directly to WebAssembly at build time. Parts of the mono runtime are still loaded by the browser to handle low level operations such as garbage collection. But essentially the application is executed as regular WebAssembly.
AOT mode could have the potential to be the better option for production as it would allow the chance to perform IL stripping, a .NET equivalent to tree shaking. However this is all still being assessed.
What can I do with Blazor today?
Blazor is currently in the very early stages of its development. While this is a pre-alpha preview there is already a lot you can do with Blazor.
On 22nd March 2018 the first public preview was released.On 17th April 2018 the second public preview was released.
It is possible to create components, use dependency injection, do basic component navigation, use JavaScript interop, get IntelliSense, and maybe a few other bits but I haven’t had long to play with it so far. So already you can try out the framework and get a feel for what it’s going to be like to develop applications with it.
I think another point to highlight is how stable things feel even at this early stage. I installed all the required parts and had a running application in under 10 minutes. I had to install the latest Visual Studio preview otherwise it would have been going in less than 5, thats really impressive!
What’s next for Blazor?
The groundwork is already well underway to make it a fully featured web framework which will support all the features you would expect. Taken from the official repo:
- A component model for building composable UI
- Routing
- Layouts
- Forms and validation
- Dependency injection
- JavaScript interop
- Live reloading in the browser during development
- Server-side rendering
- Full .NET debugging both in browsers and in the IDE
- Rich IntelliSense and tooling
- Ability to run on older (non-WebAssembly) browsers via asm.js
- Publishing and app size trimming
And as I said many of these features are already available in the framework and can be tried out today.
Wrapping up
As you can probably tell I’m pretty excited about this project. I’ve been a .NET developer for 15 years and I always thought it was a pipe dream to use C# client side. But it looks like with Blazor it’s actually happening. There is still a long way to go before we see a production capable version, after all it’s still only an experimental project. But I really think this is the start of something special.
Just thinking of being able to write C# client-side as well as server-side is making me smile. Having had more than a few heated conversations in recent times regarding which JS framework we should be using. I for one, welcome the thought of C# everywhere. I would like to clarify that I don’t see this as the death of JS and I’m not a JS hater. But I do welcome the competition which Blazor will bring. Plus, trying to keep up with everything that’s going on in the JS world is becoming a full time job!
Anyway, if you want to get involved then head over to the GitHub repo, there is also a Gitter chat to talk about the project as well. The team are looking for as much feedback as possible and the GitHub issue tracker is already looking pretty lively with suggestions and feature requests.
I’ve built a demo app which I’m developing as a way of showing what Blazor can do as well as to use in future posts, you can find it on my GitHub. I’m also going to keep it updated with each Blazor release.
You can also read my Blazor Bites Series:
- Creating a new project
- Creating Components
- Component Lifecycle Methods
- Data Binding & Events
- JavaScript Interop
- Routing
- Layouts
Which are bite size posts about the various features of Blazor.