Chatting about Blazor UI Controls with Microsoft at the Build Post Show

At Build, Microsoft announced the WebAssembly version of Blazor is now officially released. We’re excited to see this development, as we continue to develop and grow our native Blazor controls that are supported in both server and client-side Blazor apps.

Later, you will find me chatting with Michael Jolley, a DevOps developer and Twitch code streamer during the Build Post Show. We discussed some topics about Blazor UI controls, such as what options are available, what pain points developers are facing, and what GrapeCity is working on with regards to Blazor.

Below are some of the topics we discussed. I’ve expanded upon each question with more details and links to learn more.

What are the options for Blazor UI controls?

Greg: Currently, there are two ways to work with Blazor: running on an ASP.NET Core server with a thin-client, or completely on the client’s web browser using WebAssembly instead of JavaScript. UI components for Blazor can be natively written in C# or wrappers around JavaScript controls. The native Blazor controls work in both flavors of Blazor apps.

There are no Blazor controls in the box. That's something we found strange at the beginning. Basically, you are limited to HTML controls like inputs and tables, and even then, there's no direct C# API. You can create your own Blazor UI components that basically generate HTML.

Why use native Blazor controls versus JavaScript controls?

Greg: The main advantage of native Blazor components over JavaScript wrappers is the ability to reuse .NET libraries.

Also, you can share code between client and server. GrapeCity made native Blazor controls, primarily so that we can reuse code with our other .NET/C# controls.

How do you create a native Blazor control?

Greg: We create the Blazor components in pure C#. We don't use razor. This makes it easier for us to share between .NET platforms. The reason the controls work from the user’s perspective is because they are defined as markup in razor files.

Blazor then generates the controls through a series of operations like OpenComponent<FlexGrid>().

What are some of the pain points when working with Blazor?

Greg: Both client and server have performance problems, but for different reasons. The main pain point for client-side Blazor is the performance with creating the UI.

The performance is noticeable when comparing it to server-side Blazor. It's poor because the client-side is still using the interpreted runtime, which loads the .NET IL intermediate language and converts it to WebAssembly as it runs. It's also noticeably slower when you compare Blazor to pure JavaScript - probably about seven times slower.

On server-side Blazor, the UI is created fast, but there is the network latency involved with the back and forth updating that's needed.

On client-side, apart from the performance, there are also issues with the layout and the DOM. The layout lacks an invalidation mechanism. What's there now is not good because it just keeps recreating the shadow DOM over and over for every little update which impacts performance further. Also, the diff-update that is supposed to sync the real DOM with the shadow DOM is very slow.

And another pain point is lack of performance testing tools. We used Chrome tools, but it's like profiling in the dark. It's nothing like the profiling tools available for other .NET platforms. Another pain point for some will be the lack of UI controls that exist in other platforms. There are a lot of pain points.

What are some solutions to work around the performance issues?

Greg: There really aren't any workarounds to the client-side performance now. Microsoft has promised an improvement with client-side Blazor with the AOT, or ahead of time compilation. This should make client-side Blazor load faster at runtime, and in general, the application will perform more quickly.

This improvement is expected to out around November with .NET 5.

When the AOT runtime is finished, this should be much faster. The pass which converts the code to WebAssembly is made at compile time. Also, the downloaded bits should be smaller, as the .NET dll's shouldn´t be downloaded to the browser.

To fill the gap of missing controls, there are lots of 3rd party controls out there. Because you can use JavaScript controls pretty easily in Blazor, by just wrapping them, it was very easy for many developers to get custom controls in Blazor. The controls we provide with GrapeCity’s ComponentOne, are pure native controls.

What are the most interesting and useful solutions with GrapeCity Blazor controls?

Greg: Perhaps the most interesting solution we have with our controls is an easy way to display and interact with remote data. We have a data grid control, FlexGrid, and a data collection control. The data collection makes it easy to work with multiple remote data sources and dealing with large data. The ComponentOne DataCollection helps solve the performance problems that are typically brought upon with large data sets across multiple data sources. Also, it helps minimize the data traffic which helps deliver better load times.

The Blazor user interface is defined in razor files that mix HTML with C#. To display tabular data your only option is to use a basic HTML table. You can do this by just writing the table markup in the razor file as you would in a normal HTML file. But if you need to add more interaction, like editing, selection, sorting, filtering, and grouping, you'll need to use a fully developed Blazor component. This is where FlexGrid for Blazor can help.

The ComponentOne Blazor controls are supported on server and client-side Blazor. If you go for client-side Blazor using WebAssembly, it is challenging to display data from the server, and add sorting, filtering, and on-demand loading. The FlexGrid and data collection makes these easier as well.

You can download the latest version of the ComponentOne Blazor controls and they already work with the latest version of client-side Blazor just released. In the near future, we’ll be adding more client-side samples and addressing any issues discovered in the official release.