Episode 120 - Inside Avalonia's Cross-Platform UI Toolkit and the Quest for Quality Documentation with Mike James

Mike, thank you ever so much for agreeing to be on the show and for coming on to the show. This is, it’s an immense pleasure to be talking to you, a person who was previously on The Xamarin Team and now is at Avalonia and stuff, which we’ll go into in a minute. It’s great to have you with us today.

It’s great to be on. Thank you so much for inviting me to come and waffle on about things that I find interesting.

Well, that’s what this show is for. I was saying to someone the other day about part of my goal for this show - this is the fifth year, right? So part of it has been, let’s talk about a cool thing that people are making with .NET, or a cool thing that you can make with .NET, or a cool thing that you can use .NET to help that you could plug into .NET and help you do stuff.

Right.

And the other half is there’s people out there who maybe like I’m a server-side specialist, so WPF, Xamarin, all of that passed me by. Right. The last piece of UI I ever built was Winforms. Right.

Oh, wow.

It’s all brand new.

Okay. I mean, Winforms is definitely not brand new. Yeah, I guess a lot of people have fallen into those camps of kind of client-side or web dev. When you’ve done, your web dev is that is that typically on kind of the API and back ends, or are you in the weeds at front end node JS and all of that nonsense.

So when I do front end stuff, it’s always under great duress, right? Drag me kicking and screaming to it just simply because my own personal opinion and we’ll do a proper intro for you in a moment, but my own personal opinion is that it’s not entirely possible to be a full stack dev because what does the front end stack mean? Obviously it’s HTML, CSS and JavaScript, but then are you using Vanilla JS? Are you using React, Svelte, Angular, Vue or I’ve probably missed a whole bunch there. That’s probably going to really upset some people, right? And then on top of that, there are limitations in those frameworks because of how our devices work, right? The limitations are getting fewer and fewer over time, but there are still a few limitations there. And then is it JavaScript or is it Typescript? If it’s JavaScript. Is it es6, es2015, e9850? There’s too many variables there.

But they say that choice has a paralyzing effect. And I find that when I do any web development, I am mostly paralyzed. It is terribly difficult to get started with and, like, coming into it is that you want to do a file new project. I can spend a day just trying to get something to webpack and to compile and minimize everything. And yeah, I struggle with web development. I do it, but I do struggle with it. So I can understand why you would pick the back-end pieces and the APIs. That’s a much more pleasant experience, I think.

Yeah, and it’s because there’s fewer choices, I think. Well, from my perspective, there are fewer choices. Which from my perspective, again, it means that there’s more opinionated ideas of how to do stuff, and that those opinionated ideas kind of like a Java back end API, will work similarly to a. .NET seven, .NET eight, ASP .NET Core back end web API, because they’re both essentially doing exactly the same thing and because they have evolved alongside each other, then ideas will have cross pollinated.

Whereas I feel and again, I may be getting this wrong, but this is my experience, my opinion, a lot of Javascripty stuff is very opinionated, but because they’ve all come from different directions, because everyone’s coming from different directions and indeed solving different problems, right? Like comparing Angular to React is a non starter because Angular is an entire framework, whereas react is like a pluggable architecture that you can bring in to help you with state management and all that kind of stuff. Whereas Angular is very, “you will do it this way and you can’t deviate,” and React feels a little bit more, “you want to bring this in, that’s fine. Or you want to bring in something else totally fine too.” And neither of those is necessarily wrong or right. Because they’re just two wonderful different ways of doing stuff that I wasn’t there from the beginning. And so I don’t really get how it all fits together.

I mean, it’s horses for horses, isn’t it? And I think that’s true for basically every technology. We’re going to talk today about Avalonia, and I’ll obviously talk about my history with Xamarin and how I got into kind of native client-side development, but there isn’t a right or wrong answer. And people will often come and say, “well, which technology should I use?” And it’s like, “well, there is no one answer to that. I can give you my opinion, and that opinion is based on my lived experience of using the tech and my needs. But your needs might be totally different to what I’m looking for. And so I can help you come to your opinion, but I can’t just prescribe something to you like, you should build every single app with Avalonia.” I’d love to be able to say that, to be honest, but it’s not a genuine or useful response to such a question.

Sure, you’re absolutely right, because then what you then find is it would be great for you, great for the team and everything, but then you have a number of native client developers who only have experience with Avalonia, right, and they’re only solving the problems that Avalonia can solve. They’re not solving problems that other frameworks or the libraries or the entire systems can solve then, right?

Yes. As I say, there’s pros and cons to everything and it’s just about weighing them up.

Yeah, absolutely. So I wonder, Mike, would you be able to give us a bit of an intro to yourself? Because we’ve been talking for like six minutes now.

We have. Straight out of the gate. We’ve digressed. I do this because just an interesting conversation, certainly more interesting than hearing about me.

So I’m Mike, I started cross platform development. Like my first job out of university, I was building apps with “cute” or QT. I’m never quite sure how to say it. I’ve heard some people say it’s cute, but it does feel a bit strange to say I built with cute.

I’m a cute developer.

Exactly. That I’m a cute… well, you are. So, yeah, that was C++ and that was like back in the day of cute four. So it was cute widgets. And then they kind of changed everything with Qml and it was more like Xaml, to be honest. But I missed that phrase or phase.

So cross platform goes all the way back to the beginning of my career, and my second job was at Xamarin and I worked there all the way through the acquisition. So that was again cross platform, but this time C#, which was a program when I was 13 in VB .NET. Please don’t judge me for that. We’ve all made terrible life choices at some point. I have repented, and I now use C#. I’ve tried F#, but I’m not clever enough. So yeah, I started building apps with Xamarin and I worked for them. And the mission there was, how can we help C# and .NET developers build applications for non-traditional Microsoft platforms? We want you to be able to take your existing code and your existing skill sets and target iOS and Android. And later on, MonoMac became commercialized with Xamarin Mac.

