Where Windows App Development Goes to Die (Premium)

Back in 2019, I started the epic Programming Windows series which, years later, turned into the equally epic book Windows Everywhere. But about halfway through writing up the history chronologically, I ran into a wall: because I had never really participated in .NET development, I had a less than authoritative handle on that era of software development. And so I took a break from the series so that I could go back in time, virtually, and learn each of the Windows-focused .NET application development frameworks in turn. In doing so, I created a Notepad clone that I later renamed to .NETpad. And then I recreated this app repeatedly, using different frameworks, languages, and .NET versions. I documented the creation of three of these projects---Visual Basic/Windows Forms, C#/Windows Presentation Foundation, and C#/Universal Windows Platform---over a several-month period, and then later updated them for the modern .NET era so I could post them to GitHub, allowing others to clone the repositories, make their own improvements, and suggest changes to the apps. Some of which I later incorporated into them.

That's all very interesting (to me), and I did of course later go back and finish the Programming Windows series. But I still have this one idea stuck in my craw from the time I was finishing up the first half of the series, and it's related to Visual Basic (VB), an absolutely wonderful tool that many fans still believe Microsoft completely screwed up in the transition to .NET. And that idea is that it was absolutely astonishing how much of an application one could create using this tool without writing a single line of code. This was the true strength and magic of VB, that one could construct the user interface of an app entirely using visual tools and by assigning values to properties. And then you could tie it all together with what I still think of as "glue" code.

This is why my first .NETpad project utilized VB.NET and Windows Forms: this combination was the logical successor to VB 6, the last "classic" version of VB, and it seemed like the obvious way to get into .NET. And it was. And as I had hoped and mostly expected, it was likewise possible with Windows Forms to spend much of your time making UI visually and by assigning properties. It was very much like VB in that it was impressive how much you could get done before you needed to write any code.

But as I moved forward in time through newer .NET environments like Windows Presentation Foundation (WPF) and Universal Windows Platform (UWP), I experienced 10 to 15 years later what Microsoft stack developers already knew: everything changed. Microsoft adopted a declarative UI paradigm in which application user interfaces were created with XAML, an XML-based markup language, a more sophisticated approach that would let developers and designers work together on the same project, with each sticking to their subject area. There were visual designers for XAML, at least in the beginning,...