Item — HN Reader

I agree and that was a huge failure.

One of the big reasons VB died, people will tell you, was the language. And that's true. But what they don't mention is that the other reason was the components. I'm not sure this is replicating a success story but rather failing to learn from what was not a success story.

2 comments

I ran a very successful company (successful for a time) that sold Visual Basic developer tools via a printed mail-order catalog named VBxtras.

Two things killed Visual Basic:

1. The web. Visual Basic was first and foremost a Windows desktop app development tool, and their UI-first model of app development did not translate well to the web, or at least the attempts to translate to the web did not resonate.

2. Microsoft. Rather than continue the simplicity Visual Basic offered, Microsoft "improved" it by releasing VB.NET which abandoned the core simplicity that made Visual Basic so wildly popular among "Occupational Programmers," as Kathleen Dollard[1] and I lamented back in the day. The upshot was that former Visual Basic programmers fell into two (2) camps; they either:

A.) Abandoned VB for something else, or nothing at all, because they did not want to have to become a professional programmer, OR

B.) Switched to C# because if they were going to learn how to be a "real" programmer they might as learn C# and not C#'s disfavored sibling VB.NET.

I blogged about occupational programmers several times back then: https://mikeschinkel.com/tags/occupationalprogrammers/

BTW, the company that has developed XMLUI was one of our better vendors of VBX components for Visual Basic. They have since renamed to /n software, but at first they were named IP*Works (I think I stylized that name correctly per how they did at the time.)

[1] Ironically Kathleen is now leads the .NET Core CLI at Microsoft, and is also lead over VB, I think: https://devblogs.microsoft.com/dotnet/author/kathleen-a-doll...)

I am not sure whether calling WPF a huge failure is justified. It works extremely well when everything is adaptable to its MVC-adjcent MVVM design pattern. In this case it's almost child's play to build rich and conplex GUIs that keep in sync with internal state.

Microsoft dropped the ball when they rewrote WPF in incompatible forms for the web (Silverlight) and Windows Phone (WinUI) shortly after releasing WPF itself. That ruined developer trust for their GUI library longevity.

The irony is that WPF itself never went away, and receives support and even occasional minor new features even to this day on .NET Core.

Much like WinForms, there are still many internal line-of-business apps written in it decades ago that are just happily chugging along, ignoring all the post-Silverlight churn in Microsoft dev story.

I really liked WPF for Windows Phone back then. The tooling was great.

I bought a massive 1000+ page book, "Pro WPF in C# 2010," one day. I also had to buy "Home Maintenance For Dummies" the same day. The bookstore cashier laughed at me.