Even further on from that, we were acquired by Microsoft and we kind of overnight went from a company that I thought was huge at like four or 500 people to 100,000, and everything changed. Like we stopped using Google, so we had like Gmail and Dropbox, as most startups do; and we became an Outlook shop using Office 365. And again there’s pros and cons with every technology choice.

Yeah. So I worked at Microsoft for seven years and I recently joined Avalonia. So I’m sure many of your listeners know what Xamarin is, some of them possibly don’t. They’ve definitely heard of Microsoft, but they might not know what Avalonia is. So Avalonia is an open source cross platform UI toolkit. And it’s a decade old. It’s got contributors from all over the planet. I was having a look. If we look on GitHub, it says like there’s 200 and something contributors, but we’ve got some other analytics that goes goes back even further through the history because the project was renamed and it’s actually showing over a thousand contributors, which is crazy to me.

But it’s this big project that’s part of the .NET Foundation. Most months it’s the most active and popular community project within the .NET Foundation, and it enables people to build cross platform apps for non-traditional platforms using .NET. So Mac and Linux have kind of been the bread and butter. Obviously you can build for Windows, but that shouldn’t be a surprise to anyone. We’re bringing out soon. Hopefully by the time this airs, we’ll have V11 shipped, and that’s enabling iOS, Android and Webassembly. So the idea is bring your Xaml skills, bring your C# skills. If you’ve ever built an app with WPF, you are now an expert in Avalonia. You’ve not had to do anything, you just are, and you can target these new platforms.

And I joined Avalonia as the CEO just a couple of weeks ago now, but I’ve been engaged with the project for years and years. We’re trying to build a commercial side in order to help us support the people that have been grinding for a decade for free on the open source side. So we want to commercialize value adds to help us support the open source side.

Sure.

I was having a conversation with my friend Scott a few days ago about the different, I want to say expectations that open source developers have. And all of these are perfectly valid. All of these are perfectly valid. There’s some folks who are like, “I want to make a thing, to make the world better and I’ll give it away for free.” And that’s awesome. Brilliant. And then at the other end of a spectrum of open source goals, “I’ll make the thing, I’ll give it away for free and then I’ll like question marks profit.” Right? And then there’s a number of different people in that end who are very from my perspective of looking at how people have interacted on Twitter and Reddit and GitHub and stuff, there’s multiple different within that one statement, there’s multiple different spectrum points or whatever.

I have experience of dealing with people who are like, “it’s open source, but you should pay otherwise grrrrr!” And there’s other people who are like, “it’s open source and there’s a paid version if you want. I don’t mind doing it me on time, it doesn’t matter.” Right. And I feel like there is a conversation to be had, perhaps outside of this one, on setting those expectations for both the open source developers and the consumers of those open source projects.

Because I’ve felt for a while that there’s that Xkcd comic and I keep stepping over you here, Mike, I do apologize, but no, no, there’s that one XKCD comic of, you know, “here’s all the internet infrastructure and there’s this one block that’s maintained by a person in a basement in Finland.” We should be supporting those people, right. Because everything we do, we are literally standing on the shoulders of giants, right?

Totally. And I think that this is actually a really interesting topic. And I’ll be frank with you. There are some days when I’m interacting with the community where I just have to turn off notifications and I say, “okay, I’ve had enough with the community today.” Sometimes I deal with the community and I’m overwhelmed by the support and the gratitude and I’m sharing messages with the team and I’m like, “look at the awesome work you’re doing.”

But there are others that they expect an awful lot. And I get it, they’re building, often times they’re betting their business or sometimes it’s a pet project, but they’re investing in our technology by using it. And so we have some obligations to them to deliver something that works. But the thing is, Avalonia, as I said, it’s been developed for a decade. And the guys that started it and are still with us all the way through, they’ve worked really hard to get it to where it is. I mean, this is used by GitHub, Schneider Electric, Jetbrains and Microsoft. There are people using it that have deep pockets and the could invest in using almost any other technology, but they’ve picked to use Avalonia. And I’ll be honest with the enterprise side of things that we’re definitely supported there. And we have our support contracts, so we’ve got agreements in place and they’ll sponsor the project as well. So we’re able to give back to the people that have helped build Avalonia.

Our goal is to be able to basically employ everyone that’s contributing. That would be our ultimate, but we don’t want to take anything away. There have been other very useful .NET libraries that have changed their licenses. I won’t name them specifically, but there was controversy around it. And actually I think that the request that was made, it was super reasonable: If your business is making over a million dollars in revenue a year, pay us a couple of it’s. And I was like, well, " yeah, the work that that developer and that team have done is years worth of work. And you’re not going to be able to rebuild that unless you’ve got a deep knowledge of a very specific niche." And I look at that license fee, and I think that’s a bargain. I would gladly pay that, number one, to support the dev number two, because if I need that, then it’s really good value.

When we were looking at how to monetize Avalonia, we’ve always been really clear, Mike, the leadership, that it remains open source. We’re not changing the license, it’s MIT, and it will remain MIT. We want to generate revenue to support the project by creating value adds. Now the first one of those is XPF, which it targets a totally different community.

So we’ve got our Avalonia community that are building apps using Avalonia, but there’s also a WPF community and there’s a Winforms community and a kind of micro community in WinUI

We were looking at, “well, how can we help and target some of the communities outside of Avalonia based on the decade of hard work to help raise revenue so that we can employ more people,” employ people that have, as I say, they’ve worked tirelessly for a decade.

And we get questions kind of every week, “when’s V11 going to move from preview?” I think it might come from a position that they assume that we’ve got like hundreds of developers and that we’ve got a big management structure where we set a deadline and we’re going to do everything we can to hit that. And we’re going to ship something when we’ve got our big conference, like, “we’re going to release by .NET conf”. No.

