We spend time with Dmitry discussing all the great things going on in the XAML space. The teams working on XAML tooling are very active and releasing lots of updates based on user feedback.

Hello, and welcome to another episode of adventuresin.net. I'm Sean Klayberg, your host. And with me today as your cohost is Wai Lu. How How you doing today? Hey.

Good. And Caleb Wells. Hey, yo. Hey, yo. How's it going?

I think it's going pretty well. Good. Everybody doing well? Yep. Okay.

Yeah. K. So we've got a guest today from Microsoft. His name's Dimitri Lylan. Hi, Dimitri.

Hi. Thank you so much for having me on. No. Thanks for coming. It's glad to have you on the show.

Yeah. So I think the topic today, I think, is is XAML. Right? XAML. X another market language.

Right? Now yes. That's market language. There you go. Yep.

XAML. Def definitely better than XML. Yes. Leaps and bounds. You know, I'll I'll say this that I think what you can do with it is much better than XML.

There you go. I'm not sure about anything else, but, the output is prettier. So can you tell us a little bit about yourself? Sure. So, my name is Dimitri Lylin.

I'm the senior program manager that watches over XAML tooling for desktop application development. So XAML, can be used for mobile development with Xamarin. That's a partner team. We we're basically 1 PM organization, but I don't work on that kind of day to day. I just make sure that we're all aligned.

And then I work with Windows that owns the platforms. So Windows owns WPF and, WinUI and UWP frameworks. And then we have our friends in dot net. And then my team owns the tooling for, WinUI, UWP, and WPF developers. So we're kind of these multiple teams making sure that, you know, once you build your XAML, you can compile and actually turn into some kind of application.

I've been, doing that for about a year. I've been with Microsoft for about 12 and a developer for 20, so it's been a fun career so far. Sounds like you're a very busy man. Very busy. Collaborating with all the teams, it's a lot of work, but it it's, the outcomes are are amazing.

You know, the things you can accomplish with the scale of having so many teams invested is really powerful. You know, I think XAML a language that's been around for about 15 years. It started with WPF, then Silverlight and Windows Phone, you know, things that are behind us. WPF is still with us, and then UWP and WinUI kind of in front of us along with Xamarin Forms. So it's a healthy ecosystem.

Not every single product that started kind of being powered by XAML is still there, but XAML as a language, is is very important to us at Microsoft. We have lots of developers. Basically, we have we have 3 development crews working just on tooling and then many, many more crews working in the various frameworks. So I will say it right off the bat when people tell me some part of XAML is dead, I I have to cringe because I sit in a room full of developers working every single day. I partner with so many teams that my meetings are 6 hours of meetings a day at time.

So definitely not that keeping us very busy. Great. So I've dabbled in in XAML and WPF, you know, things like that a little bit, but not too extensively. So, you know, why why does somebody need to use XAML? What does it do for them?

Sure. So XAML, is a way to to build UI. Right? So you let's say you you wanna build a desktop application with WPF or EWP, or if you're looking to build an application that that targets mobile devices, iOS or Android, and let's say you wanna use something like an abstraction of Xamarin Forms over it. In other words, you're invested into Visual Studio and c sharp.

Like, let's put that as a baseline. You're that kind of developer and you're looking to to build apps or either client apps on desktop, Windows desktop, or applications that run on various Windows devices like 10x devices that are coming out, HoloLens, Xbox, or you're looking to do something on mobile, iOS, and Android, we have a series of tools, that in that they're powered by c sharp as the programming language and XAML as the markup language for building the user interfaces. If you've never heard of XAML, think of it as HTML, right, and and CSS. Like, that's that's what XAML is. You define inside of it which controls, which hierarchy, which nesting, what are all the paddings and the boardings, where to put all the images, which common styles to apply, and then that turns into user interface.

And the way that XAML is built, sort of to be inter intertwined with c sharp is that c sharp can then pass data into that UI through either binding capabilities or by directly, you know, taking attaching to a named object and changing that object's properties. So think of all of all the things that are XAML turning into objects. Basically, they can be manipulated directly. But most people that build sort of any kind of serious applications will will use binding because it gives you a really clear separation of, you know, especially if you use, like, a pattern like MVVM. Right?

It gives you a really clear separation of your code and you have your UI. And your UI can sit on top of any view model. In other words, you can have the same user interface screen be reused by different view models. The data could be coming in from different places. It could be instantiated on demand and kept very clean and very separate.

And that's kind of one of the big benefits of doing it this way. In XAML today, you know, lots of developers, I can't quote numbers, but we have quite a few developers, depending on XAML every single day to get their job done, build their applications, whether that's enterprise applications, whether that's many applications, consumer applications, or mobile applications now with Xamarin Forms. So would you say it's kind of similar to like a desktop version of of Razor Pages? Yeah. Yeah.

Very, very similar. Yeah. Lots lots of technologies can be compared to it anytime you can think about how do you how do you have some file that has a definition of UI. Right? And, you know, if you're a web developer, there's some HTML file.

Right? CSS and JavaScript In XAML world, well, it's a XAML file that's attached to some sort of c file or vb.net file, which then, through dotnet, enables you to go pull your data down, do do your data manipulation, and either pass it directly into the objects that that are on the, you know, on the screen that have names, well defined names, or you use binding, which again is number 1 way to do it. So XAML enables that separation right there. Okay. So anybody that's familiar with HTML should be able to to look at XAML and be able to edit it and understand what it's doing?

I will say that if you have a lot of experience with HTML, it is not a huge leap at all. No. It's very, very close. Anybody who's built any markup language, if you've had any markup language, you could experience to build a UI, then you're very close to knowing what XAML is all about. Cool.

So what do you see, the future being with WPF, UWP, with, dotnetcoreand.net5. I know WPF is open source. How do you see the the transition, right, especially with dotnetcore3 now, offering more, interoperability? That could be, like, a topic for the whole show if we want to. Yeah.

There's a lot of Yeah. A lot to on that there. Yeah. So let's talk about the various ways to build up application. So I'm gonna put mobile aside for a second here.

