My #MAUI Day talk - part 4

This is part 4 in a series recapping my talk from MAUI Day (in London). This will make much more sense if you read parts 1, 2, and 3 before continuing. I think it'll be worth it, this is where we get to the pinnacle and most remarked upon section of my talk.

If XAML has so many problems and it's taken this many years to identify and try and address them, maybe we should look for something new to replace it.

However, introducing a new language to replace XAML would have a number of challenges:

• It would need to be able to work with existing XAML (& C#?) to avoid the need to rewrite all that already exists.
• Many people would still assume the need to rewrite in the new option as the other option(s) would (eventually) go away.
• Assuming that the new language also came from Microsoft, the number of things they (Microsoft) need to support and maintain would be increased (they'd need to ensure all pre-existing things continue to work) and this extra requirement would slow down development/advancement in other areas.
• What about all (sigh) the tools that already exist? Would they need replacing or updating?
• It would require thorough documentation (which takes time and effort).
• All the SEO goodness of existing docs, blogs, etc. would make it hard to find appropriate, up-to-date information about whatever is new.
• Developing a new language is hard to get right.
• Developing all the required integrations with developer pipelines and other tooling (there's more to MAUI than just XAML) is complex and would be a lot of effort.

That's a lot of reasons not to do it, or to not expect something anytime soon.

It's especially tricky as my expectation (based on 25+ years in the Microsoft/.NET developer ecosystem) is that developers are highly unlikely to pay for a solution that doesn't come from Redmond. Nor would there be a lot of participation in creating an open-source solution.

But, I'm channelling my inner Thanos right now, and I think I have a possible solution.

Rather than replace what already exists (both code bases and toolchains), why not sit on top of that?

I've created a rough specification and prototype of a new language that produces XAML. The output XAML (& C#) can then be used just like the files you have and write today.

The intention is to define the UI in the new language which then produces XAML and everything continues to work as before.

Tooling and IDE integrations quickly make this feel natural.

This way, everything that currently works will continue to work. New things are extras and on top.

• By having a new language that can produce XAML (& C#) files that are used as the project system and developer tools currently expect, there isn't the time and effort needed to change what already exists. We can experiment and iterate faster on possible alternative solutions.
• By producing files that are valid even if the experimental language goes away or you decide not to use it, there is little risk. You still have working code, and you're not stuck with something that needs to be rewritten in a way you can support and maintain going forward.
• As it works on top of existing files, it can be used in whole or part within a project or a team. Just start using it for the files (pages/controls/dictionaries) that you want. It's entirely optional.
• By treating XAML as acceptable input, it's also really easy to try it out. Just copy the existing XAML into the new file and start modifying it there. You can progressively switch to the new, simplified syntax and make use of new functionality a bit at a time. If there's anything that can't be done with the new language (or you don't know how) simply fall back to doing it with XAML.
• By generating code at design time, it's possible to do things that hand-written XAML can't.

Added bonus: this could also work with WPF and WinUI. There is nothing here that is specific to MAUI.

So:

• Low effort

• Low risk
• Big improvement

I think this is worth exploring further.

Because it's helpful to have a name to refer to things, I call it ENAMEL. (Experimental Native Application Markup Extension Language)

Here's a very basic teaser of it in action:

The above animation shows 3 windows inside Visual Studio.

• On the left is an .enml file in an editor window.
• In the middle is the .xaml file produced from the ENAMEL.
• On the right is a design-time "pre-visualization" of what the page will [approximately] look like.

Yes, this is the default new page with some additional buttons at the bottom.

In the animation:

1. A property (highlighted in pink) is uncommented in the ENAMEL and the file saved.
2. This causes the XAML to be updated (yellow highlight) and that property added.
3. This change is also reflected in the "pre-visualization" of the XAML.

Aside 1: The highlighting of parts of the code was done with this extension.

Aside 2: The "pre-visualizer" is a tool I previously built for myself to give me an approximation of what the rendered app will look like. It doesn't remove the need for running and testing the app on real devices but it increases my confidence that the XAML I have will produce the output I expect. While tools like Hot Reload and Live Preview are useful, the "pre-viz" helps me avoid the frustration and disappointment of compiling and launching the app to discover I've left something out or made a silly mistake. This isn't specific to ENAMEL.

I'm not going to show here the details of the ENAMEL language that I showed on the day.

I'm not doing this to be a tease. I will share more details soon.

I'm trying to avoid making the discussion about my specific implementation when I want it to be about the concept.

The point I'm trying to make is that once I identified that there was a way to create a simple experiment with alternatives, it was easy to produce something that let me try it out.

I admit that I was well-placed to produce such a seemingly polished proof-of-concept. I've built DSLs (Domain Specific Languages) before and have experience integrating with Visual Studio.

To get as far as I did took a total of less than two days effort to implement. (Not including time spent in advance thinking about rules/syntax for the language.) Most of the Visual Studio integration was cut and pasted from previous projects, and I spent less than an hour doing the simplest possible thing I could to get basic colorization (classification) of the code.

In reality, all it's doing is taking a multi-line string as input, parsing it and returning another string containing XAML. It's basic stuff that anyone with at least some basic C# experience could do. If it was a separate app or had a command line interface to turn one file into another it wouldn't seem so remarkable.

Forget my implementation. Is this a good idea?

How would you feel about using a new, powerful, yet simple language to define your UI? And, that then gets turned into XAML and used when compiling your app?

I know there are much smarter people than me out there who may have much better ideas.

I'm not trying to say I have the solution.

I am trying to say that we need a solution; how about this as a starting point?

What do you think:

• How can we make existing and future XAML easier to work with?
• If it's another language, what should it be like?
• If not another language, then what?

I share my concluding thoughts in part 5. (The concluding part in this series.)