And I’m really keen with the guys when we talk about this. Is it’s ready when it’s ready. I don’t want anyone burning out. I don’t want to tell the guys, “you need to pull some all nighters and work weekends.” That’s not healthy. We’ll ship it when it’s ready. And if you need to wait another month, I’m genuinely sorry. But you know, the current version, 0.10, that’s stable, that’s in production, that’s workable. You can use that. And we’ve got people building with the preview versions, and Unity have pushed an app to production with it. So if Unity are happy to use it, then you probably all right yourself.

But yeah, I think there’s open source is difficult. I think interacting with any community can be difficult. But we are our community. We built for it as a community project. The company came into existence only three years ago because of the huge demand from companies. So we’re very cognizant that the community comes first in everything that we do. And some days the community is harder to deal with than others. But we still run every decision that we make and all of our future plans through the lens of “what’s best for the community.”

Sure. See, I like that because it feels - not that Avalonia ever was - but it feels less like it’s, “hey, guys, should we go in this direction today? No. Should we go in that direction?” It’s less like decisions on a daily basis. “We have a roadmap.” Perhaps I haven’t asked you that yet, but let’s say we have a roadmap. We’re going to go in this direction. And like you said, “we’ll ship when it’s ready. We’ll get there when we get there,” right? So stop asking, “are we there yet?” Because if we were there yet, we wouldn’t be sitting in the car, would we? Sorry, that’s some flashbacks from when I’ve had to deal with the kids. I do apologize.

Yeah, no, I used to be one of those kids just constantly, Are we there yet? And I’m really impatient with stuff, and if I had unlimited resources, we would have shipped by now. But as I say, we don’t want to ship something that isn’t finished. And it’s not just code. The code is obviously a huge part of it. V11 has got a new compositional renderer, which is much closer to how UWP and WinUI handles rendering. So it’s a huge improvement over the approach that was closer to that of WPF. So our previous renderer [was] nowhere near as good or as performant as the new renderer. That’s a big change. We’ve changed how the styling system works. That’s another huge change. We’re currently in the process of rewriting how the dispatcher works because as we’ve been developing XPF, we’ve realized that actually the reason the WPF dispatcher works in the way it does is genuinely useful. So we need to implement some of that gained knowledge into Avalonia UI in order to enable XPF. So there’s the code element, which is a huge undertaking, but then there’s also all the auxiliary bits to it.

So documentation, samples, making sure that we have all of that. Because if it’s not documented, it doesn’t exist. One of the key things for us this year and we talk about the roadmap is I want us to have the best documentation for building cross platform UI apps with .NET. One of the things that I remember when I worked at Xamarin was people used to say to me, “you have the best documentation,” and I never really appreciated it. But even Objective-C and later on, Swift developers would come and use the Xamarin docs to understand how to build their iOS apps. And yeah, the penny never dropped at the time of just how good the docs were. I hear the opposite most of the time now when I’m speaking to people about Avalonia, and that’s because it’s a community project, it’s been built over ten years and people will put in incredible PRs with no docs and the team look at it and they go, “do we reject this incredible contribution because it’s got no docs? Shall we write the docs? Yes, let’s create an issue and we’ll get round to it,” and then another PR comes in and if I had finite resources, we would solve that.

So, yeah, we, we hear a lot that the, the docs need improving and that that’s something I’m really cognizant of and we’re investing a lot, a lot in trying to solve that for V11. But, you know, we’ve got a technical writer that’s working on it at full speed, but again, it’s done when it’s done. I’m not going to release docs that’s half finished because it’s no use to anyone. So bear with us. And this is all on the community side as well. We’re sponsoring this work from the revenue, the modest revenue that’s generated from the business.

But I’d rather be spending that revenue on employing the people that are contributing to the project so that they can work on it full time, rather than having to pay a technical writer a lot of money to come in and rework our entire docs. Because the community are quite happy to complain about it, but then they’re not happy to contribute to fixing it.

I will finish on this one moan about this because it’s still quite raw for me. It was on Reddit, so you know a place where you can have challenging discussions with people and somebody described our docs as being absolutely horrible and I kind of shot to the heart, it was like, “okay, yeah, I know our docs need improving and we are improving them.” And somebody said that it was useful feedback and it’s like but it isn’t. To tell me that our documentation is absolutely horrible. I can’t action anything with that. Like, you said that you struggled with something. Tell me, what did you struggle with? Where did you hit a dead end and need to go and dig into source code? Or where were you, like, digging through our old GitHub issues or through the Telegram chat? Tell me where you struggled, create an issue for it and we will get the docs written. But if we don’t know what we’re missing, therefore where you’re struggling, it’s really difficult. So saying that the doctor absolutely horrible, it upset me a little bit, but yes, I feel like I’m just on a tangent at this point.

No, I totally get it. As the great Jermaine Clements of Flight of the Concords says in - I think it’s the - Hiphopopotamus vs. Rhymenoceros, “be more constructive with your feedback, please.”

Very much.

Yeah, because, “this sucks. And I hate it”. I’m using my own words here. I’m not saying this is what the Reddit user said, but, “this sucks and I hate it.” Well, okay, how do I make it not suck? How do I make it so you don’t hate it? It all comes down to compassion, right?

And I’m totally up for jumping on calls with people and taking on genuine feedback because I want us as I say, I want us to have the best docs. I want us to have the best UI framework. I think we’re probably there with the best UI framework, but a lot of people don’t know about us, and when they get started, they hit a roadblock. They don’t know where to get help, and so typically, they push through it and they resolve it. But I’m sure that there are some people that we’re losing in that process, and I want to fix that. I want to make it the most delightful developer experience imaginable for a .NET developer.

But, yeah, we need the feedback in order to do that. So telling me it sucks, zero points in terms of helpfulness. Opening a GitHub issue to tell me where you got stuck, that’s like a solid six out of ten on helpfulness sending in a PR with the actual, “this is where I got stuck and this is how I fixed it,” it doesn’t need to be perfect. We’ll make it fit the style, we’ll rewrite it so that it’s perfect. We’ll fix the grammatical errors, but contribute something, get involved with the project. Thousands of other people have been doing it. It’s a community project.