Right? Like, if you wanna target iOS and Android, Xamarin. Forms, highly encourage it. It's powered by XAML and c sharp. It's and powered by Visual Studio.

So really good good way to build, build for those sort of devices. And, Xamarin. Forms also has unveiled the various dual screen experiences, so some of the 10 x stuff that's coming out of Microsoft. So definitely worth looking at, but let's just take a step back and look at the desktop scenario where a lot of enterprise developers live. You know, it's my biggest customer base.

It's people who are building, you know, full full Windows applications. A lot of them still targeting, you know, devices like Windows XP or Windows 7. That's where a lot of this stuff started, like in the Windows 7 era, and then, of course, Windows 10. So if you look at those those set of devices and even more modern devices like Xboxes and hollow lenses and 10x devices that are coming, Like, all of those devices need some sort of applications. All those Windows family of operating systems and devices.

And there's various frameworks for building those applications. And if you look back, kind of, what what is the oldest technology that that I think about in that stack, I think about Windows Forms. It's not even XAML. Windows Forms had a designer and c sharp. Like, there was no idea of taking your UI and and putting some kind of separation between you and the code because it wasn't needed.

The u the UIs were typically much simpler, and Windows Forms is still still around, still used by lots of developers. And as time went on, Microsoft decided, well, let's create some some more richer way to build user interfaces. Let's enable our developers that are targeting the desktop to be able to build beautiful applications. Right? And that's where WPF came from.

That's the heart and soul of WPF. It was to say, Let's take the power of Winforms, the ability to create you know, desktop apps really quickly, think about any any app with lots of forms in it or anything. Basically, there's still lots of Winforms out today that people depend on even open source apps. So Winforms is quite alive. But WPF allowed for the first time for something to happen that wasn't possible in WinForms for you to be able to create a hierarchy within your UX in XAML and manipulate the heck out of the hierarchy.

So you could take a button in WinForms, and it's just a button. You can change colors, you can change borders, but it's kind of a button. In XAML, you can decompose the buttons to all of its base base components and you can manipulate every single base component. So all of a sudden, you can flip the button on its head, make it stand sideways, and make it animate. Like, that was just not possible in Windows Forms.

And WPF has has existed for, like, over 10 years, like, 12, 15 years, whatever it's been. So XAML that's where XAML started, and that's where XAML continues to live. The one challenge we had as Microsoft with WPF and Windows Forms developers, where, again, we have lots of developers still building and maintaining applications, is how do we keep them on the most modern version of dot net? How do we how do we empower them? So It wasn't a XAML question, it was more of a dot net question.

How do we make sure that they are supported? We know that they have no intention in many cases to go and rewrite their application. So we brought dot net Core to these developers. We said, we will support you with the newest version of dot net as a runtime. We will give you the latest c sharp language, the latest vb.net language so you have all the power.

And and if you're really happy with your WPF app, you can continue to be happy with your WPF or Winform application. So we made a commitment to say dotnetcore will support these scenarios. If you had dotnetframework today, great. Go for it. Continue to use dotnetframework.

But if you want the performance improvements in in dotnetcore or if you just wanna be in the latest version of c sharp, you can just migrate your project, make a few minor changes, and beyond the latest dotnet. And we also said this is not a one time thing. Once we put you on dotnetcore, once you switch to that path, as dotnetcore becomes dotnet5, and dotnet6, and dotnet7, We're enabling that path for you. We will continue to upgrade WPF and WinForms, to be able to support newer and newer versions of this of this unified dot net. There's so much to unpack there.

I won't try to go into all the details, but basically that's a commitment to the customers. That basically says, We know WPF is not going anywhere. Right? So for me as a tooling team, that also means that, Hey, that's great. I know that's where my customers are and I can continue to evolve tooling in parallel to dotnetevolving.net to make sure you're getting more and more out of your developer day.

Right? So you're not as blocked by little things, you have, kind of things that make you make it easier to build something or just make it possible to build something. So that's that's my part of the job. At the same time, we made WPF open source because many developers wanted it. They thought that that would be a great way to sort of make sure WPF sticks around for a really long time.

So WPF was open source as part of the dot net core three train, And it really creates this interesting dynamic that one of Microsoft's oldest desktop frameworks is now doing some of the most modern things. Right? Technology wise, it's becoming open source. It's running in the latest dotnet, and the tooling team where I sit are giving it new features. In almost every single Visual Studio update something new happens for WPF developers.

So that's kind of like looking backwards through today for some of the developers that have been with us for the longest. And then, for developers that are sort of building just for Windows 10, UWP is the way to do that today. Right? So UWP is the way to do that today. Microsoft, in the Windows division has announced this WinUI project for the way they hope people do that kind of tomorrow.

It's taking UWP forward into, again, all the keywords will be there, open source, you know, more modern dot net, more control for the for the enterprise developers and how the app runs, how the app deploys, how it's packaged, and really separating it out from Windows. So, UWP is evolving in parallel. And again, my team does the tooling for both. So as WPF evolves, as UWP becomes Windy, as all these evolutions are happening, we're building the tooling to make everyday developer experience better for these customers and making sure that Xamarin Forms, kind of coming back to the mobile side, that we bring features that make sense for both of these developer audiences to both the audiences because Microsoft sometimes, in the past, has not done a great job there. We've had teams that are silos, and we are really committed to making sure that we have as much one XAML across the company as we can.

Cool. So in terms of the the tooling, so I know that, Visual Studio offers pretty good, like, tooling support for XAML. But, are there much tooling for for just Visual Studio Code? So Yeah. So so that's not an area where we're investing.

I get this question all the time. It's a good question. What about Versus Code? Right? And here here's the kind of the the semi simple answer to that question.

We we've invested into Visual Studio from the start. This is where we we've literally spent, you know, whatever it is, 1,000,000 of dollars of engineering investment. Right? Many, many developers over 15 years making Visual Studio better and better and better as a as a as a place to go and edit XAML, as a place to go and compile your application and get all the right dependencies and and make sure that everything is wired up and and optimized and packaged and deployed somewhere. Right?

