In looking at alternatives to Xojo, by virtue of my working pretty much as I please on internal admin tools for the system I’m building, I have a few thoughts for Xojo devs who might be pondering the many alternatives.
In general I’m not interested in building up a nontrivial UI without a WYSWIG editor of some kind. I’m also at a Microsoft / Windows shop.
Microsoft desktop development is something of a hot mess at the moment. Windows Forms is the spiritual heir to the enormously successful VB6 but MSFT is clearly ambivalent about it. For awhile it appeared to have been supplanted by Windows Presentation Framework (WPF), a rather clunky XAML-based system that now appears to be getting the same benign neglect that WinForms has “enjoyed” for several years (it’s been turned over to the Asian division for support where it’s said that “Microsoft technologies go to die”). As a probably temporary side effect of this, WInForms has gotten some love in recent months, but if I had to guess (and guess is all I can do) where Microsoft is going with desktop is some form of Electron-like browser-in-the desktop via Blazor. Blazor is primarily for WASM-based browser deployment, so yeah that’s probably not going to end well either.
For now, needing only tooling for a small handful of people to work with in-house (never more than a half dozen, in practice more like 2 or 3) and with the option for browser deployment “nice to have” but not crucial, I’ve settled on WinForms using C# as the language (you can of course use VB.NET).
I’ve found it at least as fast and enjoyable to create a GUI as Xojo promised to be on a good day, but there are some troubling flies in the ointment.
Probably 95% of the code I write is console apps and near cousins like Windows services. The tooling for that is super mature and reliable. The technical debt around WinForms is palpable by comparison:
-
The forms designer UI is not DPI-aware, whereas the rest of Visual Studio 2022 is. The practical result of this is that the forms designer sometimes gets itself into funketized states, particularly if, as I do, you are constantly switching between a laptop and a large monitor. I’m talking about closing all designers and stopping / restarting Visual Studio and sometimes even then the only reliable way to get steady work done is on my large monitor, if the “form” being worked on is fairly large and complex.
-
In general the fake-happy path for working with the designer is, work on a form, close the designer, compile and test, then reopen the designer. If you just leave it open it may be unresponsive or wonky after running the app. Mercifully if you forget, just close the designer tab, go to the corresponding code tab, and choose “View Designer” (although it can take a few seconds for the designer to come back up).
-
On rare occasions, Visual Studio gets out of sync with the code, giving spurious compiler errors pointing to lines that don’t have anything to do with the error, refusing to navigate to the line where the error is, etc. The only fix I’ve found for that is to stop and restart Visual Studio.
-
Round-trip designer (changes in designer properly reflected in code and vice-versa) mostly works correctly, but it’s not hard to accidentally create an empty event handler by fat-fingering something in the UI and it takes a little experience to know how to properly remove it as the round-tripping breaks down here a little (basically if you create an event in the UI, delete it in the UI)
-
If you report such bugs you’ll probably run into the M$FT culture of “not enough people care about this bug so it’s not a priority” (translation, we’re not going to fix it). They are catering to web devs and API devs and other cool kids.
All that said, while annoying, the workarounds aren’t bad and the apps themselves are easy to construct and work correctly at runtime.
Would I use WinForms for commercial software? No, I don’t think so, although there are some pretty mature 3rd party control libraries that probably help with some of the above issues, God help you if you want to do a MacOS version or a web version; your WinForms code is a mostly un-reusable island unto itself. I’m not sure what kind of support, if any, Ryder has for WinForms – probably zero, although they have said they intend to support and extend VB.NET as a language despite MSFT deprecating it, I don’t think they’re committed to WInForms itself.