Yeah. From my own experience of providing sort of when I get stoked and then I solve a problem, the immediate thing that I do is I open up a notepad - or it’s Obsidian these days, but whatever technology you’re going to use to store your plain text notes - open up a note and then just start writing bullet points. “Click this button, type this command.” It doesn’t have to [be detailed], because it can just be I mean, obviously submit it to the community because it will help, but it can just be, “click this button. Click that button, type this command in. I don’t know what this is, but do this,” right, because then at the very least, you then have the steps to get to the, you know, to pass on to someone else. If you want to submit it to the community, then I’m sure I don’t want to speak for you here, Mike, but I’m sure that there will be someone on the team who, like you said, can take that and go, “right, I’ve got it. I can make that into a page. I can get the screenshots for you. You don’t have to. Just tell me vaguely what you did.”

Yeah, we’ve got a guy, actually, that works for us, and he basically lives in our community chat. And when people ask questions, he’ll go off and he’ll create a sample to answer that specific question. And then he’ll come back an hour or two later with the sample on GitHub and he’ll share the link and then it’s in our sample repo. That’s super, super helpful and I love that. But the people have to know to come in and ask a question and if we don’t know where people are getting stuck, it becomes very difficult to know how to help.

And I think it’s probably easier for… so we don’t have any telemetry in our tooling. And this was something that Microsoft is quite big on. Microsoft fully aware of what issues you’re hitting and when you’re hitting them, and how often you’re creating different types of projects and how often you’re working on, you know, there’s monthly numbers on how many active WPF developers there are for any technology. And if you look at Visual Studio code, think about all the telemetry that’s collected in there. The can tell you how many flutter developers there are on a given week. Telemetry data is king, isn’t it, in terms of understanding usage? We’re an open source project, we don’t collect any of that. And we’ve considered it. So we’ve got our Visual Studio extension and there’s a guy from Jetbrains that builds the Rider extension and we’ve considered, “well, should we put telemetry in there so that we can capture number one usage and also where people are getting stuck, “and every single time we come back to, “probably not.” We would love to have that data, but do we really need it?

Personally, for me, I don’t feel thrilled when I’m giving up that kind of data. So we err on the side of, “let’s do without.” But there’s definitely an argument there for if in a couple of years time we’re in the same position where we still don’t know what people are doing. We may need to investigate adding some form of telemetry, but it’s not something I want to do. So send in your issues, your pull requests, communicate with us, jump into our chat and tell us where you’re having issues and yeah, just talk to us, it’s the most helpful thing.

Sure. I also totally get your opinions and feelings on telemetry, right?

I feel like with a number of projects now these could be programming projects, these could be frameworks, these can be IDEs and tools, it could even be websites, right? I know people who will leap directly to the most complicated possible way to do it, with the most amount of logging and telemetry and analytics and all that kind of stuff. And then they’re like, “we’ve got no users.” Of course you don’t, because you’ve just spent six years building telemetry and logging and analytics and the most complex thing ever. Whereas I threw together a HTML page today that has a sign up form and I’ve got 15 people signing up, right? That’s 15 people who are genuinely - these are all examples, right?

But there’s a difference between jumping right towards that telemetry and all that kind of stuff, or going the grass, I suppose. grassroots I don’t know if it’s the right term to use, but the grassroots way of saying come to… “you tell me.” Because I can’t see because there’s also in one of the niches that I exist in, podcasting last year and the year before, there was a version of Audacity that got released with loads of logging and people just got really upset and, “we’re not going to use Audacity anymore” right? And you mentioned VS Code. There is a project called VS Codium, which is VS Code without all of the telemetry, but it also means you don’t have some of the debugging features as well, because some things are closed source within VV code. And I have this feeling that if you become big like Avalonia, like Xamarin and all these kinds of teams, you release something massive that’s doing really well. Then you add telemetry, you might get a core portion of your audience, your users go, “I’m not touching that any more because I don’t know what it’s doing on my computer.” For real, legitimate concerns.

Absolutely, that’s precisely there. You’ve described why we don’t want to add telemetry and why whenever it’s been discussed, and it’s been discussed very briefly, “well, maybe we should,” and it’s like, “no, we’re not doing that.” As you quite rightly point out, there are people that don’t want that data to be shared. Quite rightly. Because whilst it helps the project, you don’t know precisely what’s being shared, and with GDPR as well, how we handle that data. It’s a quagmire. Our core competencies are building cross platform UI frameworks for .NET developers. I do not want to be getting kind of waste deep or even neck deep into compliance for storing usage data and all of that nonsense.

No, I totally get that. And with that said, let’s pivot back to cross platform Uis for .NET stuff.

Yes, because we digress constantly.

Oh, totally. Yeah, no, but that’s fine. That’s why I like having these conversations. It’s open ended. There isn’t really a list of questions because we can go anywhere and it’s a safe space for people to share their thoughts and opinions on what’s happening with different tools and all that kind of stuff.

So you mentioned earlier on that one of the things that you’re hoping to have released by the time that this episode drops. For context folks, we’re recording this on the 17th of March and I’m planning to release it on June 9th. So there’s a bit of time. So everything that Mike has already said and will say has the caveat of we’re talking in the past to you in the future. Right. Anything can change between when we’re recording and when you’re listening. So anything can and will change and I’m not going to hold you to anything, Mike. If you want to say that the sky is green, I’m like cool, that’s cool with me. The sky is green, let’s go with this.

Well, hopefully I won’t say anything that’s totally wrong and I like to under promise and over deliver, I think that tends to be the best strategy.

But yeah, in terms of cross platform UI, hopefully by the time this goes out, V11 will hit stable. We’ve got preview 6ix coming, as you say, on 17th, we were thinking it would be this week. It’s probably going to be over the weekend. We think we’ve locked down master and we’re just running tests at the moment. Preview Six has got some changes to the dispatcher. We weren’t expecting a preview six, to be perfectly frank with you. We thought, “we’d do preview five, we’d do a release candidate and then we’d be happy days, it’s done.” But we thought there’s a couple of things that we want to put in here and make some breaking changes. And this is really important because API stability is like, it’s something we prioritize massively. So with each major version of Avalonia, we want to use that major version as an opportunity to make breaking changes. And the once you’re into your point releases, then we’re not going to make anything radically different. So if we don’t kind of do the tidying up that we want to do with V11, then we’re going to have to wait like two years until V12.

