As everyone knows, JavaScript is the most popular language right now. Everybody uses it, and it can be used for anything, from front-end to back-end… JavaScript gets even more popular when web frameworks and libraries like Angular, React and Vue are recommended and used by many developers. But then, there is another option… It’s called Blazor.

What’s inside the name Blazor?

If you’ve been keeping up with the latest developments in the .NET world over the past year or two, you’ve probably heard the word Blazor mentioned once or twice.  Blazor is a new client-side UI framework from the ASP.NET team. Its big selling point is the ability to write rich web UI experiences using HTML, CSS, and C# instead of JavaScript. It is open source and built on open web standards. Born in the hands of Microsoft, it combines the older Razor with the new .Net and WebAssembly, and it allows you to create both browser and server-side applications.

Understanding WebAssembly

WebAssembly, often abbreviated Wasm, is a new standard that can be run in modern web browsers bringing language diversity to the web platform. Wasm is a low-level assembly-like language featuring a compact binary format that makes it possible to run code written in multiple languages such as C/C++, Java, and Rust on the web with near-native performance.

The goal of WebAssembly is to facilitate high-performance applications on web pages. However, its format is designed for execution and integration in other environments and can also run alongside JavaScript.

Web development has always been synonymous with JavaScript development. That is, until now. Blazor came up in the rankings within a short period. People have started to compare it with popular javascript frameworks. There are many discussions about the future of client-side web development, and those discussions and comparisons have made it even popular. So, let’s see… .

What Blazor is not?

Blazor is not like Silverlight, Microsoft’s previous attempt at hosting in-browser applications. Silverlight required a browser plugin in order to run on the client, which prevented it from running on iOS devices.

Blazor does not require any kind of plugin installed on the client in order to execute inside a browser. Blazor either runs server-side, in which case it executes on a server and the browser acts like a dumb terminal, or it runs in the browser itself by utilising WebAssembly.

Because WebAssembly is a web standard, it is supported on all major browsers, which means also client-side Blazor apps will run inside a browser on Windows/Linux/Mac/Android and iOS.

How Blazor Compares to JavaScript

Blazor provides code encapsulation through its reusable web UI components. Blazor also allows both client and server C# code to share code and libraries.

Componentization is a concept familiar to people working with React, Angular, and other JavaScript frameworks. Components are the building blocks of an app, and a typical app will have many of these. They optionally accept inputs and return HTML elements that describe how a section of the UI should appear.

ASP. NET Core provides this idea in the form of Razor components. Razor components are also the component model of Blazor. Therefore, Blazor components and Razor components are interchangeable.

Each Blazor component represents a different element in the application UI structure, such as a shopping cart, a news feed, or a comment section.

How Blazor Compares to ASP. NET Core MVC Applications

A regular ASP. NET Core MVC renders the UI as blocks of strings. Blazor, on the other hand, builds a render tree, which is not a string, but a representation of the DOM (Document Object Model) that is held in memory. Blazor keeps that representation. Any changes made to it (for instance, when a binding value is updated) will trigger a UI update for the affected DOM elements. This is a big difference from ASP. NET Core HTML Helpers and Razor Views, which render out strings.

So why does Blazor work with render trees instead of strings? Remember that Blazor code in particular (and wasm code in general) cannot access DOM elements directly. This limitation differs from ASP. NET Core HTML Helpers and Razor Views, which depend on JavaScript to get full access to the UI elements. So Blazor resorts to render trees to go back to its DOM representation, look for specific pieces of the DOM, then update them, edit, delete, and so on. The Blazor framework will listen to changes made to the data model and manipulate the render tree to apply the changes. That mechanism is what allows C# to work on the client-side.

But why should you choose to develop with Blazor rather than pure client-side JavaScript or ASP. NET Core MVC/Razor? Let’s discuss some differences between them, so you can make an informed decision before putting any effort into developing a new Blazor project.

Pros of Client-side Blazor

Blazor allows .NET code to run directly in the browser. It breaks the JavaScript/Node.JS monopoly on full-stack professionals because with it, .NET developers don’t need to be programming polyglots. They can create complete solutions without writing JavaScript code.

