Usually, when developers or programmers write articles about their experiences developing for a platform they have little to no experience with, the end result usually comes down to “they do things differently, therefor it is bad actually”, which is deeply unhelpful. This article, though, is from a longtime Windows user and developer, but one who hasn’t had to work on native Windows development for a long time now. When he decided to write his own native Windows application to scratch a personal itch, it wasn’t a great experience.
While I followed the Windows development ecosystem from the sidelines, my professional work never involved writing native Windows apps. (Chromium is technically a native app, but is more like its own operating system.) And for my hobby projects, the web was always a better choice. But, spurred on by fond childhood memories, I thought writing a fun little Windows utility program might be a good retirement project.
Well. I am here to report that the scene is a complete mess. I totally understand why nobody writes native Windows applications these days, and instead people turn to Electron.
↫ Domenic Denicola
Denicola decided to try and use the latest technologies and best practices from Microsoft regarding Windows development, and basically came away aghast at just how shot of an experience it really is. I’m not a developer, but you don’t need to be to grasp the severity of the situation after following his development timeline and reading about his struggles.
If this is truly representative of the Windows application development experience, it’s really no surprise just how few new, quality Windows applications there are, and why even Microsoft’s own Windows developers resort to things like React for the Start menu to enabler faster and easier iteration.
This is a complete dumpster fire.
I would argue this is NOT native development.
I love C#, but .Net is not native. It might be a bit more native than Electron of course. At least it compiles to ahead of time x86-64 code. But true native would be Win32/WinRT with C++.
For those issues with direct access to hardware or input settings… yes, that was one area C# was lacking in the API department. But as the article suggested, they had the awesome PInvoke mechanism since day one. (Something Java is still seriously lacking for decades)
Always has been.