 On today's Visual Studio Toolbox, part two of my conversation with Scott Hunter in part one, he gave an overview of what was revealed at Build, and in this part, we have a nice discussion about what it all means for .NET developers. Then there's the question of, what do you use to lay out the design time? Is it XAML or does it wind up being something entirely different? I suppose. I think it ends up being a couple of things. First off, there are different flavors of XAML. That's a good point you might remember. Xamarin Forms is a flavor of XAML, and UWP is a different flavor of XAML, and then WPF is different flavor of XAML. There's three of them that are slightly different. I think for .NET MAUI, we're probably, Robert, we're going to use the Xamarin XAML, because we want to be compatible with the previous Xamarin apps. I wouldn't want to have .NET MAUI come out, and it'd be very difficult for a developer to move their existing application to .NET MAUI. But we want to do something new as well. There's a pattern that has gotten popular with some of the web frameworks today. For example, maybe you've seen Flutter, Robert, where you actually define your UI and code. There's Swift UI on the Apple platforms, where you define your UI with code. We are going to take a stab at that as well. With .NET MAUI, we're going to give you two choices. One is to go build your UI with XAML like you're used to. The other one's going to be to build your UI directly with C-Sharp. Yes? Yes. That gives you a couple of cool benefits. If anybody's used XAML, XAML is a really rich, really powerful platform and it's got some complex bindings to it. Sometimes those bindings are complicated. If you want to bind a Boolean to your screen, you have to write some code to convert the Boolean into a format that XAML understands that they can display. If you've ever built a Blazor application, it's much simpler. You just put a Boolean there and running your UI with C-Sharp will be very similar to that. We just put a Boolean there and we'll just deal with it. It's going to give you a simplified binding. It's going to give you a new way of running UI. We're not going to choose for you. You can choose if you're a XAML customer, then you continue to use XAML. If you want to try the new C-Sharp syntax, it's catching on for other platforms that we want to experiment with it and see if it's good for our customers too. Or maybe, which would be my ideal world, we have actually a designer who you don't have to write any code. Thinking all the way back to the WinForms days, when you would use the designer and sure you could write code, but who would do that? Now, obviously, it's a lot harder. WebForms was very much you dragged a button and you put it down there and that's where it was. XAML is much more adaptable, but given that all the XAML I write is essentially an object with properties and then hooking up events. I have this conversation with Dmitry all the time, but I would love there to be a designer which, sure, maybe it spits out XAML, maybe it spits out C-Sharp, maybe it could spit out either one, depending on what button I clicked. But that would be my ideal cool world. Yeah, the designers are interesting. We struggle with designers, especially when you get to something like time in Maui because when you support all these different devices, the designers were great, especially in the WinForms era. In fact, I would say WinForms is unusable without a designer. You can do simple stuff, but building a complex UI would be very hard. The challenge we run with the WinForms designer is WinForms is all based on pixels, which means you basically say, if draw this control at pixel point 10 by 10, and then make it 30 pixels wide and 20 pixels tall, the WinForms designer tends to struggle when you get to, here's a 4K laptop or an 8K laptop. Because of that pixel perfection, it doesn't scale very well and you struggle with it. We hit the same problems with the web form designer as well. The web form designer basically wrote HTML in the page that absolutely plays to control in the exact same place, which means if you resize the browser, the control will just disappear off the screen. So there's been a trend as of late, away from designers and the trend is probably super aware of this, Robert. It's got a notion of what we call hot reload or hot restart. And the idea is, well, what if if I just change my source code, my device reflects that change instantaneously? What if in a web app I change my HTML and the web app reacts instantaneously? Is that a better experience or a worse experience? And I think we're honestly, this sounds crazy because we're like 18 years into this stuff, I think we're still learning. I think the challenge is nobody's built a good designer that handles these displays at scale across all these sizes. But that said, the dotnet malware effort we're working on is going to be a mix of XAML with the designer and it will be a mix of C-sharp starting without a designer. But you never know. I don't know if you've ever seen, have you tried? Have you ever seen SwiftUI, Robert? No, I haven't. So they take a pretty cool approach. I've not used it a lot, but they've kind of melded a designer and Swift into the developer tool at the same time. So as you're moving over some of the source code, you get some popouts and stuff like that do some pretty cool stuff. And I think that's an area that we'll explore too is there a way to take that native C-sharp, let it sit in a source code file, but as you hover your mouse over the various parts of it, you get some of those designer features. We actually did this around 2010 for Aestinate Webforms. We found the problem with Aestinate Webforms was the designer struggled to show you what the market would look like across the various browsers, Firefox, Chrome, now Edge. And so we had an approach where instead of actually trying to be in the designer, we brought the designer to the source code. So as I'm moving through my ASPX file, I get the little chevrons around the code that will bring up the designers and the dialogues and stuff like that. But I think this whole space is a space you should just keep following us on Robert and try the bits as we come out and let us give us feedback. I am writing a couple of apps that need to run on multiple platforms. I'm writing apps that both me and my wife will use. It needs to run on my Android, her iOS. We both have surfaces. So I'm obviously writing doing the apps in Xamarin and they look great on Android. They look great on iOS. And that of the box, they don't look as great on Windows. This is not meant as a criticism. It's just a bit of a statement of fact. So if I want to write an app just for Windows 10, I could use WPF or I could use UWP and then transition into Win UI. If I'm writing the app for iOS and Android, I can use Xamarin, but I could also use UWP and then use something like Uno to get it into iOS and Android. And that also gives me WebAssembly. So if I'm doing just iOS and Android, it seems like a pretty clear choice, Xamarin, because that's the first class scenario. But for somebody that also wants to build the app that's going to run on Windows, what's your recommendation as to how to handle that? I think for what you just described and where we are exactly today, you are correct. I think that your choice, you really have two choices. One of those choices is you can build a web application and the web app, you can make a web app that is responsive, meaning that it changes size according to the device you run on so it will look good on an iOS or Android device. It can look good on the Windows device. But that requires you know web technology. Right, or requires me to learn it at my advanced stage. Well, advanced stage. No, but it is, I would say for you, if you're used to building, you know, native apps for a long time, it is a learning curve. And but we want to make sure that we address in the dynamic space, especially, we want to say if you're a web developer, we're going to help you bring your web developer skills so the app can look good on all the devices. But I think you really nailed it when you said, if you want to run an app that runs on, you know, Windows and iOS and Android, you can do it with Xamarin.Forms today, but it maybe it doesn't look as good on the Windows device. I think that's something in .NET MAUI we want to address. With .NET MAUI, we want to get you to a point where you can build a pretty good looking app that runs on Windows, Mac, iOS and Android. You know, right now Xamarin.Forms, as you said, has been primarily optimized for the iOS and Android devices. In some ways, the ability to run it on Windows is actually just a kind of a historical thing of making it where you can run it locally for better interlude performance. And then, as you said. Guardless of whether the app's ever going to ship on Windows. If you're building a Xamarin app, you need to do the Windows app because that's the best way to debug it. Right. Fastest way to build it. But we've not spent a lot of time making that a great experience. And I think that's one of the goals of .NET MAUI is to make that a great experience. Okay. And then of course, as you said, if you just want to run it on Windows only, you've got a variety of choices. You have WinForms, you have WPF, which are the things we've historically shipped. And a lot of developers, I still find that WinForms is the... I can be most productive in WinForms. Even though the tech for WPF is better or the tech in some cases of UWP is better, then there's nothing faster than just going and dragging a button and double clicking and it stays exactly where you want it to. It's so, so easy. And as you said, the designer is so amazing there. But I do think there is a trend, as well, when UI's going to come out. And as it does, I think it will replace UWP. And I think of UWP slash when UI is, if you want to take advantage of the best hardware on the Windows device. That means you want to be the best touch support. You want to run on all the monitors. You want to run on all the versus the Windows 10 consistently. I think that in the long run will be the best experience. But it hasn't shipped yet. And then of course, I loved your notion of the UNO stuff. UNO's got some stuff where you can bring a lot of the UWP style tech and they can run it using WebAssembly, the same tech that Blazor uses. Yeah. They can run that on iOS, Android devices as well. So I do think that we are at a point where we have kind of UI soup. And just like I've tried over the last couple of years to really clean up .NET with .NET standard and now .NET 5, I think it's one of the things that my team wants to work on is making these UI stories an easier choice for developers. Yeah. I mean, those are always going to be multiple ways to do things. It will never, unless you really did come up with a designer that was so cool that no one would ever again write code. But other than that, there's always going to be multiple ways to do it. It's just, I don't know. I'm almost to the point where I think I'm going to write the app. The beautiful thing is all the code is the same. All the views, the models, the view models, all the helper functions, that code is all written once and can be used everywhere. So that's nice. And then the UWP XAML would look pretty similar to the Xamarin XAML. I've already got the screens all laid out. So it's just a question of duplicating and most of the properties are the same. So it wouldn't be that hard to redo it in UWP and then start exploring WinUI later on. And then you get the project, then you get Uno, so you get WebAssembly. So you wind up for not a huge amount of work getting everything you want. So I don't know, maybe that may sound like the best way to go about it. I was going to say, in the future, WinUI could be the rendering tech underneath a .NET Mali application. Yep. At which point you're going to get the kind of what you were asking for, Robert, where basically you write that XAML once and you get all the power of WinUI on the Windows device and you get a good looking app on the iOS Android device too. That's... We'll let you go do another one of these in a year and see where we're at. So one last thing I want to ask you about Blazor and WebAssembly. I know Rocky Latka, for example, has been telling me for five years that WebAssembly is going to be the end of desktop apps. Is that true? Is it now true? What do we think about that? I don't think it's now true. To me, I think WebAssembly is something different. I think of it, it could be the way that all apps are built and run on WebAssembly and alarm run. The cool thing about WebAssembly is today it runs inside of the browser and it runs inside of a sandbox which means it's not allowed to touch the file system or the registry or all the things you don't want to have an evil app touch. And WebAssembly is supported by a ton of languages, c++, .NET, Go, a variety of others. So there's a lot of potential there that imagine you have an operating system that can run WebAssembly. Well, now you can use all these different technologies and the apps run on that device. There are some limitations in WebAssembly today. If you took your WinForm application or your WPF application and said, I'm going to go make a WebAssembly version of those, WebAssembly doesn't yet support threading. So if you're doing multiple threads, you're going to have some challenges. Anytime you want to touch some resources on the machine, you might run into challenges as well because as I said, it runs in a sandbox and so if you want to talk to the disk, you need to go either through storage APIs which don't really land in the real disk or you have to go build a web backend for your application and you call the web backend and it talks to the file system. But give us a couple of years and let's see where things are. I think it does have some exciting possibilities of being a universal runtime for all apps. Cool. Thanks so much for your time. Thanks for the great overview of what we did at Build and then I really enjoyed this type of conversation. Thanks for doing this. Thanks for having me. These are good questions and hard questions and I think you're not the first developer to ask these questions. Or will I be the last, I suspect. All right. I hope you guys enjoyed that and we'll see you next time on Visual Studio Toolbox.