I mean, there's a lot of complexity beyond just XAML that that sort of takes something from becoming code into a running application. So all that glue and all that investment is in Visual Studio. And for us to go and and start to redo a bunch of that work in Versus Code, well, we're not sure what what we get out of that. Right? Visual Studio, the the sorry.

The full version of Visual Studio is a community edition, so it's not like that's free, completely free. So it's not like people are blocked from getting access to Visual Studio. So it's it's not that. But the tooling builds applications for Windows, so it's not about making Versus Code run on Mac or Linux, right, as an advantage. Visual Studio and Windows is where you'll be building it because that's where your app will be running.

That's the only place your app can run. And we have a lot of rich tools that are, again, very specific to Visual Studio that we would never see them sort of manifesting the same way in Visual Studio Code without a lot of work. Right? And one I'll give you the one example. Like, the live visual tree that in real time inspects your running application and takes that hierarchy as XAML and makes it into an easy tree that you can sort of look at and understand how your app in real time and the view that's open right now is being com composed together and you can go down that tree, you can select an element, an element to select the code, like all of that magic.

That took us and Windows, I think, a year and a half to put together. It's it sounds simple once it's done, but the technology underneath to sort of pipe out a run a real real time running application, create a pipeline that can message back to Visual Studio, they can then visualize it properly, they can then connect back to the code, and then make a hot reload cycle work around it because we have hot reload capability, just like, you know, other modern UI stacks. So you can change code as the app is running. So to make all of that work together, I mean, that took years. Now imagine somebody says to us, yes, make it all work in Versus Code.

We're like, so we should we'll just have to stop everything we're doing, everything else that you want, and just make it work again in Versus Code where you you could already run Visual Studio. Like I don't know what the advantage there would be. I'm all for somebody to try to convince me, not not like I'm the final arbiter of starting a Versus Code XAML project. And not and also not like we're blocking the community from doing something. Right?

The community can go and start making, all sorts of things for Versus code and XAML. But we, as a team, we know where we need to invest, and we have so much work to do there that, my my I I have pretty good clarity for about a year into the future at this point of things that we should be doing. So I can I can honestly see where that makes sense? I've had, discussions with other dot net developers, web developers, right, who are who are using a JavaScript framework like React or Angular and using, you know, c sharp for their middleware, right, or, empty framework or whatever. And, you know, there's there seems to be, kind of a consensus, at least in in my group of developer friends, that, it makes a lot of sense to do Angular and React Versus Code because of the way it's built and designed.

And then for us, it makes the most sense to do your c sharp in Visual Studio because there is more tooling and there is more, more an integrated environment specifically for what we're trying to do there. So I I can see that. Yeah. Well, the the way to look at the two products is they do have slightly different purpose in life. Right?

Versus code is trying to be a lightweight code editor. It is trying not to get bloated with features and and panels and capabilities that slow it down. It's meant to be, like, you can you can get into Versus code in a few seconds, and you could be FID ing into your project a few seconds later, and it can just open up a folder instead of opening up a solution. So there's all these nuances of, like, that that really apply well to, hey, you have a bunch of Python scripts. You wanna quickly open them and start running 1?

Versus code is freaking amazing for that. You have a markdown file to edit. You have you have a React Native project. You you have a even some some of the dot net core projects. Right?

There's lots of project types that sort of really work well and don't need a ton of tooling from Versus Code itself. And then in Versus Code, over time, people have built, you know, some tools are pretty advanced in there. But everything is is an investment of of engineering time and effort. And Mhmm. When you have, you know, limited capacity, like, of course, we do as a dev team, like, we have 3 feature crews.

And if we were to go build the Visual Studio Code even to, like, 20% of what Visual Studio can do today already, we'd have to tell 3 feature crews to stop all pretty much all work except critical bug fixes and accessibility stuff and go work in Versus Code for a long time. And we'd wind up with the same features, but but 20% of them. You know? So what's what's the advantage? That that's why, we think the rest of you is good, and it runs already where your apps that you're building are gonna run anyway.

When it when it comes to tooling, if one of your team comes up with an idea, do you automatic and and it's and it's a good one. Right? Do you automatically say, okay. We're gonna make this work for all the teams? Or in some cases, do you do you have to say, well, that's good for this use case, but not for this one?

How do you how do you determine things like hot reloading? Right? All of your teams, I'm assuming, have it implemented and working in in their different environments. How does that work? Yeah.

So how how do we build features, I guess, is the question here. Yeah. It's it's a it's a question that I I love to talk about because it surprises people, and I and I'm I'm glad when it does because it shows that we are we're doing something that that I don't think Microsoft's always been known for in terms of how they build software. So let's take a step back and talk about Visual Studio before I joined the organization. Like, I've been with Visual Studio one one way or another for 7 years now at Microsoft.

I used to be in the consulting side, so I I was kind of outside of the feature building bubble. But 7 years ago when I joined, it was around Visual Studio 2013. And, and slightly before I joined the team, we started building Visual Studio very differently. The notion was before that, like let's go back 10 years before, we we were Microsoft at that time, I mean I wasn't even there, like they would just plan for years years, they would build for years years then they'd deliver a product, some kind of beta. And that beta gave people some ability to give some feedback on what Microsoft was about to deliver, but then you got that thing because it was mostly done.

Right? At that point, we were gonna make major decisions. If we if we made a decision that you weren't happy with, it was pretty much too late to have any any impact on the product. And then fast forward to, like, 2012 or so, 2011, the the the seed of change started. Then Microsoft said, especially developer division where Visual Studio's build started to say, let's give customers much more ability to to have impact on what the product shape will look like.

And how do we do that? Well, let's let's ship it in smaller chunks. Let's work for a year instead of 3 years. Right? And in that year, let's do lots and lots of previews and alphas and betas, and let's start listening to customer feedback.

Let's start looking at telemetry. Things that today seem like duh, like, seem like, of course, we should have always done it this way. But, I mean, it just wasn't the culture in the industry. The industry itself wasn't building software in such a rapid, such a customer involved way. So we've we've basically said we're gonna become customer obsessed, and we've been on this obsession journey for for many, many years.

