What is this Blazor everyone's talking about?

#blazor #dotnet #csharp

JavaScript has been labeled as the backbone of web application development allowing you to create beautiful, and functional, web applications. But for a .NET developer, like myself, working with JavaScript can feel like the wild, wild west. Fret no more! Blazor helps alleviate that feeling by allowing us to run C# code in the browser!

Read on to learn more about what Blazor is, as well as, the pros and cons of using Blazor.

What is Blazor?

Blazor is a new single-page web application (SPA) framework built on top of the .NET framework. It allows you, the .NET developer, to build the same great user interfaces as those using JavaScript, except with C#. This also means we can reuse existing .NET libraries and logic we've created, like for field validation.

Now, there are those experienced developers out there, including yours truly, who remember the last framework to provide this feature, Microsoft Silverlight, and it's fate. There was a caveat that came with using Microsoft Silverlight, though, and that was it required the installation of a compatible plugin into your browser. This is was a deal-breaker for a lot of web users, and still is, especially with the prevalence of mobile browsers. The good news for us today is Blazor does not come with this caveat.

Blazor can run in 2 different modes, server-side and client-side. Each mode has different strengths and weaknesses making them useful for different scenarios.

Server-Side Blazor

Running Blazor in server-side mode means all execution of our C# code happens on the server. Once the code execution completes, updates to the user interface (UI) are immediately sent back to the client and merged into the document object model (DOM). Blazor uses SignalR, a real-time communication framework allowing server code to push content to "connected clients instantly as it becomes available, rather than having the server wait for a client to request new data."[1]

Client-Side Blazor

When using client-side mode, all code execution happens on the client and because everything happens on the client, all of the app's assets are deployed as static files. This means you can host the files on any service that can serve static files, like a content delivery network (CDN). To execute your C# code, Blazor uses WebAssembly (Wasm), a new technology that allows the execution of binary code inside most modern web browsers.

To learn more about Wasm, check out this article by Eric Elliot.

JavaScript's not dead

If you're a frontend developer who's reading this trying to keep up with all the new frameworks coming out these days, then you might be thinking Blazor, or Wasm for that matter, is trying to replace JavaScript. Let me put your worries at ease, as this is far from the truth. Wasm is meant to be a complement to JavaScript, not replacement.

The team behind Blazor recognizes there is already a rich ecosystem of JavaScript libraries available to developers. Likewise, many companies and enterprises have a large investment in client-side libraries built throughout the many years before This is why they provide JavaScript interoperability.

The good, the bad and the ugly

Alright, we've talked enough about what Blazor is and what it's not. Let's get to the pros and cons.

Pros

1. A framework developers already know

The team built Blazor around already used pieces of popular web development frameworks. So if you already have experience developing Razor Pages, MVC or Web APIs, the learning curve to Blazor is greatly reduced!

2. Faster page rendering

Because client-side Blazor is using WebAssembly to execute code and render the pages, we're able to run at near-native speeds, and the Blazor team is continuing to look for ways to increase these speeds.

3. Client-side mode can run in an offline mode

When running your app in client-side mode, all the resources and libraries your app needs to run are downloaded to the client. This allows your application to run detached from the internet, or in an offline mode. Something to also keep in mind, this is assuming your site doesn't need access to an external service to function, and if it does, you've accounted for the pre-loading, or persistence of the data locally, until a connection can be made to the external service.

4. Server-side communication is efficient

With Server-side Blazor, none of the code or libraries are sent to the client and only a small amount of JavaScript is sent over to bootstrap the application making it very efficient going across the wire. Server-side Blazor also uses SignalR to communicate between the server and client. SignalR uses web sockets to allow real-time back and forth communication, without having to wait for the client to make a request for new data.

5. Code reuse

Blazor implements .NET Standard 2.0, a formal specification of .NET APIs common across all .NET implementations. This means we can use the same code and libraries in the browser, on the server, or any other application implementing .NET Standard 2.0 and take advantage of the extensive, and growing set of libraries available in NuGet.

6. Client-side runs in Browsers Sandbox security

Long have users been worried about whether it's safe to run a web application or not due to concerns of malicious intent or data snooping. Blazor runs in Wasm and as such does not require any additional plugins or usage confirmations. It runs within the Browser Sandbox security context.

7. UI Component ecosystem from top component vendors

Many of the top component vendors, such as Telerik, DevExpress, ComponentOne, and SyncFusion, among others, have been following the development of Blazor and have already begun creating reusable UI components. These components further reduce the time it takes to get a working application out the door.

Cons

1. .NET Framework needs to be downloaded to the client

Client-side mode executes the C# binaries in the context of the browser, and because of this client-side execution, a copy of the .NET Framework libraries are needed. This leads to the download size being larger and a longer initial app load time. Once the libraries are loaded, they can then be cached.

2. Client-side mode is still in preview

Unlike server-side mode, which was released with the general availability of .NET Core 3.0, the client-side mode is still in preview. It is expected to be released in May 2020.

3. Only works on modern browsers

Due to the dependency on Wasm, older and non-standard browsers, like Internet Explorer and "thin clients", are unable to run client-side mode versions of Blazor.

4. Debugging can be tricky

Because execution in client-side mode happens in binary on the client, custom tools are needed for debugging. These tools are currently limited in capabilities and can be cumbersome to set up. See the instructions here.

5. Reduced performance benefits in server-side mode

Unlike client-side mode, server-side mode requires a network connection between the client and server, and as such, any slowness in the network will negatively impact the performance of the application.

Conclusion

It's never an easy decision when it comes to deciding on the technology for your team's next project and I hope I've provided you with some beneficial information when it comes time to evaluate your next web technology. While I would love to see Blazor take off like gangbusters, always use the right tool for the right job. 🙂

To learn more about Blazor, head on over to the official documentation, or if you're itching to get your hands on some code and have the latest version of Visual Studio installed, just create a new project and select Blazor app. You can also view the official getting started guide here.

Other articles in the series: