Daniel Roth: The Thing I love Most About Blazor Is How It Empowers Every .NET Developer To Be Productive

Several weeks ago, the 2020 edition of the DevReach developer conference brought together renowned industry experts and influencers for hands-on sessions and exclusive interviews about the latest app dev technologies and best practices. With each day dedicated to different technology and framework, attendees were able to dive into live coding with Blazor, React, Xamarin/MAUI, and Angular. Due to the COVID-19 pandemic, this year’s edition was virtual but true to its spirit to be an event from developers for developers, it still provided numerous opportunities for learning and collaboration.

One of the key participants in the five-day conference was Daniel Roth, a Principal Program Manager at Microsoft on the ASP.NET team. He has worked on various parts of .NET over the years including WCF, XAML, ASP.NET Web API, ASP.NET MVC, and ASP.NET Core. His current passion is making Web UI development easy with .NET and Blazor. 

Trending Topics SEE talked to him about the advantages of Blazor, the current state of the Blazor ecosystem, and given that Blazor started as an experimental project – what was Microsoft’s process for dealing with all of the unknowns at the beginning. 

Trending Topics SEE: Daniel, what’s your story and how did you arrive at your current position in Microsoft?

Daniel Roth: I came to Microsoft fresh out of college in the summer of 2005 after completing my MEng at MIT. I joined as a Program Manager on the .NET networking team just before .NET 2.0 was about to ship. I worked on WCF and frameworks for SOAP services for many years, and dabbled a bit XAML, before eventually joining the ASP.NET team to work on ASP.NET Web API.  More recently I’ve started to work more exclusively on our .NET web UI frameworks like ASP.NET MVC, ASP.NET Core, and now Blazor.

What’s the top advantage of Blazor over other frameworks? Personally, what’s your favorite thing about it?

The thing I love most about Blazor is how it empowers every .NET developer to be productive and to do more. Every .NET developer can become a full stack web developer using Blazor. We’ve always had a great story for building what I like to call server-rendered web apps with ASP.NET. A standard ASP.NET web app receives a request from the browser and then runs some .NET code to dynamically generate a response, like some HTML or JSON data. But if you ever wanted to do anything in your web app that ran client-side in the browser on the user’s device, then you had to write some JavaScript. Modern web apps take full advantage of the client to provide rich, interactive UI, and to leverage the capabilities of the client device. But having to use both .NET and JavaScript in the same app with their different tools, frameworks, and ecosystems added a lot of extra complexity. Blazor makes it possible to write your entire web app with just .NET, which is a huge win for productivity. You can use your existing .NET skills and code for both client and server logic. 

Is there any category of apps for which Blazor is particularly suitable?

Blazor is built to be a general-purpose web UI framework, just like other popular web UI frameworks like Angular, React, or Vue. We’ve seen developers use Blazor for everything from an internal line of business apps to public-facing websites and services. But like any other framework or technology, there are scenarios that Blazor may be better suited for than others. 

For example, to run .NET code in a browser you need to download a WebAssembly based .NET runtime with your app. We do lots of tricks to make that runtime as small as we can and to cache it appropriately, but if your app download size needs to be as tiny as possible then Blazor might not be the right solution for you. Runtime performance of .NET on WebAssembly might be another concern, which is an area we expect to improve upon in the future with things like ahead of time compilation to WebAssembly. You should of course choose the right tool for the job, but for most web apps we think developers will be very happy with what Blazor offers today.

Blazor started as an experimental project. What’s your process at Microsoft for testing, running, and analyzing the results of experiments?

When we first started talking about shipping Blazor there were still lots of unknowns: Is running .NET code in browsers really practical? How would things like debugging work? How would Blazor compete with existing frontend frameworks? To get answers to these questions we started with a prototype originally built by Steve Sanderson, a dev on the ASP.NET team. As with any of our projects, we like to stay connected with developers in any way we can to ensure we’re meeting them where they are. We conducted user studies with web developers from a variety of backgrounds. The early reactions were really positive! I remember one guy we talked to was ready to rewrite his entire web app in Blazor based on the demo we showed him and we had to explain it was just a prototype. 

From there, we started releasing monthly experimental releases of Blazor, and pretty soon we had an enthusiastic community of early adopters and advocates. Blazor was open source from the beginning, so we received lots of great feedback through GitHub. We did more user studies and collected more user feedback using an in-product survey which we still use today. We made good progress on the Blazor component model during that time while folks on the .NET runtime team worked through the issues with getting .NET running on WebAssembly. After a few months it became pretty obvious that it was going to take a while to build out the .NET support for WebAssembly, so that’s when we decided to move forward with the Blazor component model, but hosted on the server using SignalR to handle all of the UI interactions remotely. That’s how Blazor Server came to be, and it shipped with .NET Core 3.0 and then again with .NET Core 3.1 LTS. Progress on .NET for WebAssembly happened in parallel, and we shipped support for Blazor WebAssembly based on .NET Core 3.1 earlier this year. Both Blazor Server and Blazor WebAssembly are included in the box with .NET 5 with many additional improvements. It was quite the journey getting to this point, but it was the constant flow of feedback from users that really made it all possible.

Whаt’s the current state of the Blazor ecosystem and what’s next for Blazor in general?

Blazor ships with very few components included in the framework, so we rely heavily on an active Blazor community to help build out the ecosystem. All of the major component vendors that I know of now have commercial Blazor UI component libraries. There’s also a very active open-source Blazor community that builds all sorts of great component libraries, JavaScript interop libraries, and other great Blazor stuff. The Awesome Blazor GitHub repo is a great resource if you’re looking for Blazor specific projects and libraries.

What was your favorite part of DevReach 2020?

It’s always fun to hear about the latest trends in front-end web development. There was an entire day at DevReach devoted to Blazor with a lot of great speakers that I’d definitely recommend checking out.

And, our favorite question, what advice would you give to young software engineers, at the very beginning of their careers?

I would suggest to always be on the lookout for ways to use your software engineering skills to make the world a better place for everyone. There’s a huge need for great software in so many areas. One of the things I love about working on open source software is all the people I get to work with that are willing to share their time and expertise for the common good. If you focus on that, I think you’ll be in great shape.