Guid.New – .NET, the new framework for the browser?

When the software development company Guid.New GmbH was founded back in 2016, there was one thing that united all their 5 co-founders: Their unconditional love for software engineering and technology. And as luck would have it, they all had a very specific taste in what technology they preferred when it comes to development.

This taste was .NET and came in many different flavours, such as classical .NET backend development, WPF desktop applications, Xamarin mobile apps, ASP.NET server-side web development and a few more. But one thing kept missing – one thing that was and still is essential for most of the use cases they are developing software for: Single-page applications for proper web development.

Since they all had an affinity for strongly typed languages and a proper framework with broad community support, their technology of choice for this job was Angular 2+ with Typescript as programming language. While it was a great framework and opened numerous new opportunities, it still was a completely different technology than .NET, which brought its own challenges with it. Learning a new technology is one thing, but keeping up with all the news, best practices and security issues is the other thing.

As a result, hiring more people with different skills could be a solution, but this in turn comes with new challenges. Like not being able to easily develop full stack and having a good understanding of the whole system.

There is light on the horizon

They took their first peek at a brand-new technology called “Blazor” when it was first announced by Microsoft on February 16, 2018. An open-source project that promises client-side web development with .NET using C# as a programming language. Could this really be what they had always been looking for? Well, since back in 2018 the technology still was very experimental, they decided to wait another year before putting it to the test.
On September 23, 2019, the first version of Blazor Server was released together with ASP.NET Core 3, shortly followed by the web assembly version, Blazor WebAssembly in May 2020. This was the moment Guid.New decided to give it a try and eventually put that shiny new technology to the test. Yet, they knew that a “Hello World” sample would not do any good in evaluating a new technology and so they decided to invest in a complete port of an established Angular application for their client Andritz AG.

So, in this article they want to talk about what exactly Blazor is, the different variants available and what they are being used for. And probably as the most important part, the learnings from the port of the Angular application are pointed out.

What is Blazor?

The meaning behind the artificial name “Blazor” is described on GitHub as follows:

“Blazor makes heavy use of Razor, a mark-up syntax for HTML and C#. Browser + Razor = Blazor! When pronounced, it is also the name of a swanky jacket worn by hipsters that have excellent taste in fashion, style, and programming languages.”

But first things first. What exactly is Blazor?

Blazor is a single-page application framework, similar to JavaScript SPA frameworks like React, Angular vue.js, which allow them to build an interactive web UI. While with Blazor they still describe the UI with HTML and CSS, the application code is written in C#. To access the DOM, it is possible to use JavaScript interop which basically allows to execute any JavaScript code or even use JavaScript libraries in addition to their .NET code.

The experiment