So as we find things that we’re like, “okay, this probably needs to go in.” It’s like, “okay, well let’s create another preview.” And who knows, maybe by June 9 we’ve got like preview 30 or something and I’ll have gone totally gray. But as I said before, it’s done when it’s done.

Absolutely. So you also mentioned earlier on XPF now I think… thinking back on what we’ve talked about so far, I know from my experience I got to Winforms and the went away and did some server side stuff and then I’ve come back. It’s now the future or it’s now the past for the people listening. But right now, whilst we’re recording, it’s the present. Anyway, some things happened and a whole bunch of UI technologies happened. And WPF is one of them and I know that from my own googling around. I can make a WPF app. I can have it run on Windows. Fantastic. Lovely. Not a problem. And I know that when we first started chatting, XPF was like a thing that had just been announced. And I’m like, “oh, what’s this? Oh, wait, what? You can take an XPF app and throw it onto a macOS device or onto a Linuxy device,” but not everything?

Could you speak to how? Because again, I’m speaking of you again, but also for people who’ve just heard that and gone, “holy moly guacamole, I need to go and get XPF because Jamie said,” could you set their expectations? Because I’ve obviously just blown a hole in everything.

No, what you said is basically right. It’s magic. We’ve got some very clever guys that work on Avalonia UI.

Let me give some context. So you’re quite right. It allows us to take WPF apps and run them basically on top of Avalonia. How and why did we do this? Because we’ve got our UI framework. So the why is that we created this company three years ago in response to the demand from enterprises for support and also for projects. And the projects make up two thirds of the revenue for the business. And some of the projects are like multi year. One of the big projects is a two year process and the billing is extremely large. But we don’t want to grow old porting WPF apps to Avalonia. It is something we will do and we are more than happy to do it. If you have a WPF app and you want it ported to Avalonia, get in touch, we’ll give you a quote. We just don’t want to do it forever.

And part of the problem with that is that, as I say, it can be a multi year process. It’s expensive to basically halt development of your application, to migrate it to any new technology. It takes time and you’ve got the opportunity cost as well. So not just the cost in either outsourcing or having your debts do it. Your competitor is going to be six months, a year, two years further ahead, and all you’ve done is reinvent the wheel. You’re stood in the same place, but in a slightly different outfit. WPF developers. I mean, WPF was released in what, November 2006? So it’s 16 years old. It could buy a lottery ticket, it could get married with permission from its parents, Microsoft, at least in the UK.

It’s an old technology in the scheme of things. And there are companies that have built applications using WPF, and these are mission critical applications. The businesses live and die by these applications existing, and they need a modernization strategy. And the one that’s coming out of Redmond is “rewrite the app.” It’s like, that’s high risk. It’s expensive, and it’s going to take a long time. And depending on which technology you pick to rewrite to, it can be really high risk.

And sometimes it’s just not even suitable. Like, one of the suggestions it was at .NET Conf was, “modernize your WPF app to Blazor.” It’s like, Well, Blazer is a web technology. It’s not in any way suitable for some of the apps that a lot of the apps that we see are medical devices or embedded devices for measuring particles. And putting that as a web app possibly could be done, but is it the right choice? All of your team are XAML developers and you’re saying, “okay, now you need to go and learn this Razor syntax and this web tech.” And I don’t think it’s a viable solution. And given the amount of interest we’ve had importing, we didn’t think it was a viable solution. So, yeah, we’re porting all of these apps, loads of customers, more demand for porting than we can realistically service, and we don’t want to grow our porting WPF apps. So we were looking at, “well, how can we fix this?”

Avalonia UI is like, the spiritual successes to WPF. It’s really similar. But there are some differences. We haven’t just blindly copied the WPF APIs because then you would end up with all of the limitations. And not every decision that the Avalon team made back in the day kind of passed the mustard. Is it passed the mustard? I think that’s the correct phrase.

Let’s say it’s the correct phrase. You’ve said it twice. I’ll say it “passed the mustard,” There we go.

Yeah. If it’s not, I would be curious because to me that sounds right, but I often get these things wrong.

Yeah. So the project has never been about blindly copying WPF, but it’s similar enough that most companies, if they’ve got a well architected MVVM application, we can do a port pretty quickly. We’re doing a port at the moment for a big financial institution. They’ve used MVVM. They’ve got some nice DI. So it’s basically just a case of updating XAML files and changing the styles. So it’s not difficult, but it’s tedious. Depending on how many views you have, it becomes very time consuming.

So we decided, “let’s build a compatibility layer.” And when we were discussing how we do this, we were thinking two options. We either do what we’ve done with XPF, which is fork WPF, or we build some kind of migration tool where you could migrate your app to Avalonia and it would just, like, convert your APIs. I was quickly told why the migration tool was a terrible idea. And that’s because the third party dependencies, you don’t have the source code for if you’re using Telerik or Infogistics or ActiPro, you don’t necessarily have the source code for that. So just a migration tool isn’t going to bring your entire app across. So we decided, let’s go with the forking of WPF and make it run cross platform.

So Microsoft made WPF open source. It was very generous of them, but they kind of I like to describe it. It’s a phrase that Nat Friedman from Xamarin used to use of, “just throwing something over the fence. It’s like, you forget about it, you just lob it over and it’s done.” So they open sourced WPF and then kind of forgot about it. They weren’t accepting contributions. And there were lots of questions about, “can this be cross platform?” And just to get it to build on a Windows machine was arduous. So we decided, well, thank you very much, Microsoft. We’re going to take that and we’re going to fork it, and we’re going to replace all of the low level implementation with Avalonia. So we’re going to leave the presentation framework and presentation Core largely untouched. We’ve had to make a couple of changes, but it’s a really big point for the team of, “don’t change the code in those libraries. “It remains the same.