It is it evolves every year like like any methodology. It does it's not static. Right? It's it evolves over time. But if you look at the Visual Studio the way it is today, we we basically build a we ship something called the Visual Studio Update about every 3 months.

That means every 3 months, within that time, you you as a customer, if you're paying attention deeply to what we're doing, you're seeing us do preview 1, preview 2, preview 3 of an update. And then within that 3 month period that preview 3 turns into r c, turns into g a, and then we start working on the next one. And then at some point we snap and we say, okay, this is now Visual Studio 20 blah. Right? Just like we went from 2013 to 2015 to 2019, or was it 2017?

Jesus. I don't even I can't even keep up anymore. Right? Like, it's 27 years. Then.

Yeah. Yeah. Right. Every couple of years, we we turn a major major, version over. But but for the most part, even within the major version, you can see anywhere from 5 to 10 updates within that major version.

Right? And that means that we have constant ability to ship features, and users have constant ability to give us feedback. So if we work for 3 months and you don't like what we did, it hurts a little bit, but it's not nearly as painful as working for 3 years because developers can make a lot of trouble in 3 years. Right. Now in that 3 months period, the most important question, though, I think is how do we decide what we work on?

Right? How do we decide, okay, I have 3 months of of dev time coming. I have many, many sprints in that period. How do I know what what we're gonna work on? And we use a bunch of different, I guess, points.

Yet at times, we we do make it up. Right? There are times where we we make sort of a big decision, Visual Studio online, for example. Right? Like, that's that's a huge investment to to to bring Visual Studio into into the cloud world, to make Visual Studio a lighter client over time and enable you to to basically install something lightweight in your machine and connect to a remote environment.

Right? It's, like, a huge huge thing. It's a huge change. It deserves its own episode on your podcast. But but for the most part, that that is, like, such a big investment that lots of leaders at Microsoft, they agree to go spend that money.

But then there's many, many, many smaller things. I would say the majority of the work. So, in in my list of changes, for example, I recently shipped the ability for you to, you know, when you're looking at XAML and the previewer above it, the the the designer above it, the ability for you to pop your code editor out at its own floating window. It wasn't a lot of work. It took our devs about a week to to make to make that, to make that code change and then, you know, figure out the icon and the placement and test it and all of that.

But the way we made that change was a bunch of customers said, we would really love this. This would improve our productivity. Mhmm. And then we took that feedback from customers. So there's an icon in digital studio on the top right that says report issues and send suggestions.

Right. So so all of that feedback comes into my team, like that pop up editor question, we look at how many people are asking for it, we look at who's asking for it, we think about it ourselves, we we take a look at historically, have other people asked for it in the past, and we make a decision, yeah, let's do the work. So, changing the zoom, making it so when you drag an image into XAML to turn it into XAML, like, all of those small changes we've been making are direct directly correlated to customers saying, please do this for us, and insufficient sort of volume that we thought this was a good idea. And then the work aligned to something that was reasonable for us to do within the time we had available in the developer team. So we do a lot of it this way.

And then when we go to something slightly bigger, like let's say how how how is hard reload originally developed, that was a pretty big investment on my team. We went out to a bunch of customers and we talked to them deeply about developer productivity and we saw that one thing could be really productive was if we can enable somehow for them to change their running application. Because the designers were not doing a good job at rendering their application properly because of their app complexity, but the running app was perfectly complex enough and could render everything they needed to. And we saw that opportunity for for increasing their productivity. So then we came back with a solution to these customers, these these sort of, like, large large accounts that we we were talking to.

And we said, what about this? And they're like, Yes, that sounds amazing. Can you make that happen? So we went and we made that happen. So it's 2 slightly different ways, but both very customer centric ways to build software.

If I just have a good idea, that's good, but I need to go validate with customers. There's almost no such thing as me just saying let's go build something. That that basically doesn't happen here anymore. That's good to know that the feedback button actually does something there. It's it's we we breathe it and we live it.

And when people tell me I had one customer, tweeted me, remove the button. You guys never do anything with my feedback. I said, I triage feedback every single day. My my dev leads triage feedback every single day. We we would not know what to do if that feedback button went away.

Like, there's no way we're removing that button. And then, of course, we have telemetry, and we look at social, and we and we look at what competitors are doing, but that feedback is very critical to us. Problem is probably there's there's so much feedback. You know, you can't really address every one of them. You have to prioritize.

And, you know, I've done feedback sometimes, and sometimes they get acted on and sometimes they don't. But it's you know, if there's not enough other customers that have the same issues that I have, you know, it doesn't get a high priority. Yeah. It it needs to be something that that we we can we can buy into a little bit. Bit.

There is some triage from the team. That's our job to go and make sure that whatever it is that we're going to build will make sense to our customers, will make sense to the internal roadmap that we know. Like, if we see some changes coming down the line and we're not ready to communicate yet, we're not gonna go do even a good idea of work that's gonna be thrown away. Right? Because we don't wanna waste dev cycles.

Other times, we get feedback that that makes sense, but we're architecturally blocked. Like, right now, I'll give you an example. We would love to add a lot more XAML refactoring tools into Visual Studio. Let me give you an example. Today, if you have a control and you have a bunch of, you know, properties and and and other things that are sort of styling that control that's in line and you want to pull it out into a generic shared style, that sounds like, yeah, that's very common sense.

Right? Why why don't you guys do that? Well, we we need an engine first that can look at XAML the way Roslyn looks at c Sharp. And until we we build that capability, which we're working on and it takes a long time, we we just can't build that feature cheaply. And if we built it today using some alternative method, we'd have to throw that code away.

So we sometimes take a take a break on some feature area if we're doing some underlying architectural work that will eventually unblock it. So that's one example. Other times, we we give good ideas but our engineers are busy. So maybe they're working on something with Xamarin. Forms where right now we're we're working to share a lot more code with that team, so that XAML IntelliSense feels feels the same everywhere, so that the way Hot Reload works is the same everywhere, sort of taking advantage of the most modern investments we have in sort of our our code stack.

