251–260 of 604 posts
The deeper problem is that Microsoft keeps trying to solve GUI consistency at the framework layer instead of the design system layer. WinForms, WPF, UWP, WinUI -- each one a new framework, each one eventually abandoned. Apple solved this by treating the design system as the product and letting the framework be invisible. Microsoft has it backwards every time.
I really don't think that's the fundamental issue.
TFA points out, and I agree, that the fundamental issue is political: competing teams across different divisions coming up with different solutions to solve the same problem that are then all released and pushed in a confusing mishmash of messages.
I haven't written a line of code for a Windows desktop app or extension since early 2014, when the picture was already extremely confusing. I have no idea where I'd begin now.
My choice seems to be either a third party option (like Electron, which is an abomination for a "native" Windows app), or something from Microsoft that feels like it's already deprecated (in rhetoric if not in actuality).
It's a million miles from the in the box development experience of even the late zero years where the correct and current approach was still readily apparent and everything you needed to move forward with development was available from the moment you opened Visual Studio.
There's just so much friction nowadays, starting with the mental load of figuring out the most acceptable/least annoying/most likely still to be supported in 5 - 10 years tech to use for solving the problem.
Java wanted to run your code everywhere so they basically wrote a byte code compiler and then wrote one vm per OS/architecture I never understood.NET's purpose. What problem it exactly went out to solve? Did Microsoft want developers to be able to run their applications everywhere too? Absolutely not. Sidenote - MFC is the ugliest thing you'll see. Yet they didn't mention another piece of work called ATL. Active Temp…
> WPF was good As someone who saw what impact WPF had on average users running average hardware in the late 2000s to early 2010s, I disagree. In 2011, my brother was in seminary, using an average Windows Vista-era laptop that he had been given in 2008. When he was home for Christmas in 2011, we were talking about his laptop, and he told me that the Logos Bible software ran sluggishly on that laptop. He said something…
That's fine, except no platform answers this.
Obviously Linux doesn't, but the Mac doesn't either. Apple of course has it's recommendation, but most developers do not take Apple's recommended path because of course, it's Apple-only, most developers make cross-platform apps these days.
Even if Microsoft decreed the one-and-one Windows development path, most developers are not taking that path.
It used to be the case that Mac developers used Apple tools, Windows developers used Microsoft tools, but those days are gone. Developers want to use Electron, or Qt, or some other system to support multiple platforms in one codebase.
Microsoft has less to do with this than the article makes out. I'm a desktop developer. I don't care what Microsoft recommends, or what Apple recommends, because neither work in the real world where supporting only their platform just isn't realistic.
Earlier quoted context omitted.
> Apple solved this This comment written before Tahoe
Snide and subjective comments aside, you’ve clearly missed their point. Even if you take away subjective opinions on Liquid Glass, the point is that the core system updates things across the board. Unless apps have implemented custom drawing, you get a consistent-ish UI (for better or worse) across the system, whereas with windows you are beholden to whatever hodge podge of UI frameworks were chosen at the given time…
Java wanted to run your code everywhere so they basically wrote a byte code compiler and then wrote one vm per OS/architecture I never understood.NET's purpose. What problem it exactly went out to solve? Did Microsoft want developers to be able to run their applications everywhere too? Absolutely not. Sidenote - MFC is the ugliest thing you'll see. Yet they didn't mention another piece of work called ATL. Active Temp…
Targeting the broadest possible variant of x86-64 limits you to SSE2, which is really not very capable outside of fairly basic float32 linear algebra. Great for video games, but not much else.
Also keep in mind that .NET originated right at the cusp of x86-64, which again is a whole different architecture from its 32-bit predecessor. Most native apps used to ship separate binaries for years.
And of course, I think Microsoft was aware of their intrinsic dependency on other companies, especially Intel. I can see how the promise of independence was and is enticing. They also weren't interested in another dependency on Sun/Oracle/whoever maintains Java at the moment. While Windows on ARM64 is still in a weird spot, things like .NET are useful in that transition.
Lastly, the CLR is different from the JVM in a number of interesting ways. The desktop experience with the JVM is not great, and Java is a very bad language. It makes sense to do your own thing if you're Microsoft or Apple.
Earlier quoted context omitted.
I agree. Except that WinForms has not been abandoned. In fact, it's one of the supported paths in the modern .NET stack.
WinForms is a layer built on top of raw Win32. So it's not portable. Even though Wine exists, Win32 calls can only be made from Win32 programs, not native Linux programs. So a WinForms app using the latest dotnet would need to run the Windows version of dotnet under Wine, and not use the Linux version of dotnet.