The Progress Telerik team has been really excited about Blazor since it was announced as an experimental project. Ed Charbeneau has written a number of blog posts about it (you can find them here) and our product and engineering teams have been experimenting with it.
We are hearing from all of you that you are interested as well, so we thought we'd sit down (virtually) with Daniel Roth, the Senior Program Manager at Microsoft responsible for Blazor, to learn more about the past, present and future of the project.
Here is a recap of our conversation.
Sara (SF): We're really excited to hear about Blazor and to have you share your thoughts with developers. Thanks for taking the time. Why don't we start at the beginning. Tell us a little about how Blazor came to be.
Daniel Roth (DR): Of course. Thanks for the opportunity.
SF: That makes a lot of sense. Who wouldn't want that kind of performance and speed? So why is it that Blazor is considered “experimental?"
DR: Blazor started as an experimental project because we weren’t sure how well it was going to work out to run .NET in the browser on WebAssembly and we didn’t know how compelling the user experience would be. We’ve learned a lot since the start of the experiment and Blazor now supports an enthusiastic community. There are still some technical challenges to work through, like performance, debugging, and download size, but we feel confident that they can all be addressed. We’ve already decided to move forward with productizing the Blazor UI component model in .NET Core 3.0 so that it can be run server-side with ASP.NET Core. The WebAssembly support though will need a bit more time to bake.
SF: Can you explain a little more about productizing the Blazor UI component model in .NET Core 3.0? Does that move make Blazor no longer "experimental?"
DR: Blazor is really made up of two parts: a component based UI framework and a WebAssembly based .NET runtime. Running Blazor on the server means that the components execute on the server on .NET Core while the UI is managed over a SignalR connection. You get to write your code using .NET and you still get the rich interactive feel of a browser-based application. Since the server-side Blazor model has no WebAssembly dependency we’ve decided to go ahead and productize the UI framework part of Blazor in of .NET Core 3.0. We are integrating the Blazor component model into ASP.NET Core, which is what we are now calling Razor Components. At the same time, we are continuing work on the client-side WebAssembly support, which will remain experimental for a while longer. The key thing is that we are keeping the component model the same whether you’re running on the server or the in the browser. The same components can be used on the server or in the browser assuming they were implemented with the appropriate abstractions.
SF: Nice. OK. So Razor Components are stateful UI components for the web that support a flexible hosting model?
DR: Exactly. You can host Razor Components in an ASP.NET Core app (for example, as a routable page or used from a Razor Page or MVC View) or you can host them directly in the browser via WebAssembly. Again, they are the productization of the Blazor component model in ASP.NET Core.
SF: Are existing (pre-Blazor) .NET assemblies compatible with Blazor?
SF: Since Blazor runs .NET in the browser, can Edge/Chrome developer tools be used to break/debug client-side code?
Alternatively, you can host your Blazor app server-side and then normal .NET debugging works like it would for any existing .NET application. Many Blazor users tell us that they use the server-side model during development so that they can debug with the intent to later run the app client-side on WebAssembly. It’s another good example of the benefits of having a flexible hosting model.
SF: Can the Blazor framework be used to build desktop apps?
DR: Our primary focus with Blazor is building web apps, but we have tried out using Blazor with Electron to build cross-platform desktop apps. We prototyped using Blazor in a .NET Core process to drive the UI of an Electron app over an IPC channel, and it worked well. You can find a sample using this model on our Blazor community page. It’s still just a prototype though and we don’t know at this point if it’s a direction that we will pursue.
SF: You've mentioned the Blazor community several times now. Talk to me a little more about that.
SF: What kinds of projects and apps have they created? Are there any that really stick out?
DR: The Blazor community has been enthusiastically building out a variety of fun sample apps using Blazor. They’ve built Markdown editors, to-do lists, calculators, Twitter clones, chat apps, and a whole bunch of simple games, like Asteroids, Tetris, etc. You can find these apps listed on our Blazor community page.
We also regularly get pinged by customers both internal and external to Microsoft that are experimenting with Blazor for potential production scenarios. One interesting scenario is the Try.NET site. Try.NET lets you write some .NET code in browser and then run it. Currently Try.NET compiles and executes your code on the server, but they are investigating if they can use Blazor to instead build and run your code directly in the browser.
SF: Now for a few more personal questions :-). What is your favorite thing about Blazor?
At the same time, I think Blazor has a lot to offer even if you’re not already familiar with .NET. Blazor gives you a simple and intuitive UI component model with great tooling all built on .NET, which is a stable and mature platform. I really like how Blazor helps me get started fast and lets me focus on building my app. When you combine Blazor with a fast and secure ASP.NET Core backend I think you’ve got a winning solution.
SF: It's really hard to argue with that. One last question... Looking into the Magic 8 Ball, what is the future of Blazor?
SF: Thank you so much for your time and insight, Daniel. We can't wait to see what the future holds!