So all of that could also delay some other work that that's a good idea, but developers that would do that work are just busy working in other things for, let's say, 3 months. So so we have all of that. It happens all the time. People sometimes do get frustrated. I I feel for them.

Like, they want a feature, and we we want the feature too, but we can't do it for some reason. But lots of stuff goes through that pipeline and winds like like a bug that goes through that pipeline. We we fix 20, 30, 50 bugs all the time and ship them in an update just from our team alone. And many other times, we we we will literally make changes to the UI or add features. The the one that that's coming up as an example is we had a bunch of customers tell us they for the live visual tree thing that we have, this component that visualizes XAML, if they're if they had an app that has multiple instances, we couldn't connect that thing to multiple instances.

And we were like, yeah. That's actually a design oversight. The technology can sort of do it, but we never build the APIs to enable it and the UI metaphors to enable it. So we're doing the work. We're gonna enable it.

And that came straight from customer feedback. So we gave some workarounds to the customers for now, and we're gonna enable that feature. You know, typically, we we get things done within 2 2 2 updates. So if we get the feedback and we're in update 4, by update 5 or 6, typically, the fee if we if we say we're we're doing it, we're committed to the work, we'll typically ship it out. So, again, we'd never have those things if we, we didn't get feedback.

That button top right button is so important in Visual Studio. I'm also guessing that some of this is also developer education. Actual developers knowing that a feature already exists or where to find it or how to use it. I was watching one of your videos, and you were going into detail about, documents online. And that functionality.

And I'll be honest, I have a design background. So I was looking at it, and I was like, this looks like Photoshop. Right? It's like it doesn't and I was like, very cool that you can hide stuff. But I think you mentioned, right, that there's a number of people that just don't realize it's there.

Yes. We we we sometimes get into that. I'll give you two examples. One one funny one. So so there there's this concept in c sharp called regions.

It's the ability for you to to basically take a take a bunch of code and and put it into, like, a visual block that you can collapse or expand. Right. And, back in Visual Studio 2015, before I joined the team, right, I joined the team just a year ago, so way before my time, we added that feature to XAML. So in other words, in XAML, you can collapse a bunch of XAML. And that's really useful if you're building, like, a really large resource dictionary.

Let's say you have a resource dictionary called, you know, button styles and you have a 100 buttons and you wanna collapse that into 25 button regions. Great. That's a great feature. So I had multiple customers tell me to please add regions into Visual Studio for XAML, and I and I was like, don't we have that? And then I started testing it, and I realized 2 things really quickly.

Number 1, IntelliSense, the way I would think to discover it wasn't lighting it up. It was there, but it was, like, a little bit awkward the way it was there. And then on the other side, I realized we have no documentation that you could find from Microsoft except the original blog post from, like, 2015 that tells you about it. So so we we went ahead and fixed IntelliSense. That already shipped.

And we are building a whole set of docs that I hope to ship, like, no later than summer that will document the heck out of the code editor because we have lots of things in the code editor that that are really good features that we don't have any official, like, docs.microsoft.com location for you to Google. You can't, like, Google XAML regions and find a doc from me. And that that's on me. That's my fault. So I'm gonna go fix that.

On the other side, we, we had a feature that was a little bit hard to discover and also had no documentation. Again, a fault of the team just being overloaded. And, you know, it happens. Like, you know, we have lots of people here, lots of features, lots of products, lots of priorities, lots of pressures in the team from partners and and, and customers. So things things go wrong sometimes.

There's no there's no excuse. Right? Like, we should. It's inexcusable. We should have had documentation from from v one.

We didn't. Sorry. But we went ahead and we built documentation. When we realized the customers were telling us every time we showed this feature called XAML hot reload, they would say, you have you have hot reload? Oh, like that Flutter thing, like these other, you know, modern frameworks?

We're like, we've had it longer than that. Mhmm. And it works for you right now. And people I've been on calls where people, like, really hold on. And they would, like, fire up Visual Studio, and they would put their app on the screen, and they change some XAML, and the app would update in real time.

They're like, this is amazing. They just changed my life. And they're like, great. Where can I learn more about it? And I'm like, oh, yeah.

Learn more about it. That's a good idea. Right? We should have a document. So we built, like, a troubleshooting guide if it's not working for you.

We built a what are the features? What are the limitations? It's all up on docs.microsoft.com. So we're really, you know, for a year now have been trying to backfill documentation and make features be discoverable through your favorite search engine, whether that's Bing or Google. You should be able to find information about it.

And we're also getting trying to get into a cadence of doing, like, a a recap vlog every 3 to 5 months where we talk about everything we've done in that time. Because Visual Studio has release notes, if you follow every release, you can find the XAML section in 14.3 sorry. Sorry. 16.3, 16.4, 16.5 as we release each update. You can find all the XAML features.

But we realized we have so many of them shipping over time. We'd like to consolidate them somewhere, so that will be one place. And then we're building up our documentation that by summer, I should be in a place where I'm pretty happy with most of it. So that's kind of on the documentation side. But we also are trying to make features more discoverable in the product, the IntelliSense fix that I mentioned, right, for regions.

The way you think you should find regions is the way you should find them in IntelliSense. And we've we've made that change, for XAML hot reload. We put a message into the into the running app where we had other related buttons, that says hot reload is available or hot reload isn't available because you could break hot reload or you can run your app in such a way that the debugger can't attach. So we need a way to tell you if it's available or if it's not available. And it also helps you just discover that it's there and then if the message annoys you, there's a little collapse button.

We love collapse buttons. We love settings. They let us do things that the users can opt out of or opt into. So that's the way that we're thinking about it. So you mentioned, Versus online a little bit.

And, right now, Versus online is basically a Versus code editor experience. But by Microsoft's working on more of a Visual Studio type experience. Yes. Will Versus online, have the XAML designers and things like that? So so the way to think about Visual Studio online and I am I don't work on that team.

It's a it's a pretty major project that, you know, even I'm not an expert on at this point, so I will try to do it justice. There's plenty of, like, blogs and other things that we're publishing. So if you search for Visual Studio online, you can learn a lot more than what I'm gonna tell you right now. But what I can just tell you from my team specifically is that Visual Studio online has has at least 2 elements to it. I'm not saying only 2, but let's talk about 2 of them.