The starting point for their experiment to evaluate Blazor was an internal tool of the Andritz AG for monitoring orders ( It consists of a heavy lifting backend that aggregates loads of data from different sources and a rather small UI offering a search function as well as multiple lists and detail-views. Currently, the backend is implemented in .NET and the frontend in TypeScript using Angular as a framework. What makes the scenario even more interesting is the fact that the Andritz AG heavily relies on .NET as their core technology, which makes the idea of a unified technology very appealing.

In order to be able to evaluate this new technology, Guid.New set the following goals during this experimental port.

  • What will the differences be in the finished applications?
  • To what extend will we be able to utilize our current knowledge of .NET?
  • Should we use Blazor Web Assembly or Blazor Server – and why?
  • Is Blazor a technology to be relied on or could it end like Silverlight?
Tools and ecosystem

One great thing to point out about .NET is its huge ecosystem, consisting of countless tools and libraries. As well as an extensive documentation and a blog post tackling almost any problem you will probably ever run into.

But just how nicely does Blazor as a brand-new technology go with all of this?

Since Blazor is a part of ASP.NET Core it does share the same tools as the SDK and CLI. Furthermore, most tools that support ASP.NET Core or C# also work with Blazor, including Visual Studio and Visual Studio Code as IDEs. As Guid.New already have Visual Studio in use for the backend, all it took them for setting it up and finally being able to run and debug the new Blazor part, were a few additional projects in the already existing solution. Even better, for Azure DevOps, which they are using as their tooling for the continuous integration pipeline, no changes were needed to also build, test and publish the Blazor part of the system.
Another very important part is 3rd party libraries, when the default APIs of the .NET framework is not sufficient for our needs. As of today, there are more than 220k packages ( available on and since Blazor is built upon .NET Core 3.1 it is possible to reference any package targeting .NET Standard or .NET Core. Although this is a benefit, it does not mean that all of them are meant for being used in a client-side web application, nor do all of them support the APIs of the browser sandbox.
Because they are already using Telerik components in their Angular version of the application, they have decided to put those to the test as well. They were quite surprised to see that Telerik was already offering Blazor support for their components. While of course not feature complete, and by far not comparable to the Angular version, it was still good enough for everything they needed in our Blazor port of the project. Also, keep in mind that they attempted this experiment at the beginning of this year and since then Telerik has already released a bunch of updates bringing new features to the table.

Ease of transition for a .NET developer

While the ease of transition heavily depends on how much experience you already have with the specifics of web development, such as HTML, CSS, different behaviours in different browsers and across multiple operating systems, it is fair to say that using Blazor as your first SPA framework coming from .NET will ease your life, processes and your work. This is mainly due to being able to write your code in C#, apart from the code to describe the UI itself, which is written in Razor syntax. Coming from ASP.NET will make things easier, since you are already familiar with all the pitfalls of web development, while already being experienced with the use of the Razor syntax.


As usual, being an early adopter in the use of a new technology comes with its own risks and challenges. Therefore, Guid.New want to give you a quick overview on the things they ran into while doing their Blazor port.

First off, the debugging experience seemed quite poor to them compared to what they were used from Angular or other .NET projects. Another thing that they were really missing during the development was the availability of best practices and existing experience on how to structure your application. These areespecially important when you are dealing with a big enterprise application.
For example, in Angular you will find tons of resources on specific topics like state management, code structuring and so on. But since Blazor is so new, there is not much there yet.
Last but not least, they want to mention working with styles and assets. While Angular allows you to utilise the full power and magic of webpack for compiling SASS to CSS, optimising bundle size and bundling the output with hashes for cache-busting. In their experiment they were using the WebCompiler Visual Studio extension (, which is not quite comparable yet.

Hosting Models

To understand how Blazor works, it is important to note that it differs a lot depending on the hosting model used. Currently, there are two main hosting models available which were also the focus of our experiment: Blazor Server and Blazor WebAssembly. Microsoft has also announced multiple additional hosting models going beyond web apps and supporting desktop and mobile apps.

Blazor Server

As its name indicates, with Blazor Server the application runs on a server and not within a browser. To send the UI Updates from the server to the browser, SignalR is used to transfer the data in a compact binary format. This is further supplemented by a newly developed, efficient diff detection algorithm by Microsoft.
From their point of view, the biggest advantage of the Blazor Server approach is that, since the whole application runs on the server, there is no need to create an API to communicate between client and server. Additionally, the slim clients needed to run the application are very interesting when it comes to dealing with low-end devices for end users.

Blazor WebAssembly

WebAssembly (, as described, is a binary instruction format that allows running code in the browser with native-like performance. WebAssembly is an open standard and already supported by all the major browsers. In order to make Blazor WebAssembly even possible, it was necessary for the Xamarin team to compile the Mono runtime to WebAssembly. With this out of the way, how Blazor works, is that the application first loads the runtime in WebAssembly binary format and – only after that – it loads the application assemblies itself and all dependencies, including System.dll, mscorlib.dll and so on. While the runtime is in WebAssembly binary format, all other assemblies are in the same .NET assembly format as in any other .NET application.

Code sharing

For their experiment they wanted to try out both – Blazor Server and the Blazor WebAssembly Version. One of our goals was to find out to what extend it will be possible to reuse code in-between those two variants. When they started out with the Blazor WebAssembly application, they were able to completely reuse our API which was already used by our Angular application. Further down the line when they started with the Blazor Server variant of the application, the first approach was to copy all the code and get it up and running.
Consequently, they created a shared project and started moving duplicated code file by file. The result of this was that almost all the code, razor components, images, styles and fonts could be reused. Only code specific to authentication was not feasible to be shared, since they have used cookie authentication for Blazor Server and bearer tokens for the WebAssembly variant.

All in all, if you do not want to decide which Blazor variant to use or you just want the flexibility to change your mind later, there is not a lot of effort required to support both variants at the same time.

Comparing the output

When comparing the output of the existing Angular application to the Blazor prototype, the most important thing is to determine whether there is any notable difference for the user.
The first and very important parameter for a web application is the download size. When a user navigates to the URL for the first time, the initial HTML, the application code and resources like styles, fonts and images must be downloaded. Since in their experiment most of the things stayed the same, they will only compare the size of the code that has to be downloaded.

When looking at the Angular app, all of JavaScript files loaded from the network have a size of 775kB. This production bundle was created using the Angular CLI and, in addition to our code, contains the Angular Framework and all 3rd party libraries used in the application. In comparison to the Blazor WebAssembly application, only 395kB of JavaScript code is loaded – most of the code is from the Telerik 3rd party components they have used – but in addition to that Blazor also loads 662kB for the .NET runtime in WebAssembly format and all other DLLs (3MB), coming together at about 4MB. The reason for this huge difference in download size is that JavaScript was always meant to be run in browsers and is optimised for this usage. Furthermore, numerous tools and techniques, like tree shaking, even further enhanced this optimization and reduced the bundle size even more.
On the other hand, .NET had mainly been used in desktop applications or web applications running on a server, where the size of the application was subordinated to other things. To reduce the size of Blazor WebAssembly applications, the Intermediate Language Linker ( is used. This works like tree-shaking in JavaScript, but the usage of reflection in .NET makes it harder for the linker to find out what is really used during build time.

However, .NET 5 promises new improvements to the linker, while .NET 6, coming in the first quarter of next year in a preview version, will also bring ahead-of-time compilation, which allows them to compile the framework assemblies and their code to WebAssembly, further reducing the bundle size. Blazor Server cannot be compared to the WebAssembly variant or Angular regarding bundle size, since it only loads a small script (76kB) which opens a WebSocket connection to update the UI from the server.

To sum up, you must look at your project at hand to decide how important bundle size really is for you. For their port, the application is only used by a small number of users on desktop PCs only. They are not shipping daily updates, which means the browser caches resources, so there is nothing to download when the application is loaded again. Consequently, the bigger bundle size does not really matter in our scenario.


Next up, they did compare the start-up- as well as the runtime performance of the Blazor variants. Most of the time, Blazor WebAssembly is quite fast. However, trying to make a lot of changes in the UI, as for example loading a long list of data, it can slow down significantly to a point where even the browser may become unresponsive for a time. While at Blazor Server the same issue of long loading times for lists with lots of data was likely to occur, this was not the only problem they ran into. Even though the UI updates from the server are usually only small messages, they noticed at longer lists they can grow to up to 10MB for a list of 5000 items. Which of course is huge compared to a JSON with the same data only having a few hundred kB. To circumvent such scenarios, make smart use of pagination and virtual scrolling.


While Blazor is a new technology to write single-page applications in .NET using C#, it is built upon ASP.NET core. An established framework with a huge existing ecosystem of tools and resources and a great community. Since single-page web application are in high demand across all industries and use cases and .NET is a highly renowned technology, the idea of combining those two is an incredibly rewarding thought.
If you find yourself in a similar situation like it is pointed out in this article, it is highly recommend trying out Blazor, getting familiar with it and learning about its pros and cons first-hand. Whether it is the right choice of technology for your next project or not depends mainly on the skillset and of course the use-case of the application.

Guid.New will pursue this new opportunity with great anticipation and are looking forward to many new features and updates for this exciting technology.