And what we’re doing is we’re replacing MIL Core at the lower levels with Avalonia. And so this means that you can take your WPF app and you can run it on macOS, and Linux; and Webassembly, and iOS, and Android will be coming next year. But you can do that by only changing the csproj.

So yeah, you open up the csproj, You change the project SDK. You need to remove the UseWPF because you’re not using that any more. So it’s Project SDK, UseWPF. and you hit F5 and you’re now running on XPF. And you can take those binaries and you can do it on a Mac, you can do it on Linux. Nikita, who is like one of our many resident geniuses, or geniai? he’s incredibly bright. He develops on Linux. And he saw that Paul Thurrott had liked one of our tweets, so he jumped onto Paul Thurrott’s GitHub, found an application that he had written, he cloned it to his machine, opened it up in JetBrain’s Rider, updated the Project SDK. That app had a dependency on Winforms, so he had to add an additional attribute, which is <UseXPFWinformShims>True</UseXPFWinformShims>. With that, he hit F5 and he was now running this WPF app. And it was literally like 30 seconds to do that migration.

Wow!

Yeah. So it is magic when it works, but it’s not a silver bullet. There are times when and there are things that we can’t do.

So I mentioned the Winform Shims. We’ve got Win32 shims as well. And these are really needed for those Telerik and DevExpress controls where they’re oftentimes it’s a Winforms control masquerading as WPF. And so we can support that, and we do support it. We’ve got customers that have got entire apps that are just full of Telerik and DevExpress and ActivPro and all the various control vendors. And we do that by at the moment, my guys take the application, they attach the debugger and they run it on XPF. And they’re looking for where are these controls reaching down into GDI and Win32 APIs. And then we’re providing those shims to make them work cross platform.

So that’s why we’ve not given out XPF as a demo for everyone to run. Because if you just took it and your app in any way was calling into an API that we hadn’t created a shim for yet, then it would crash and that would be a horrible experience for you. And you go, “this doesn’t work”" In your case, it wouldn’t work.

But if you are using Pure WPF, then it is magic and it just works. If you’re not, then our guys will make sure that those APIs are available. And we think within six months or a year, touch wood, we’ll have all of the shims in place required to run like 90, 95% of all applications cross platform without needing to speak to us. So we’re building an analyser tool that is based on the old mono analyzer, so it’s called MoMA. It’s a tool that Joseph Hill, one of the co-founders of Xamarin, he created [that], he describes it as his baby. We’ve taken that, we forked it, we’ve updated the definitions to use XPF definition. So you bring in your WPF app and it can tell you, “these are the problems that you’re going to have.” And then from that, if it’s like 100%, like, this is great, you’ve got no worries. You’re not using any Win 32 APIs, you’re not using any Win forms APIs that we haven’t already provided in our shims. Then click here to buy a license and you’re off to the races. We need to do some work on our end. It’s a case of get in touch and we’ll work with you to make sure that your app works.

Nice. Yeah. I do remember seeing something on Twitter a few weeks back where one of the Avalonia engineers - I think it was their story, but I may be misremembering. Where one of the Avalonia engineers was like somebody I believe somebody was interacting with Olia Gavrysh from Microsoft. And Olia had said, “get in touch and we can help you migrate stuff.”

Yeah, we’d already done it.

Yeah. And it was like six days later. “Oh yeah, by the way, we’ve already done this.” And then I was like, this is amazing. In six days. And someone else pointed out, “no, it took an hour.”

Yeah. Off the original Paul Thurrott, “let’s run his app in 30 seconds. On Linux,” it was like the speed run super quick. A guy in the community, Laurent, he posted a screenshot of the app that got him interested in WPF. It’s like a really early sample from 2006 called Family Show. And he said, “it would be cool if you could get this to run on XPF.” And it’s like, “challenge accepted.” Nikita, he grabbed the code and it was a really early build of .NET runtime. And we can do it on mono, but we prefer it to be on .NET six or .NET seven. That’s, like, the easy path for us. So he spent, like, 44 and a half minutes migrating it to .NET seven, and then he spent 30 seconds getting it to run on XPF.

Wow.

Yeah. And then we posted a video of it and people were loving it. Quite rightly. Because those kind of demos look great. It’s something hopefully, when this goes out, we’ll have much more in terms of marketing to show people it working and what the experience is like. But also I’m quite enjoying when I chat to people and demo it to them. And I’m in Visual Studio and I update the SDK and hit F5, and you can kind of see the jaws just drop down and it’s like, “wow!”

Yeah. Because it’s got me thinking about, like okay, so I’m going to ask you a personal opinion question.

Okay.

I’m not going to hold you to what you say here, and I don’t think anyone listening should. So, in your opinion, what is the future of .NET cross platform application development? Is it Avalonia?

See, that caveat at the end makes it… I’m going to be honest, I don’t know. I’d love for it to be Avalonia, but I think that…

Okay there are three players in this. In terms of cross platform, if you just want to go for Windows, then you’ve obviously got Winforms, WPF, UWP, WinUI. Take your choice. If you want cross platform, you can go with actually, there’s kind of four. You’ve got Maui, you’ve got Uno, you’ve got what was we used to call traditional Xamarin, which is just the bindings to iOS and Android. I don’t think I could in good faith recommend those approaches, especially for iOS, given Apple moving most of their SDKs to Swift. And whilst they do have a Swift binding story, there are many, many APIs that aren’t available there now. So I would kind of discount the traditional Xamarin approach. So, yeah, you have Uno, Maui and Avalonia.

People often ask me if I think that Uno is a competitor. I don’t, simply because I’ve seen the usage numbers for UWP and WinUI. It’s tiny, so I don’t lose any sleep over what they’re doing. And I think that reimplementing - I’ve been very vocal about this - I think reimplementing a Windows API to Mac, Linux and Web and all of the platforms and being bound by what occurs in Redmond doesn’t particularly make sense as a strategy. I wish them good luck, but for me, it’s not something that I worry about.

