Blazor Q&A with Microsoft's Daniel Roth

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. 

There has been a long-standing desire on the .NET team to improve the client-side experience for .NET web developers, but since browsers have historically only supported JavaScript there wasn’t really anything that we could do other than add another JavaScript framework into the already crowded ecosystem. That all changed when the WebAssembly community group announced that they had achieved cross-browser consensus, which opened the door to let other platforms run in the browser. Even then, no one was really sure if it made sense to try to support .NET on WebAssembly until Steve Sanderson built the first Blazor prototype as a demo for his NDC Oslo 2017 presentation on new browser capabilities. The experience Steve showed of building client-side web apps all in .NET was so slick that it opened a lot of people’s eyes to what is now possible.

SF: Very cool. I didn't realize it had been at NDC Oslo where he showed the demo. I'll have to go back and watch that. On the topic of WebAssembly, what do you think it provides that JavaScript or TypeScript doesn’t?

DR: For most application types (mobile, desktop, server, devices, etc.) you have a rich ecosystem of languages, frameworks, and tools that you can use as a developer. The big exception is the browser. Historically, browsers only supported running JavaScript. WebAssembly really changes that to make a much broader developer ecosystem available to web developers. If you can compile your code to WebAssembly then it can run in any modern browser and at native speed.

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?

DR: With Blazor you run ordinary .NET assemblies in the browser. Blazor supports .NET Standard, which is a standardize API surface area for all the different flavors of .NET (desktop, core, mobile). There are some limitations to the .NET Standard support in Blazor due to the browser sandbox. For example, you can’t open arbitrary files on the file system or make arbitrary network connections, just like you can’t from JavaScript. But for the most part .NET Standard libraries should “just work.”

SF: Since Blazor runs .NET in the browser, can Edge/Chrome developer tools be used to break/debug client-side code?

DR: We have some very early support today for debugging Blazor apps directly in the browser in Chrome. The way it works is we provide a debugging proxy service that augments the Chrome debugging protocol with .NET specific context. You can then use the browser dev tools to remotely connect to the browser instance you want to debug through the debugging proxy. This requires a couple of manual steps to setup today, but in the future, we plan to provide a tooling experience that enables browser debugging for you, like when you hit F5 in Visual Studio. We haven’t implemented debugging in Edge yet, but it would be a similar setup. The nice thing about this setup is that in addition to debugging your .NET code you can also step into any JavaScript code that you might be using through JavaScript interop. There’s still quite a bit of work to be done though to make the experience really feel like a normal .NET debugging experience, but it’s something we’re working on.

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.

DR: The Blazor community is one of my favorite parts of working on the Blazor project. They are a passionate and helpful bunch! Lots of community projects have sprung up around Blazor to provide component libraries, helper libraries, JavaScript interop libraries, tools, and a bunch of fun sample apps. We try our best to share these projects on the Blazor community page. The Blazor Gitter chat room is also a great place to hang out if you have a Blazor related question or you just want to chat about the future of web development with .NET.

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?

DR: My favorite thing about Blazor is that I get to write web apps using my “native” language for writing code. I get to use the tools, languages, and libraries that I am familiar with, which makes me more productive. It’s not that I don’t like JavaScript; the JavaScript community has done some phenomenal stuff. But working with .NET and C# is what I’m most comfortable and productive with. I also really like how developing with one platform lets me share and reuse code; no need to reimplement stuff twice in a completely different platform.

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?

DR: “Outlook good”😊. In the relative short-term the Blazor component model, or Razor Components, will become an integral part of how you write web UI with ASP.NET Core, enabling you to write rich interactive web apps without having to write a lot of JavaScript. Further in the future I expect that .NET will join a rich developer ecosystem of languages and tools that can be used for client-side web development, making building web apps easier and more productive than it has ever been before.

SF: Thank you so much for your time and insight, Daniel. We can't wait to see what the future holds!