 Hi everyone, welcome back. I'm Daniel Roth and in this session we're going to talk about the future of Blazor on the client. Blazor is a client web UI framework based on .NET and C-sharp instead of JavaScript. Now previously the browser was a black box that you couldn't get your .NET code into. Now with Blazor, you can use .NET for your client web development needs. But what if you need to take your app to other native platforms like mobile, desktop, and other devices. It could be really expensive to have to build native experiences for all those platforms. You might not have the developer resources or the developer skillsets. One common strategy is to use the ubiquity of the web and your existing web developers to build apps with native like capabilities. In the future, we want to evolve Blazor so that you can use it to build apps that have those native like capabilities. So we're going to walk this spectrum from the web to native applications. Now we've already seen Blazor server apps in .NET Core 3.0. It's available this week, download and install it, try it out. Blazor server apps enable you to add rich client-side interactivity to your existing .NET web applications. Now they run on the server, but they allow you to have that client interactive feel like a single-page web application. They also enable you to leverage the capabilities of the browser using JavaScript Intra. Let me hop over here to Visual Studio. Here's the Blazor weather application that we saw earlier this week. This is a Blazor server app. I've already refactored it again to move all of its components into this Razor class library, this blazorweather.core. We expand some of these folders, we'll see all the Razor files in there. There they are. That's so that I can reuse these components in future demos. When the Blazor server app, we've seen what this looks like. It has a UI for showing the current weather. One of the things that we already saw is that we do have client-side interactivity. We can click on and change the current temperature unit. We can also use the capabilities of the browser to get the user's current location by clicking here. That should use the geolocation APIs to give us where we're currently at. One other thing that I've added to this application that also leverages an additional capability is the browser's local storage. I used, it's actually a community project. I was at github.com, Blazor'd. This is a project by Chris St.D. He's done a whole bunch of really good stuff. He has a package that uses JavaScript interrupt to enable local storage and Blazor applications. I use that so that if we go back to the app, we can store our pinned locations locally in the browser. So that's like go to Chicago and we'll pin that one. There it is. Now we can cycle through our pinned locations. So we have Seattle and Chicago. If I grab this URL, I'm just going to close that tab and then we'll open up a new one, browse back. We still have Seattle and Chicago as our pinned locations using the browser's local storage to store those things. So we get to leverage browser capabilities as well with our Blazor server applications. Mr. Roth, Mr. Roth. Oh my goodness. I brought your Blazor. What are you doing? I brought your Blazor. Oh my goodness. Yes, yes. Gotta look the part. Oh yeah, this. The Blazing Blazor. This makes me ready now for the demo. Thank you Mr. Fritz. All right. All right. We're going to blaze on now. OK. Woo. Yeah. Not expecting that. OK. So what's the next step on adding more native-like capabilities to our Blazor application? Well, the next step is Blazor WebAssembly. Blazor WebAssembly apps run in the browser on a WebAssembly-based.net runtime. Sorry. So with a Blazor WebAssembly app, your app is just a bunch of static files. And they can be downloaded. They are downloaded into the browser and then executed. And they can then leverage the capabilities of the browser as well. So I've taken the same application. This is the server version. Let's close that. Let's now go to a different project. And this is a WebAssembly version of the same project. It's actually using exactly the same components. This is kind of cool. A lot of customers that I talked to are starting out with Blazor server with the plan to when once Blazor WebAssembly is available in May of next year, that they can then shift their app to actually run full-on in the client. But let's go ahead and run the WebAssembly version of this app. Looks pretty much the same. Does the same things. Like we can get our current location here. Should be in Redmond. Yep, there we are. All right. And then if we F12 and look at what was downloaded to this application, it looks a little bit different. Yeah, so there you see down at the bottom, there's that monodot wasm file. That is our WebAssembly-based.net runtime. So this app is actually running client-side directly in the browser. Now to show that that's really occurring, we can even debug. When I F12 again, if we look in the console, you can see there's a debugging hotkey gesture that we can do. I'm not debugging this in Visual Studio. I'm actually going to use the browser dev tools to debug it. We don't support debugging in Visual Studio yet for Blazor WebAssembly apps, but we will in the future. For now, don't run it with Debugger in Visual Studio, and then you can use Do This Trick. So I'm going to hit Shift Alt D. And that's going to try and bring up the browser dev tools to connect to the tab that I want to debug through a debugging proxy that we set up for you. Now for that to work, we actually have to run the browser with remote debugging enabled, which I don't have it doing currently. And it's telling me how I can restart it, so it does do that. So I'm going to close down the browser completely. And I'm going to run the command that it just told me to do. To restart the browser with remote debugging enabled, and we'll hit that gesture again, Shift Alt D. And now I should get the browser dev tools that can connect to my tab. There we go. So let's put this side by side with the tab I want to debug. And we've already got some files open. Let's go ahead and close those. In the Sources tab, we can see down here, we can actually take a look at all of our, let me give myself a little more space, all of the files that are in our application. So there's Blazor Weather Core. What do we want to look at? Let's look at the temperature unit picker. Open that file up. We can set a break point right here on the click handler when the temperature has changed. Let's go ahead and get the current location back up on the screen so we can change the temperature unit. We'll click. And there, we just hit a break point in C-sharp in the browser running on top of a WebAssembly-based.net runtime. We can even expand down here and take a look at some of the local fields in our component. So currently, the temperature was Fahrenheit. Let's hop out of here and let the app continue. If we clip the temperature unit picker again, it should say that it's changed and has it. Yeah, looks like we're good. So now the temperature is Celsius. So there, we just debug our Blazor WebAssembly app directly client-side. So that's pretty cool. I'll go ahead and let that run. All right. So that's Blazor WebAssembly. Now, we can use some of the more modern web standards in our Blazor WebAssembly app to make it even more native-like. And apps like this are typically called progressive web apps, or PWAs. What is a PWA? Well, a PWA is just a web app, but it uses modern web standards to enable things like offline support. You add a service worker so that the files can be cached and used even when the browser is not connected. Support for push notifications. PWAs tend to are fast and responsive, so they have that native app-like feel. On some platforms, they can even be OS installable. Like you can pin them to your home screen on your phone. Or on Windows 10, you can install them so that they can be run from your start menu. So we can take our Blazor WebAssembly app and turn it into a PWA. Let's do that. So actually, we've already got it running. And if we look at the top with our Blazor WebAssembly app, you can see there's a couple of icons up there. And this one here says install Blazor Weather as a PWA. That's because the browser and Windows 10 is detecting that this is a progressive web app. If I go ahead and click that, yeah, let's go ahead and install. And now we see our Blazor WebAssembly app, but it's in like a native shell with all the same functionality and it still works, like, I don't know, St. Louis. So we can find new locations. We can get the location by geolocation. And we can see that on the start screen of my Windows 10 box there is my Blazor Weather app. And it has a nice little icon so that it shows up in the start menu. So that's pretty cool. So that's a Blazor PWA. How did we enable this? If we go back to the code and look at how this was implemented. In the www.root folder, we can see there's a service worker that was added to this application. This is a piece of JavaScript that enables caching. And then there's also this manifest file, which specifies like icons that can be used when this app is either pinned to a home screen or to the start menu on a Windows device. That is a Blazor PWA. It's starting to look a little bit more native. It's got a native shell. It's runnable from the start menu. Let's go ahead and close that. Great. Hybrid apps are native apps that run natively on the device. They have access to all the native capabilities of the device. But they use web technologies for rendering their UI. So for example, you might have a mobile application that's running natively, but it's using a web view for rendering all of its user interface. Or you can have an electron application. And an electron application is using an embedded Chromium shell to handle all of its user interface. Let's see if we can build Blazor hybrid apps as well. We've been doing some experiments in this space. Let me go back to Visual Studio. So here in my third project, we have a BlazorWeather electron app. So I'm going to set this as the start project. And we're going to run it. Again, it's using the same components as before. But now, instead of running as a web application, this Blazor electron app is going to run in an electron shell. It's a native shell. Like we have all the access to all the native capabilities of electron. The same functionality still works. Let's see what the weather is like in New York. There it goes. We can get the current location and so forth. We have all of our pin sites. And this app is interesting because it's not actually using WebAssembly. The Blazor WebAssembly app and the Progressive Web App, those were both WebAssembly based. They were running inside the browser using the WebAssembly based runtime. And as a result, they were also limited by the browser security sandbox. A lot of people ask me about Blazor WebAssembly apps when they see DLLs being downloaded into the browser and ask, is that safe? Is that OK? Is there any security issue there? And the answer is no, because the code that's being executed is being executed using that .NET WebAssembly runtime running in the browser security sandbox. So it can't do anything more than what normal JavaScript could do in a browser application. Can't do anything more and it can't do anything less either. It has all the capabilities of what JavaScript can do, but no more. So it is safe. In this case, though, we're running an electron. In an electron app, the .NET code is running in a normal .NET core process. And that .NET core process does actually have full access to the native capabilities of the machine. So if you want to touch the file system or open arbitrary network connections with this application, that's stuff that you can do in this application. So basically what we have here is a native desktop app with the UI built using web technologies, built using .NET, and its cross-platform. This will run on Windows, Mac, and Linux. So that's an example of what a Blazor hybrid app might look like, at least for desktop scenarios. This is something that we're exploring and investigating. If you want to play around with Blazor Electron, I think I have this URL set up. You should go to HBS colon whack whack Blazor Electron, aka MS Blazor Electron is the URL. And let's see if this is now live. I think I set this up this morning. Yeah, there we go. This will take you to our ASP Labs repo. And we have an experimental project that we're working on that integrates Blazor with Electron and there's a sample there that you can try out. All right, now the last stop on our spectrum from web to native is going full native. Actually having a native app, but instead of using web technologies to render the UI, we use native controls so that we can leverage the native controls of the device. This is an area also that we're investigating and experimenting with. I don't have a live demo for this area, but Blazor was architected from the beginning so that its renderer was extensible. The default renderer in Blazor renders HTML. And that's why you use Blazor to build web applications, not too surprising there. But the renderer can be replaced. In fact, you can replace it with a different renderer that renders to whatever you want, like you might render instead to native controls. There's a really cool demo that is just a tech demo and experiment. It's not anything that we have any plans to ship, but that Steve Sanderson did at NDC Oslo earlier this year. And what he did is he took the Blazor renderer, he replaced it with a renderer that could render to native Flutter controls. So he was able to build a Flutter app using Blazor, writing his code in C sharp. And normally Flutter apps would be written with Dart. It's a pretty cool demo. You can take a look at it at the link below, aka.msblutter. So Blazor plus Flutter, it gets you Blutter, I guess, where you can see Steve Sanderson a demo of that capability of Blazor. Now, again, this is not something that we actually plan to ship, but it just shows you what is possible with the Blazor model. This is very similar in nature to what you typically write with applications that are using technologies like Xamarin or React Native. These are applications that run natively on the device and then also render to native controls in a cross-platform way. We're looking at, could we do something similar with Blazor, like have a Blazor native that does a very similar thing. Nothing to share yet there, but it is an area that we are currently looking at. All right. So this is what the road map now looks like for Blazor. Blazor server is available today. It is supported in .NET Core 3.0. If you want to build a Blazor server app and deploy it into production, you can do that right now. Go ahead and download it, install it, it's great. You can start adding some rich interactivity to your existing .NET web applications. Blazor WebAssembly, we announced earlier this week. We'll ship next year. We're targeting May of next year. We'll start to see more progress on that in the months ahead. We're also starting work on Blazor hybrid apps and Blazor progressive web apps. You should expect to start to see previews of that functionality in some of the .NET 5 previews that will be coming up shortly. .NET 5 is expected to ship in November of next year, but hopefully we'll have previews of PWA support and Electron sooner than that. If you want to play around with Blazor WebAssembly apps as PWA's, there are actually some really nice community projects out there that you can download and install and those are really great to try out. Blazor native is not something that we have any concrete roadmap for, but it's an area that we are experimenting with and we hope to learn more about and talk to folks like you to see what we should do there. So that is the future of Blazor on the client. I hope you enjoy the things that you see, that you saw, I hope you're excited about them. Give them a try, try out Blazor and Electron with a sample, try out Blazor WebAssembly, give us feedback and of course make sure you download .NET Core 3.0 today. There is no time like the present, so make sure you're using the bits that are already ready available. This is a bunch of useful resources that you can go look at to get started with Blazor. Go to Blazor.net to get the bits and find the documentation. You can get the .NET Core 3.0 bits at .NET.net slash get-core 3.0. Go make sure you get Visual Studio. If you're on Windows, you're going to want to get the latest release of Visual Studio 16.3. We have a wonderful Blazor workshop if you want to learn how to program with Blazor and participate in the Blazor community. They have a lot of great folks like Chris Dainty who did the Blazor project and others that are building wonderful JavaScript interop libraries and component libraries. And with that, I'm going to turn the remainder of the time over to questions. Yeah, thank you. Check this out. Like I am sparkling. Yeah, that's pretty awesome. Yeah, I love that, yeah. Yeah, so thank you so much. We have a little special surprise. What? Another surprise. What is this? Lots of surprises today. Just go on over there, just walk over and let's get you- What is this guy? Let's get this over there right now. So I want everybody that's watching to know that this is actually Dan's 15-year anniversary at Microsoft. It is. And Blazor probably wouldn't exist without Dan. With a lot of people. With a lot of people working on Blazor. With a piece of the Blazor thing. And so I want to give you this gift. This is a Blazor pillow. What's even better about this Blazor pillow if you swipe up? Oh my goodness. What is this? On the Blazor pillow. That- Look at that. Is that spectacular or what? Is spectacular. Are these being fabricated at large? Because I love to just like lay my sweet head on that. Oh, this looks like a one out of a kind thing. I don't know. This, this, this, that is- Congratulations on 15 years, Dan. Thank you very much. It's been a good 15 years. To the next 15 years. Yes. Fantastic. Thank you. Can I borrow that pillow for a couple of weeks? I mean just maybe no? Creepy. This got awkward real quick. I'm so sorry. We probably have a ton of questions. Let's do it. Lots of people tweeted you in your brand new jacket. So it's pretty sweet. Do you want to take a look? Yeah, let's do it. So let's start from the left here and we're gonna get this question here. Will Blazor be a good choice for enterprise level web apps that need high availability, scalability and fine-grained services on the cloud? Wow, this is really good. Yeah, you know, I, yes. I mean, that's what it's built for and Blazor server in particular, that's what's shipping today. That's what's supported. Absolutely supported for large enterprise applications. So I think we think of Blazor as being particularly well suited to enterprise apps for line of business applications. Yeah, it would be absolutely. Yes, it is ready. So yes, yes. The answer is yes, yes. All right, what else do we have here? So what about this one? How do users update new build versions in a Blazor PWA? Oh, updates. How do you do that? These updates to new versions in a PWA. So I believe that's all managed by your service worker policy. Like the, so I think the inherent question is there is when you download a PWA, you can often set up a service worker so that it's available offline, which is effectively that caches the files. When you set up the service worker, I believe that's where you put policy about like when does the app go back to get the new files. And you know, I'm sure there's also a way where you can just force the app to refresh. But I think that's how you would do it. I'll have to, I'll double check on that, but that's my current understanding. We haven't done a lot of investigations in Blazor and PWA yet. We've just done some early, you know, proof of concepts like you saw today. This is an area that I expect that you'll see us looking more into in the .NET 5 wave. All right, next question. Any updates about supporting GRPC Web for Blazor? Also Blazor native on mobile. Yeah, GRPC Web, that's really interesting. So we support GRPC now in .NET Core 3.0. However, it doesn't work from a browser. You can't speak the GRPC protocol from the browser to your front-end servers. There is a variant of GRPC that you can use called GRPC Web. We don't currently support it today and we don't have concrete plans to support it yet, but we are talking about it as a potential area to invest. So don't know yet, but let us know if you think that would be interesting and useful. For Blazor native, well, we just talked a whole bunch about what we're thinking for Blazor native. We are right now in the prototyping and investigating stage. Blazor was architected from the beginning to support non-web native scenarios where you replace its renderer with some other renderer that can go to native controls. It's very similar to what React did. React started out as a web framework and then moved to support native apps with React native. Blazor can absolutely do the same thing. What the roadmap for that is yet? We don't know, it's still TBD. TBD, okay. We have another question here. APWA using Blazor. That's something really attractive, but for now my question is, which server auth integration is preferred like Windows or DB? Chrome has problems with Windows auth. So which auth mechanism should you use with a Blazor application? So that will in part depend on your hosting model, like if you're hosted on the server or if you're running on web assembly in the client. And really the type of auth you then use will depend on your app and will depend on your environment. If you're running in the client on web assembly, that's like a spa. So you use spa style authentication patterns. Typically that means using like open ID connects, OAuth like flows where you acquire a Jot token and use that with all of your HTTP client requests. You can also use cookie based auth from a spa that is possible. Blazor server apps, you have the whole set of auth options available to you based on what you're trying to do. If you're writing a line of business application and you have Windows users and you wanna let them log in, Windows auth that would be a great option. If you're writing an app where you need users to be able to register their own user profiles and have their own passwords that you wanna manage, then using Aspnit core identity for your authentication support is a great option. For the web assembly apps, using identity servers support for open ID connect would probably be probably what you wanna do. Fantastic, so just a couple of pictures, like this one to me is one, it feels like I'm there, right? It feels like we're there, right? It feels like we're there, yeah, it's wonderful. And another one, of course, Jeremy. Wow, looking sharp. If you follow him, you'll find he did another picture of me but not as flattering as this one. Jeremy, you gotta get my good side, buddy. Now for some Blazor jackets. For more important questions, obviously, can this be integrated with an existing .NET framework project? If so, how? Be a nuke it? That's a great question. Could you use Blazor with a .NET framework app? I mean, Blazor server obviously not because Blazor server is running on ASP.NET Core, like it's using the SignalR support in ASP.NET Core. So no, with .NET Core 3.0, you can't run that on a .NET framework app. Blazor web assembly is just static files. So it doesn't really care what is on the server. It could be actually PHP or whatever on the server. So technically, I guess you could use .NET framework on the server with a Blazor web assembly app but it's really been optimized and integrated with .NET Core. Like the full stack experience that we imagine for Blazor web assembly is you have .NET Core on the server, Blazor web assembly on the client, and we provide you all the nice integration points there. That's how we mostly imagine it being used but technically should be doable. And here's like a super awesome question. Mika, what does it say? Yeah, is that Blazor's future web development? Is Blazor the future of web development? Is it the future of web development? Not to try to put it on your spot. It's just wearing the jacket and you have a pillow with your face on it. Right, the plaything. Whatever you say is super authoritative when it comes to the future of web development. It absolutely is. For many, many web developers, is it going to be the only way that people write web apps going forward? Like some people ask like, does this mean that no one will ever write JavaScript again? Like, no, that's not what Blazor is going to do. There will be lots of people still writing JavaScript. There'll be lots of people writing in all sorts of different technologies. What web assembly did is it actually opened up the door for really any platform you want to be used in the browser. So I imagine there'll be people using Python and Go and Rust in the browser as well, but we are working really hard to make sure we have a great .NET full stack web development story. All right, so here's another one. And this is interesting to me because I remember when this was introduced, I saw Sanderson demo it to me. It was me, it was Damian Edwards and Fowler. And we just sat there were like, holy cow, this is ridiculous. The first thing I thought was perf. Is this going to be the same as the other? So any stats that show performance comparison between ASP.NET and NBC web and Blazor? Yeah, so there's a couple of different comparisons that you could do there. First of all, it's not really an Apple to Apple comparison. And the reason is like we talked about yesterday, Blazor is for your client web development needs. It doesn't replace NBC. It doesn't even do the same things that NBC and Razor pages do. Those are server render technologies that you use on the server. Blazor is meant to be used in the browser for a client web UI. So you don't even do that. When you want to do a server rendering, you do that with NBC. You don't do that with Blazor at all. But there is some interesting perf characteristics of Blazor that are worth mentioning. The Blazor is based on a diffing algorithm where you render your components. It calculates a diff and applies it to the DOM. That diffing algorithm has been highly optimized to be very, very efficient. When you run it on WebAssembly, there are some known performance issues with any CPU intensive loads on our existing WebAssembly runtime right now. That's because right now our .NET WebAssembly runtime is doing IL interpretation. And it doesn't have a jitter. It's just interpreting the IL on the fly. And that can be slower. We're working on that. We're working on supporting a head of time compilation to WebAssembly, which does give you back that native-like performance. We haven't had a preview of that yet, but we hope to have one as soon as we can shortly. So that will hopefully address the performance problems of running Blazor WebAssembly in the browser. When you're running on the server, you're running on .NET Core. It's super fast, no performance problems at all. All right. I think we have one more question. Yeah, we have time for one more, right? Yeah, we do. All right. Will Blazor support a per-raiser component server-side WebAssembly configuration in one spa? I don't know if I can parse that. Will Blazor support a per-raiser component server-side slash? That's like so many pieces here. That's why it's such a good question. I think, the way I choose to interpret this question. Nice. Nice. Well, you are wearing the jacket, so you can do whatever you want. I think what this is asking is, you could imagine maybe having a mixture of hosting models in the same app where this component is gonna run on WebAssembly, but that component's gonna run on the server. Maybe for whatever reason, it makes sense to do that. We don't have a first-class way of doing that today. It is something that people have asked us about. Right now, you either, you pick one or the other. You're doing Blazor WebAssembly or you're doing Blazor server. It doesn't seem like there should be anything blocking it, though, because, like I said, Blazor WebAssembly is just a bunch of static files. You could have a Blazor server app. You throw a bunch of Blazor WebAssembly files into its www root folder, and you can download those and use those. So, it seems like you could get it to work. I haven't actually done it yet, though, and it's not an area we've really played around with. Maybe that's something that we'll look at going forward. Well, this has been amazing. We have coming up a short commercial break-in afterwards.