I think Maui obviously being the continuation of Xamarin forms super strong on mobile. So I think right now if you’re building a mobile app, you should probably just cut straight to Maui. That being able to use native controls in a mobile app is really important because a lot of the best mobile apps that you’ll use are using native UI controls. On desktop the story is quite different. It’s really rare to use a native desktop app. I mean, we’re chatting here in Discord. This is absolutely a web app masquerading as a desktop app. Teams the same thing. Visual Studio Code, Figma, Skype, Slack. I struggle to think of apps that I use on a regular basis that are actually not just a website. So we’re competing against those technologies on the desktop. And when you deliver a native app, it’s so much more performant, it’s using so much less memory, it’s quicker to start. There’s a whole host of benefits. So I think that Avalonia is really, really strong in the desktop space and we do really well in embedded. Webassembly is definitely going to be interesting. But Maui doesn’t support Webassembly. They can’t support embedded because they don’t support Linux.

So I think, as I said right at the beginning, it’s horses for courses. There’s no right or wrong answer for me. I’ve worked at Xamarin, I love that technology. I think that Maui has a lot of potential. I think that on the desktop side, to be frank, I think they’ve made some decisions that are going to haunt them for a very long time. I think that picking WinUI was a terrible decision. And an even worse decision was to pick Mac Catalyst. Even Apple can’t make decent catalyst apps. I don’t know how you could possibly create one using an abstraction even higher. So yeah, I think that we’re in a really unique position because of how we work, because we use Skia to render everything, we have full control of how your app looks. So it’s much more like Flutter.

When we think about competition on mobile, we’re looking at Flutter. That’s our competition. We’re not worried about what Maui is doing because we think, and I’ve certainly seen this a lot of companies now, they’re going, “well, Maui isn’t ready and it’s quite a sad state of affairs. If we need a mobile app, let’s just build it with Flutter.” And so the question that we’re thinking about as a team is, “how do we make it so that they don’t go to Flutter and that they come to us instead?” So I’ve got a guy that’s working on Android basically full time to improve our Android story, and we’ve just hired a guy that’s going to be working on the iOS side of things. So mobile is one of our key investments. And the on the embedded side, we looked cute or QT because they’re the market leaders. So I think that Avalonia is in a really strong position to kind of take over all of .NET. I think because of our heritage as well, being community focused. It’s a community project. It wasn’t started by some giant corporation or profit seeking entity. We were built by the people, for the people.

Okay, that’s cool. Yeah. I do feel like it was a very leading question and a bit tongue in cheek of me to ask. I’m kind of being silly. We’ve talked really sort of serious stuff so far, wanted to throw out a curveball and be a little bit silly. But I like the way that you’d put that, because my experience with Maui is that it doesn’t do what I want it to do. And that doesn’t mean that it doesn’t work, that doesn’t mean that it’s not good. It just doesn’t seem to be able to do what I want to do. And I’m sitting here talking to you with my M2 Mac air, but my daily driver is Ubuntu, right? And I’ve been able to run .NET Maui Android app, wrote a blog post, sent it over to Microsoft and was like, “hey, I’ve gotten it to run, but I can’t do Debugging, I can’t do hot Reload, but it’ll start also because I’m on Linux, it’s in Rider. So deal with that as you must,” because I just couldn’t get it to work in VS Code. But this was like September last year, so September 2022. So obviously things have come along since then and we’re recording this in the past, so things will have changed between now and when people are listening too. So what I’m trying to do is sit on the fence, right? It’s a moving target, right?

Yeah. And I think your position as a podcasting host, you would need to sit on the fence. I don’t think I need to sit on the fence on this.

With Maui, we are very keen to have a partnership with them because as I said on the mobile space, if you want to compete within the consumer, and I used to say this at Xamarin as well, if you want to build a consumer application for mobile, you really do need to be using native controls. And I think, to be honest, you probably need to be building it for iOS and Swift and then on Android using Java. Or I’ll admit, Android for me is something I basically ignore 99% of my time. But I think that, yeah, to deliver that kind of five star experience right now, you probably just want to be using Swift. And when Xamarin was created, the only option you had was objective-C and that was a horrific language to develop in. So like C# was a breath of fresh air, it was lovely. But Swift is also really nice to use. So I think if you want native controls then just build it with Swift. I wouldn’t bother with anything else. If you don’t need native controls, well, then there’s a whole host of options available to you. You might want to look at Flutter right now because it’s pulling away from where we are in the .NET world and that’s why we look to Flutter as a competition and we want to be much closer to their functionality.

But coming back to my point, we wanted to partner with the Maui team and we created a hybrid approach that enables you to embed Avalonia into a Maui app so you can kind of mix and match. You can have some native controls with Avalonia controls in there as well. And we’ve also considered creating a back end for Maui based on Avalonia. So just like their back ends run on Mac Catalyst and WinUI and Coca Touch and Android Widgets, we could do it that sits on top of Avalonia, and that would enable your Maui app to run on Linux, and it would enable your Maui app to run on Webassembly as well.

To be frank, we don’t know if we want to pursue that because we’re a small team, we have finite resources and do we want to kind of be working and maintaining that code for a project that’s maintained by a multibillion corporation? I mean, Microsoft’s got a market cap of $2 trillion. I kind of feel if they, if they really wanted Linux and webassembly support based on Avalonia, I’d be happy to talk to them about sponsorship of that work and we could come to some arrangement, but I’m not sure; we’ve got the proof of concept. It works, but I’m not sure I want to flesh that out and kind of go to production with it. Sure, we’ll see.