The thing you mentioned, which is Visual Studio Code, in the cloud, in other words, like, you don't need to install anything, but you log into Visual Studio Online and you can use something that's like Versus Code to have a lightweight code editing experience in a web browser. And then there's this notion that if you want to go to the full version of Versus Code, you can connect it to the same cloud environment and you can take advantage of cloud build resources and other things that are in the cloud. So that's one thing that's there, so the whole kind of v s code side of the house. And it and it's the same team. Like, my my my org builds v s code, so it's not like some other team at Microsoft.

People building v s code and people building visual studio sit in the same building. They go to the same meetings, we're one big happy family. But on the Visual Studio side, the bigger tool, in that sense, we we're building the same capability. So over time, Visual Studio and in the demos we did back at Ignite, 2019 when we we we released this, like we showed that Visual Studio can also connect to the same cloud environment Versus Code can connect to. So we are building basically both Versus Code and and Visual Studio to support this idea of cloud environments and be part of the story that we're building for Visual Studio online.

And over time, my team is is figuring out the right ways to enable customer value in that scenario. We're still early in that thinking. Versus online is still an early product. It's like an early preview. So we have lots of time to figure this out and and we will.

But but, yes, we we we're committed to basically be be part of that experience for XAML developers. So at some point, there'll be some blog, maybe from me, that will say hey WPF developers, UWP developers, here's what's new if you want to use Visual Studio online as part of your dev in your loop. Right? But I'm not there to do that blog post like today, But it's something that we're very excited about. So in that dependency and the real studio will remain but the ability to access the online environment is what we're excited about here.

And, you know, I'll even be honest like we're even a little bit behind on like live share. Live share is the ability to to share your screen with another developer. XAML today doesn't light up properly a 100% in there, and we're we're gonna fix that. That's on our road map. Again, there's some infrastructural things we need to do first.

But but basically, Live Share and Visual Studio online is all in front of us. Great. So you also mentioned, WinUI. What is that, and and how is that gonna be different than, you know, UWP? Sure.

So, this is me speaking for another team. I always like to make that distinction. Like, we we build the tools for things like WinUI, but there's a team that sort of defines what WinUI is and what it what it means. And that team is the Windows team, the Windows developer team. So they have a GitHub repository called the the Microsoft UI library.

The this project which basically is being called WinUI 3. So if you Google for WinUI 3 GitHub, you'll find their GitHub posted road map. That's the best place to go learn all about it, and I'll give you a summary of of what that roadmap will tell you if you go read it. It's basically putting, Windows on a journey to disconnect UWP from Windows. One of the challenges that they kind of have acknowledged customers are bringing to Windows is telling them that, let's compare.

So if I'm building a WPF application today, I take a dependency on WPF in a particular version of that by depending on dot net framework. So I pick a certain version of dot net framework. As long as that version of dot net framework is on my machine and I'm targeting it, I get certain WPF capabilities in the WPF framework that I've built my app in, and therefore my app will run a certain way and that's that's very much independent of the operating system. Right? Except for that dependency in the dot net framework.

UWP for Windows 10 which is the only place where UWP runs was different. It depended on both the SDK you selected, but also the operating system that can support that SDK. So if you had some something like, okay, I'm targeting this particular version of Windows 10 with my application. And then Microsoft said, well, you well, did not Microsoft said, but you said to Microsoft, my app is great except my I'm having a problem. Like, customers are reporting that this control that Microsoft builds, this list box, is is doing something odd occasionally.

And then Microsoft's like, oh, yeah. You're right. There's a bug in that list box. We're gonna fix it, but we're gonna fix it in the operating system because that's where we ship list boxes. So your app, should should target this new SDK.

Developers say, great. Great. But your customers also have to upgrade their version of Windows or they won't see the fix. So that that's a problem, because in in one world, yeah, in one world, develop developers, you know, might not care if their customers aren't upgraded, they could just tell their customers. But in many other worlds, you don't have that control, right?

You don't have that ability to tell customers to just upgrade, or customers can't for various reasons. So WindUI is taking UWP out of the operating system. It's taking the controls, the rendering stack, the input stack, and it's making it an open source project up on GitHub that is a bunch of NuGet packages as a way you can consume it in Visual Studio, and then you can build a UWP app using those NuGet packages. And next time we fix a list box or next time we add a new control, you can just rebuild your app with the latest NuGet packages, and it should still run this in the same OS where your previous app ran because those packages are being down leveled to to pretty early version of Windows 10. So the range is basically increasing.

Right? So instead before it was like, you're targeting this SDK and this SDK. And if you wanna use all the features between the 2, you've gotta have all your customers be on the latest version of Windows that supports the SDK. And now we're saying, alright. WinUI supports this version of Windows.

And as long as you're using WinUI, your app will run-in all those versions of Windows. And when you rebuild your app with the newest NuGet package, it'll just run-in all those versions of Windows. So that's the modernization that they're doing and they're open sourcing it which is great because it allows the community to finally get their bug fixes in. You know, maybe there's something that you really want and Microsoft can't commit to doing it for you in WinUI, but you think that this thing will make a huge impact on the community and you open up a GitHub issue and you have 50 people support you and you're willing to submit a PR to us, you'll be able to do that. And before, you couldn't because Windows was closed source all the way in the developer platform.

Right? You you could file a feedback request, but you couldn't submit a PR. So both dot net is open source, WPF is open source, and WinUI is is open source in this version 3 flavor, which is the the thing they're working on this year. Is that where I'm gonna be excited about it. Is that where, the idea of XAML Islands comes from?

Yes. So XAML Islands is part of the same project. It's, it's a project that tries to bring some of the modern UWP controls to to older frameworks like WinForms and WPF. So the notion is if you're a WPF developer and you really love the highly optimized data grid or something in the newer version of Windows, you can still use it as long as you're willing to tell your customers you can only use that wpff on Windows 10. Right?

