For a while now, Microsoft has demoed and spoken about their highly hyped WebAssembly framework that aims to blur the lines between front and back-end programming.
If you are a .NET developer or just like to keep your finger on the pulse when it comes to new frameworks and web tech, you have most likely heard of Blazor. If not, you can keep reading and just smile and nod so people don’t find out you’re behind the times.
Blazor is a framework that will allow developers to write applications targeting different platforms, with the web being the first priority. Right now, you can already write HTML, CSS and C# to create Blazor based web applications. By default, Blazor is a web-first framework made evident by the parts they have released so far.
When people talk about Blazor and get excited, they generally fall into two categories.
- Developers who are excited about WebAssembly
Given how new WebAssembly is (browser support wise), Blazor is one of the first frameworks of its kind to support and commit to WebAssembly (to the extent that they have). As you can see, WebAssembly is in a good place right now and keeps on getting better.
Something that many developers probably don’t realise is Microsoft has been grooming us to get used to C# syntax in the form of TypeScript for over eight years now.
I love TypeScript and I honestly can’t remember the last time I worked on a project that wasn’t TypeScript. I am also not a C# developer, but my experience with TypeScript and its overlap means if I wanted to write C# code, I would probably pick it up pretty quickly.
Jokes aside, Blazor is an impressive and highly ambitious effort on Microsoft’s part. Not only are they targeting the browser, but it appears that Blazor is going to be a platform for building across; desktop, mobile and web.
Blazor consists of the following pieces all being worked on separately:
- Blazor Server
- Blazor WebAssembly
- Blazor Electron
- Blazor Mobile Bindings
For quite some time, Blazor Server was the only released offering in the Blazor suite and it shipped with .NET Core 3 back in 2019. In February 2020, experimental mobile bindings were announced. In May 2020, the ASP.NET team released Blazor WebAssembly 3.2.0.
As things currently stand you can build Blazor applications on the server using Blazor Server which will push the rendered components into the browser and handle rendering. You can now also build client-side only applications using Blazor WebAssembly (.NET backend not required)
The road to web domination doesn’t appear to be stopping there. Microsoft is fast at work on .NET 5 which aims to unify the ecosystem aka global domination. A singular framework that can run anywhere: this is big deal type of stuff.
However, before we get too excited, Blazor WebAssembly has some serious performance issues and they’re not all the ASP.NET development teams fault either. While work is ongoing, it seems the long-term solution to performance woes is Ahead of Time compilation (AOT). An issue on GitHub has been opened since 2018 and it appears AOT won’t be arriving until .NET 6 because more work needs to be done before it can be incorporated.
The wounds of Silverlight are still fresh for some
For those who have been around for longer than a minute, you might remember Silverlight which was often compared to Adobe Flash. It came at a time when the web was primitive and browsers sucked, to create rich experiences you had to leverage something else.
Some of the core ideas of Silverlight are present in Blazor (only in spirit) and for those who committed to the Silverlight platform and ultimately found themselves abandoned when Microsoft ghosted the community and then eventually clarified their stance.
Given how young and ambitious Blazor is, there is always the chance that Microsoft could drop it like a sack of potatoes in a couple of years if it doesn’t catch on. However, based on the sheer number of resources that are being thrown at this and integration with .NET, I think it’s safe to assume that Microsoft is committed to Blazor.