Hacker News new | ask | show | jobs
by pux0r3 3583 days ago
I'm going to throw my vote in for the C#/UWP pairing. I am part of the prototype team where I work, and when I need to target Windows it's my weapon of choice. Sometimes I can't get access to something I need due to the sandboxing, so I'll drop back to WPF. I am familiar with forms, but I find that UWP/WPF's XAML is much easier once you get used to it. I would recommend against MVVM stuff if you're just prototyping or making small one-off apps, that is a time trap in those cases.

That being said, if you don't want to hit the more "Universal" part of the UWP and you just want to tie into shell commands/utilities, it's hard to beat Python with TKinter.

I'll also use Unity a lot (I was previously in games, and we do a lot of entertainment work). It's probably not what you like, but you'll be able to hit every non-embedded platform under the sun (including Windows and UWP, but also including Chrome, various TV's, &c). The UI system has improved a lot, and their (older) IMGUI implementation makes it super easy to wrap a UI around logic.

Finally, I'll add that (especially if I know that I'm building for a specific platform), it's hard to beat the native rendering APIs these days. They're all super easy (all being UWP/WPF, Android, iOS's UIKit, and macOS's AppKit), and will generally get out of your way. I've gone down the Xamarin route in the past, and it turned out to be overly difficult to build some simple apps (plus, I've had trouble deploying to Android in some instances).

1 comments

UWP or WPF is absolute overkill for a simple front-end to a command line app.

WinForms is the only right choice here.

UWP is definitely overkill if you go through the trouble of writing all the MVVM bindings as I mentioned. But, for really quick things, I can type XAML faster than I can try to align gui elements with a mouse. Then you get the same code-behind file to do your heavy lifting. The WYSIWYG editor is far worse though, I pretty much would only use it for a preview and only touch the layout via the XAML.
Disagree. As someone who has worked extensively with both WPF and WinForms, they're just different programming paradigms (XAML vs Forms Designer), but once you get up to speed on WPF, you can develop interfaces, even "quick and dirty" ones, just as fast if not faster than WinForms. What exactly about WPF is overkill?
Also, isn't winforms & co. more or less deprecated by Microsoft?
Yes, in that it has been replaced by WPF and now UWP. That said, it is complete, stable, and mature. You know what you're getting with it. Going by what Microsoft recommends (e.g. whatever the latest they've put out is) isn't always a good idea. For example, early on the WPF days, there were loads of bugs in the framework. Even today, with WPF not being actively developed, it's filled with quirks and bugs that you just come to know about by working with it a lot. I'm sure UWP is in a similar state right now to early WPF, which is why I'll avoid it until it becomes more proven.
WinForms is a pretty thin layer over win32, it isn't going to suddenly stop working.