That's the one dependency. Okay. Or you can use an island to bring it in. So, yes, there's documentation up on on the documentation side all about XAML Islands, and that's a story that's also evolving in parallel to WinUI. Lots of lots of stuff going on there.

The team has, like, weekly meetings that I'm in. They're working really hard on it. Great. So just this week, Microsoft was demoing some, Windows 10x dual screen devices. What does, Windows 10 x mean for for XAML and and developers?

It's it's a continuation of Windows is the way that I look at it. Right? I I think 10 x is, you know, kind of a new enough topic that it, you know, not every Microsoft employee should talk about everything. So I I will say that there's there's been a bunch of things put out by by people that make a lot more money than me that talk about 10x, and you should go listen to them. There was recently a, Microsoft 365 developer day.

It's a live video broadcast. You can see they published a bunch of blogs. Kevin Gallo did a blog post. There's a bunch of documentation. There's emulators now, for for Windows 10x that you can download and play with.

Dual screen devices are coming at some point. So all of that is building up. And what that means for me as a XAML team is that there's more places that can run XAML. So I'm excited. My my job is good.

You know, XAML XAML apps, so UWP apps can run on these new devices. So, it just kind of increases the footprint where where my tooling can take people, and that's really exciting to me. I don't know if we I'm gonna have to break open my wallet once they come out, I think, but, they they definitely look cool. They look cool. So, Dimitry, what are some of the things you're most looking forward to, in XAML in the next 6 months to a year?

Yeah. Quite quite a lot of stuff in the pipeline right now. I'll give you just a couple of examples and Okay. You know, I I would say I did a blog post on the Visual Studio blog. If you search for what's new in XAML, you'll find a blog post from just a little while ago where you can kinda catch up if you've if you've missed between, like, 16 o, which is 2019, the first release, and for 16 4.

We did a lot of stuff. And the biggest thing there is, like, XAML hot reload. Take a look at if you've never seen XAML hot reload, the ability to change your UI when your app is running, that's that's a thing to look at. And we've we've we've done lots of other things there to sort of make the productivity of of XAML tuning better. But we have a bunch of things coming in, like, 16/5, 16/6 time frame that I'm really excited about.

One of them is the data data binding failures window, for example. It's something we've published as an extension, on the on the Visual Studio marketplace. It has it has been a bane of my existence. Like, I used to be a WPF developer before I joined the team many years ago. And and, and I wish this feature was there when I was building my WPF apps for customers.

And I know to this day people wish this feature was there, so I'm I'm helping make it happen. And and that is taking binding failures out of the output window and putting them into a dedicated panel that you can pin, that you could sort, that you could search, that works with every flavor of XAML, WPF, UWP, Xamarin. Forms. If it's XAML, the failure should appear there. And that's a feature we're bringing in the next couple of updates that I'm super excited about.

Because we've been able to make it an extension for early testing by customers, we've gotten, you know, hundreds of people telling me thank you. So that feels really good that we're sort of on the right track there, and we're still gonna make it better and optimize it over time. So that that that is a really exciting it's like it's kind of a small feature, but it's also a big real world productivity features because there's no such thing as perfect binding. And because any real application is built with binding, having to look for those failures inside of a constantly running output window of information, text information is really hard. And you could easily miss it, miss something, or not see something.

This makes it a panel just like the error dialogue, which is sortable. And right there in your face, you can pin it. The failure happens. Boom. It appears in there.

And when you're done, you can hit clear and start your next session. So that's one thing I'm really excited about. We're also, looking at making the designer to be a bit more user friendly in terms of making it fast to access common to change common properties or or take common actions. Let me give you an example. If you, put down a tab control and you want to change how many tabs it has, like, that that's not an easy thing to do unless you jump into the XAML.

But let's say you just wanna use your mouse and you wanna point at that control and quickly add a tab, like, that's something we're bringing. And the the way we're doing that is that through through this feature called suggested actions over time, you're gonna see more and more controls light up with a little adorner on the top right when you click on it in the designer. And in that adorner, when you click on that, it's gonna open up a panel of the most commonly changed properties based on telemetry. So we know which properties you're most likely to change, and we're gonna make those easily available. Before, you'd have to go to the properties panel and scroll through hundreds of properties looking for, like, the most common ones, and we're just putting them right there.

And then right below those properties, we're gonna put common actions. So whenever it makes sense to have some action against the control, we'll do that, and we're making it extendable so that partners, you know, our our control vendors or anybody in the community can also do things in there. And we're thinking of some some interesting scenarios we can enable once that feature is sort of stable. So there'll be more and more stuff coming coming to make that possible. And we're also doing a bunch of really interesting investigations right now.

One of them we talked about earlier. We're looking at live share, we're looking at video studio online and thinking about what we can do there. We're looking seriously for a long time now and we're getting closer and closer to be able to do something about it which is the whole resource management, XAML resource management. We know people want more visualizers, more refactoring. That's something we hope to work on in the near future.

And, we we have a couple of ideas to make the, you know, make the designer better. So we're also suggested actions is kind of the beginning of that. So we're hoping to to do that do that as well. But I will caveat a lot of this work with with the with the idea that if something more important comes up, we'll have to do the more important thing. Or if we do an investigation and we realize the solution isn't, you know, sounds good on paper, but isn't really making customers more productive.

And we we we often early test things with customers. We get a bunch of people on the call. We show them things. We'll we'll run them through examples. And if we're getting bad signals for that, we'll we'll stop work.

We'll we'll sometimes redo something. Sometimes we'll throw something away. But I'm just kind of laying out the the idea that lots of things that if you're a XAML developer today that you care about, we're looking at it. We're looking at the resource management. We're looking at modern technology with things like live share.

We're we're trying to make your your life better. And that button in the top right that I mentioned is is your way to to give us indicators that we're either doing the right things or the wrong things because you can report problems, you can report bugs, and you can report suggestions, and I hope people use it. A lot of stuff coming down the pipe. Good to hear. Okay.