Okay, we’ve talked to Avalonia, we’ve talked a little bit about XPF and the magic that it is. And I mentioned at the start that I’m one of these developers where everything in the UI completely passed me by. So I was wondering just to get your initial thoughts on because I know we’re running low on time now. Your initial thoughts on, “how the heck do I as someone who completely missed out on WPF, WinUI, UWP, everything after Winforms, how the heck do I go about learning to use Avalonia or any of these new technologies?” Right? Because I’m sitting here going, “well, like I said, I tried out using Maui, but Xamarin passed me by too, right?” So the whole Xaml, everything just wash straight past. So I feel like I’m possibly a tough case for you and the team to write docs for because do you have to sit there and teach me XAML in order for me to use Avalonia? And the if you are teaching me XAML, then what about the people who have done XAML and WPF, and all of the other technologies, they’re then being left in the dust, they’re like, “well, I can’t sit here and read through this documentation of this is. How we do this?” You need to do your anchor tags and all this kind of stuff. So I can imagine that whilst me as an individual, I am a very tiny part of your potential user base, but they’ll be you’re the most user base. Okay, thank you very much.

You as an individual, all priority is on.

So our technical writer has very limited experience with Avalonia. And you would think like, that’s an odd choice. Why would you hire a technical writer that doesn’t know your framework? But it’s actually proven to be incredibly beneficial because he is asking all of the questions that you would probably ask. He comes from an MVC background, so he knows HTML, he knows some JavaScript, he knows CSS, but he’s more about ASP .NET development. So his way of modelling and thinking about application development mirrors much closer to yours than it does mine. And so he’s asked some absolutely fantastic questions. And the way that he’s writing the docs, it does go back to the basics of, “what is XAML?” And we need that because there are people that need to understand. You don’t have to use Xaml to write Avalonia. You can use just POCOs, so plain old clr objects. You write it in C# or VB .NET or S sharp. If that’s your thing, it doesn’t matter. I mean, you could even do it in Cobalt because there’s a .NET version of that. It doesn’t matter as long as it’s .NET language.

So, yeah, my advice would be read the docs if that’s how you like to learn. If you don’t like to learn reading docs, there’s a plethora of YouTube content available to you that will teach you Avalonia. If you get stuck and you’re wondering, well, or you finish watching every Avalonia video on YouTube, start learning about UWP or WPF or just the standard approach, you know MVVM and XAML. I think if you know HTML, you basically know XMAL. It’s a markup language. If you know how to write XML, you know XAML. It’s not a terribly difficult thing. It’s about building that mental model. And that’s what our new docs, which are, my goodness, I hope I can say, they’re already out in the future. Now, in the past. We have tentatively said that we will publish next week, but I need to double check with the team. But yeah, they are focused on taking you from an absolute beginner with no experience through to building an app on your preferred platform for your preferred platforms. On top of that, we’ve got the samples so you can clone those, whack the breakpoints in, explore how it works, fiddle with things, break it. And when you get stuck, come to our community, chat with them. You might ask a question that generates a new sample.

Yeah, fantastic.

Just play.

Okay. And then I guess if I could collect some links from you outside of our recording, I could put them into the show notes for things like links to the community and things like that. That would be pretty useful.

Yeah, I will share everything that we have.

Awesome, that’s very kind of you. Awesome. What about getting in touch with you then? Are you open to people reaching out on Twitter and saying, “hey Mike, here’s this thing,” then you maybe direct them to the right person?

Definitely. I don’t have the answers to everything, I’m not all knowing. It’s a shame, I wish I was. I leave that to my wife. My DMs are open on Twitter. If you’re more of a LinkedIn person, you can ping me on there. I’m on this new thing that everyone jumped to when Elon bought Twitter. Same handle, MikeCodesDOTNET. I don’t even know if there’s DMs on that, but if there are, you can DM me there as well or you can email me at mike[at]avaloniaui[dot]net, I can’t promise I’ll get back to you quickly, but I will endeavour to get a response to you at some point.

Amazing. Yeah. I feel like I need to try out - not Telegraph, it wasn’t that - It was Mastodon. I feel like I need to try out Mastodon now because everybody jumped to it and I was like, I’m fine with all the cool people going, you all figure it out and then you can be like the early adopters and figure out all the pain points and now I can come in afterwards, right?

Yeah. I am super late to the party on it and I only kind of started an account because people were pestering me to be like, “well, he’s only tweeting on Twitter,” and it’s like. Okay. And I just copy and paste them so it’s basically the same thing, so you don’t need to follow me in both places.

Fantastic. Well, Mike, thank you ever so much for being with us today, I really appreciate it. I’m walking away with a better appreciation of not just Avalonia, but of desktop UI development and I feel like there’s a conversation to be had, perhaps if you’re interested, or if anyone on the team is interested about just the magic of getting a desktop UI running on a Linux. Right? Because just real quick, for people who don’t know, there isn’t one Linux and there isn’t one desktop experience on Linux and there isn’t one - I’m using the wrong words - but like graphics pipeline for Linux, right? So getting an app to run on any of the Linuxes to me is wizardry is what it is. It’s a little bit more than magic, it’s wizardry.

It is wizardry. And I can actually answer this really quickly, the key to that is to pick your dependencies well, so we only depend on X11, so we can run on just the Linux kernel. You don’t need a desktop environment we can output by the frame buffer at the lowest level, which is why we’re perfect for embedded. So yeah, just if you start to depend on GDK, then you’re in for a world of pain. Don’t do it. Just use X11. We have Wayland support coming as well. But yeah, pick your dependencies well and then it becomes pretty easy.

Wow. Okay. Wow. That’s a nugget right there. That’s some proper software engineering knowledge drop right there. Pick your dependencies very carefully because I feel like everybody just goes NuGet install, npm install, ruby install, or whatever it is, right?

Definitely.

Cool. Well, thank you very much, Mike. Like I said, I’ve come away from this with lots core knowledge and I am raring to go to learn way more Avalonia and way more desktop stuff because like I said, it passed me by completely. So I really appreciate it.

It’s a pleasure and I look forward to it. And we look forward to seeing you in the community.

Oh, absolutely. I’ll be in there later on this afternoon. Excellent. Thank you ever much.