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 hate Javascript and want to use C# to write web applications
- 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.
Is it just a coincidence that behind both C# and TypeScript is the same man, Anders Hejlsberg? This was undoubtedly the plan all along, to bring C# into the browser. TypeScript arrived early enough that Anders and his new world Javascript order friends could slowly lure us into the C# void with their beautiful enhanced Javascript siren song.
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.
Admittedly, Silverlight was superseded by HTML and Javascript as well as emerging web standards. Silverlight, like Flash, were bandaids on gaping holes in the web. However, the issue is Silverlight attempted to position itself as more than a Flash clone and it failed.
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.
But, who honestly knows what will happen? Even though I am not a .NET developer and I am a heavy user of front-end client-side frameworks (I actually like Javascript), the prospect of Blazor excites me. I am really excited to see how React and other frameworks and libraries adapt, will we see a React WebAssembly in the future?
I can’t foresee a future where Blazor makes Javascript irrelevant or kills it. Blazor will be like any other framework, library, tool or skill. Some will avoid it, others will embrace it and the web will continue to move forward (just as we’ve seen with Javascript frameworks).
As a .NET developer, Blazor is just about one of the best things that ever happened in the .NET world
As a .NET developer I also love JavaScript, even more so than C#.
Microsoft should focus on Visual Studio and the core assemblies of .NET and stop building (mostly poor) extra frameworks.
Blazor is just another thing I have zero interest in.
Only for MS fanboys that don’t want to learn JS.
I will be cautiously optimistic about Blazor. I feel there is still way too much ceremony involved with Blazor compared to VueJS or Angular. it needs to be simplified more. It feels more like a backend solution than a frontend solution. Maybe I am just used to Javascript now… lol