So we'll end with our picks. You wanna go first, Y? Okay. So, yeah, I was I was actually struggling with fix this week, but, I I go through phases where, I generally, like, listen to, like, sometimes I listen to, you know, podcasts and other times I listen to audio books. But lately I've just been listening to, like, a lot of music.

And I grew up in the in the nineties. And I think music that you listen to during your your teen years, like, no matter, you know, where your taste go, you you always go back to it. So I was a big, like, nineties rock grunge person. So I thought my pick today would be, the Smashing Pumpkins album, Melancholy and the Infinite Sadness. It's like this.

So it's like an album that was written in 1995, but it's like this epic, like, double album back when they were at their peak and, you know, back when, you know, albums were so popular. So there's just so many so many great tracks in there. And I yeah. It's it's really good, but, I wouldn't bother listening to a new stuff though. So Are you a big are you a big Nirvana and Pearl Jam fan too?

Yeah. Big Nirvana. Yeah. Yeah. Oh.

Showing my age, though. Yeah. I wasn't a teenager, but in the nineties, but you know, most of mine I agree with you. Teenagers, is your influencer for music? Because eighties rock, that's for me.

Yeah. Yeah. Alright, Caleb. What's your pick? My pick is Deepak Chopra's, latest book, Metahuman.

I've been listening to the audiobook. It's, it's really interesting. A whole different way of looking at things. Sometimes I like to flip things on their head and look at things from a whole different perspective. So if you like that kind of stuff, I've enjoyed reading it.

It's like philosophical type book. Is it, Yeah. It's, it's really, the idea of, personal duality and being able to have an emotion while also being able to be separate from it. And the idea that, we're all living in, a really, really, really good simulation that our brains are making, on a millisecond by millisecond basis. It's it's an interesting read.

Cool. Sounds pretty deep to me. Yeah. Yeah. It actually it actually reminds me of the stick song, the grand illusion.

Yeah. You're probably not familiar with it, but, yeah, it's about we're all just living all in the grand illusion. Yep. Right. Yep.

Alright. So, Dimitry, what's your pick? Sure. So, I've really been been into sci fi lately in terms of books. Unfortunately, I I have a newborn.

I have a job. I have lots of things that always get in the way of, like, sitting down and reading. If I'm reading, it's usually somebody's emailed to me about some Visual Studio's AML feature. So that's not been realistic. But what has been realistic is all the time, I'm commuting and exercising, doing anything where where my attention can be given to something else partially, and that's been audiobooks.

So I decided to go through, and I've read through, like, 4 different trilogies now. I guess I'm on the 4th trilogy. But I'll highlight the one that I'm mostly excited about, and that's Red Rising. That trilogy took me by surprise. In fact, I almost stopped reading the first book because the first couple of chapters were kind of boring.

I thought that I was like, What is this? Some guy, he works in a mine, his wife his young wife kind of has this rebellious nature and she gets killed. And I'm like, Okay. I don't get it. How's this sci fi?

It's not compelling to me. And then, 5 books later, I love every character and I can't stop reading it and there's a 6th book coming and I'm, like, tweeting at the offer. What the hell? Ship your book already. I can't wait.

There's, like, a scene in the book. The guy that offered does such a good job. He gets you so emotionally, like, connected to the characters that there was there was there was a scene where the main character might have been killed or something like that and I had to stop reading for a while. I was like, I can't take it. If he gets killed I can't take it.

Screw this. I like this guy too much. So you really align the characters and there's a great take on where humanity might go in the book. So without spoiling more, I'll say that that it takes you on a journey that that's, you know, one of the many possibilities of where we might wind up as a species and kind of just close enough and far enough away that you can sort of relate to it. So I strongly recommend that whether you're reading or listening, go go check out Red Rising and just get for the first 25% of the book.

It's gonna be a little bit tough at first, but after that, you will not stop. Well, congratulations on the newborn. You you definitely don't look tired enough to have a newborn. 10 months old? For 10 months.

Right? So I'm past the You've got some sleep. Yeah. Yeah. The first 3 months were like a psychological experiment of how how little sleep I can get and still function.

Right. I'm just blessed to work at Microsoft. They give you 3 months off as a dad. So I I took that 3 months, and it's really saved saved me. I don't know how people do it and have jobs.

I don't know. Yep. Caleb's got a 4 year old, so he Yes. Yes. He hasn't too far through past that phase.

No. I I completely understand. You remember. Alright. So my pick this week is gonna be, some 3 d software.

I've dabbled from 3 d rendering and 3 d animation from time to time. And there's an, a free really production quality, 3 d software out there called Blender. So if you ever want to mess with modeling and animations and it can even do 2 d animation. So it's got all the texturing. It's got lots of different powerful features in it.

You know, people might have heard of 3 d Studio or or my end, things like that. But this is pretty close to that much power in 3 d rendering, but it's free. So go ahead and check out Blender. What's the learning curve like? I've been meaning to play around with it, but I'm just like, I don't want to invest like 6 months learning it kind of thing.

But is it easy you can pick up? Yeah. If you can understand, you know, in the three-dimensional space, the newest version, version 2.8 really improved the, the interface environment for being able to move things around and and assign textures and and, kind of make the models the way you want to be. So, yeah, check it out. And, I'll also send you a link for, some a guy that really does a lot of, good tutorials.

Cool. Good to do. Alright, guys. So, Dimitry, if people wanna get ahold of you, how can they re how can they get in touch? Yeah.

The best way is, I'm very active in Twitter. So my Twitter handle is at Lylen.com. So just hit me up there. My DMs are open. I'm always willing to hear from people.

And, also, if you file some feedback, against anything's ML tooling related, that'll pass in front of me. So it's another way to get my attention. Alright. And if any of our listeners wanna reach out to the show, they can get in touch with me. I am on Twitter at.netsuperhero.

So go ahead and follow me. Give me some feedback for the show. If you got suggestions, send them out to me. We're always here to listen to you guys. So thanks, everybody, and thanks to Mitrice for taking your time out of your day.

Thank you for having me. Yeah. It's been fun. Yeah. Yeah.

Thank you very much. Good talk. And we'll catch everybody on the next episode of adventuresin.net. Bye,