Blazor code is compiled into .NET Intermediate Language, meaning it has the potential to be faster than the equivalent JavaScript code. This compilation model can make a difference for performance-driven browser applications, such as games.

You can share validation code between client and server apps. Let’s say you have form validation logic to be applied on both the browser and the back-end. With Blazor, you can create a class library in .NET Standard 2.0, and share it across client and server apps. Any change in the validation logic automatically applies to both platforms.

Cons of Client-side Blazor

To run Blazor on the browser, you must not only download the application’s .wasm and .NET libraries to the browser, but also Mono.wasm, the .NET runtime on top of which Blazor runs. Mono.wasm can be cached but downloading these assets for the first time will delay application startup. So even a tiny Blazor application will require downloading megabytes of code. JavaScript does not have this overhead.

Blazor can’t manipulate DOM elements directly. Occasionally, your client app must have a great deal of control over the HTML elements. Since Blazor doesn’t provide this capability by itself, you must use JavaScript Interop to fill this gap.

Overall client-side Blazor is currently slower than JavaScript during most aspects of running the app (not just startup). Microsoft is most definitely working to improve performance and, given their track record with performance tuning on other platforms, this should be a solved problem over time.

It’s also worth noting that, at present, there is limited debugging capability. Blazor still has to improve in this area. You can use a debugging tab in Chrome to debug and inspect the values of int, bool, and string types, and not much more than that. If you want to debug more effectively, you should put console logging throughout your client app.

Blazor vs. React

There are lots of developers that would argue that React as the best library for web component development. Although it’s not an apple to apple comparison, we have to agree that React is well-established and earned its respect with a proven track record and by having a strong community around it.

In other hand, Blazor is new but, it brings the flavor from its well-established counterpart Razor. So, it’s not entirely novel for developers. Moreover, .Net developers could have smoother transitions since Blazor uses C# for development.

Blazor vs. Angular

Another top JavaScript framework for SPA is Angular. When compared to Blazor, Angular has the upper hand thanks to its stability, popularity and production-readiness. Besides, Angular fully supports PWA while Blazor’s server-side is yet to become compatible.

So, let’s assume, what makes Blazor so unique

The main plus point of Blazor is that it enables us to develop and execute browser-based applications using C#. For the past several years, JavaScript (or TypeScript) has been the primary programing language used to create the frontend. If you are a .NET developer, you had to learn JavaScript, in addition, to become a full-stack web developer. With Blazor, you can develop both server and client sides using C#. And it seems, that it is the primary advantage when it comes to Blazor.

Unlike JavaScript, Blazor is pre-compiled into intermediary language. This feature gives us some remarkable benefits when it comes to performance demanding applications that run on the browser. Plus, Blazor applications can work offline for times where more processing power is needed, such as PDF generation, Gaming algorithms &, etc. Apart from those, there are many others features/advantages of Blazor:

• Build Web UIs with C# instead of JavaScript or TypeScript;
• Build progressive web apps (PWAs);
• Create and use reusable components written in C#;
• Full debugging support on the server-side and debugging with some limitations on the client-side;
• Data binding with the HTML DOM (limited two-way binding);
• Share code between client and server in C#;
• Server and client-side models;
• Server-side rendering (aka pre-rendering) for higher performance;
• WebSocket connections;
• Works offline (client side WebAssembly only);
• Works in all modern web browsers including mobile browsers;
• Blazor code has the same security sandbox as JavaScript;
• Use JavaScript interop to call JavaScript frameworks and libraries;
• Open source.

Final thoughts

The development world is moving towards more straightforward and flexible ways to achieve results. Hence, the tools designed a decade ago will have to make space for a fresher and more innovative front-end approach. With Blazor, Microsoft offers a complete development ecosystem where a singular framework that can run anywhere.

Blazor solves real problems faced by web developers and it does so effectively and at almost no cost. Its learning curve is smooth and easy. It contains all the must-have features of a modern day SPA framework while keeping things simple. With Microsoft behind it and an excited community supporting it, Blazor is poised to make a big impact on future web development.

So, what do you think, whether it becomes more popular with years or nothing can change Java Script era and etc?  Share your comments please and we will make our own conclusion.