8 ms·

Microsoft has a history of creating new UI frameworks. IMHO it's the result of Ballmer's "Developers, developers, developers!" attitude, which I think is a good

• cjbgkagh 9mo ago
  The decisions reg UI frameworks are largely due to internal political conflicts, mostly between DevDiv and Windows.
  • markus_zhang 9mo ago
    Just curious what is DevDiv? Tools division?
    • xmcp123 9mo ago
      As I understand it, .NET, developer tools, and VS. Basically you have tight OS integration vs developer friendly cross platform.
      • seanmcdirmid 9mo ago
        I think it also includes GitHub now.
        • Conan_Kudo 9mo ago
          I believe GitHub is under a different group (CoreAI), not DevDiv.
      • markus_zhang 9mo ago
        Thank you!
  • easton 9mo ago
    From the outside looking in one wonders why this is allowed to continue. Microsoft’s old school “developer tools for money” business is slowly dying (because Visual Studio proper is less popular than its ever been since so much is targeting web), you would think they’d reorganize and move .net and GitHub and stuff into their cloud team and yeet whatever toxic leadership is preventing Windows from using Microsoft’s own frameworks. IIRC .NET was banned from core Windows components after longhorn died, but its been 20 years. .NET is fast now, and C++ is faster still. Externally developed web frameworks shouldn’t be required for Windows.
    • cjbgkagh 9mo ago
      It’s a largely dysfunctional org creating largely dysfunctional software, I.e. Conway law. Dysfunctional orgs tend not to be capable of fixing themselves, especially without external threat. Satya Nadella, like many CEOs, seems mostly interested in impressing his peers and these days that means fancy AI, before that it was Quantum chips. Microsoft has produced some great technology and when I was last there I was definitely focusing on getting as much of the good stuff out into open source as possible. Back in the early V8 days the execs imagined JavaScript would keep getting exponentially faster, I tired to explain with a similar investment anything V8 could do dotnet could do better as we had more information available for optimization.
      • kombine 9mo ago
        Yeah, .NET is actually an impressive piece of tech. They have F# too which is a really solid programming language. And then they chose React of all things to build core OS UI.
        • pjmlp 9mo ago
          Because .NET is under DevDiv, F# came from Microsoft Research, and the OS is under Windows team. Windows team even refuses to have managed bindings for DirectX, like Apple and Google do on their platforms. Managed DirectX and XNA were pushed by highly motivated individuals, and lasted only as long as they stayed at Microsoft.
  • zamalek 9mo ago
    Yeah, as far as I understand it, that politics is: Sinofsky entrenched NIH on every team that he touched.
  • asveikau 9mo ago
    They have a lot of staff turnover too, and each generation of new SDE has less of a clue how the old stuff worked. So when they're tasked with replacing the old stuff, they don't understand what it does, and the rewrite ends up doing less. That was my impression of one of the major problems when I worked there 2008-2011. But I don't think it's just one problem.
    • nextos 9mo ago
      I think that because their total compensation is lower than FAANG, especially at senior levels, and they are seen as uncool, they sometimes have issues retaining top-notch talent. It's paradoxical, because MS Research is probably the best PLT organization in the world. But they have failed to move a lot of that know-how into production. Besides, because it's an older company, it might have more organizational entropy, i.e. dysfunctional middle-management. As you say it's probably several other causes too. But still, hard to understand how they can create F#, F*, and Dafny, just to name a few, and fail with their mainstream products.
      • zipy124 9mo ago
        You also probably couldn't pay me enough to work in the kind of environment that produces such buggy software as Microsoft teams. A message based app which can't even guarantee delivery of messages, or synchronization across devices isn't a good sign for management and delivery.
        • asveikau 9mo ago
          I was a unix head at the time and ran OpenBSD on my personal Thinkpad. I figured a stint on the Windows team would broaden my horizons and expose me to differences. It did that. I don't regret it. I did in the end feel that the company was not my vibe, but I respect and appreciate some of what came out of there.
      • asveikau 9mo ago
        Back when I was there, part of my calculus was that cost of living in Seattle was cheaper than the bay. It was about 35% cheaper back then, according to regional CPI data I looked at at the time. Not sure what the difference is today. I believe housing is still substantially cheaper. I think a few years after I left when more Big Tech opened offices in Seattle, competing companies started paying Bay Area salaries for Seattle living, removing this argument. I haven't watched this closely in recent years. But fwiw, I was able to save and invest a lot in my Seattle days, despite a salary that was lower than in the bay.
• bigstrat2003 9mo ago
  > React has had tremendous success in the web world, so why not try and get those developers more comfortable producing apps for your platform? Because web stuff utterly sucks for making UIs on the desktop. Microsoft either doesn't know this (bad sign), or is choosing to use the trendy thing even though it'll make their software worse for customers (a worse sign). Either way it's a very bad look from MS.
  • gfody 9mo ago
    probably trying to repro the crazy success of vscode, surely electron is the magic sauce and not the dream team of devs. azure data studio should've proved that you can't just sprinkle electron dust and get a winner. sadly I loved azure data studio despite its being afflicted with electron, but it became so bug infested they had to completely abandon it.
    • AdrianB1 9mo ago
      vscode is successful despite electron, not thanks to electron. The electron part is the worst of it.
  • user34283 9mo ago
    No, it does not suck. I attempted to use WinUI 3, and could not even get PNGs to render the colors correctly, no matter what setting I tried. Then I gave Tauri a try, and everything worked out of the box, with the PNGs rendering even better than in the Windows Photos app. Building the UI was much easier, it looked better, and you get to build the "backend" in Rust. Nothing about this sucked.
    • lenkite 9mo ago
      WinUI 3 is basically utterly pathetic bul_sh_t attempting to pretend that it is a UI framework. A wet paper plane passing itself off as a passenger aircraft. Please compare with a real desktop UI framework like GTK or Qt. Or just a more modern one like Rust Iced or gpui/slint
• drnick1 9mo ago
  Operating systems should always use C/C++ UI frameworks, and as little costly abstraction as possible, period. Anything else is wasting resources.
  • layer8 9mo ago
    It’s not so much about wasting resources as it is about the added latency, jankiness, and inconsistency in look & feel hurting usability.
    • oldestofsports 9mo ago
      Latency is literally wasting resources
      • layer8 9mo ago
        The point was that users mostly don’t care about wasting resources, but about usability. If usability wasn’t impacted, few people would care about resources being wasted. But since usability is very much impacted, people (rightfully) complain.
        • seba_dos1 9mo ago
          Wasting resources affects usability, and not just through latency.
          • layer8 9mo ago
            It doesn’t necessarily. A lot of resources are being wasted without impacting usability. Users only start noticing and complaining about it when it does.
            • seba_dos1 9mo ago
              It does, period. Less things can run in parallel, fans get louder, batteries live shorter and devices feel old years before they should, all of which directly affects usability. The user not noticing the direct cause or having enough resources to waste to at least perform some tasks acceptably doesn't change anything.
• al_borland 9mo ago
  I think the reason they keep trying new UI frameworks is that no one really adopts them. Developers know that Microsoft won’t kill off backward compatibility and break all the enterprise apps, so why rewrite? When one framework fails, they start working on the next one. I question if they understand the corner they’ve painted themselves into.
  • blibble 9mo ago
    I stopped writing Windows applications back in the early 00s my Windows API knowledge (essentially: just Win32) is still exactly as useful as it was then, having missed the 7 or 8 different UI frameworks in the interim
    • stevekemp 9mo ago
      Me too, back then I wrote applications either using the raw Win32 API (GetMessage, TranslateMessage, DispatchMessage, etc), or using MFC. I think MFC is now long-time dead and buried, but at the time I liked it despite the ugly macros.
      • cyberax 9mo ago
        MFC is actually still supported by MS, works in the most recent MSVS, and even occasionally receives updates.
    • pjmlp 9mo ago
      Win32 is basically frozen on Windows XP. Since Vista most newer APIs are done in COM, or WinRT nowadays.
      • trinix912 9mo ago
        I remember a thin book describing changes to the API in Vista and 7 compared to XP and it was really thin. Just a few extra APIs to be able to show controls in the taskbar preview and things like that. Win32 is a stable API and I hope they don't let anyone from the Windows 11 modernization team touch it.
• RajT88 9mo ago
  The software biz in general has a major "out with the old, in with the new" attitude, which paired with the attitude of, "We're going to build what we know, instead of learning the old stuff which is new to us". I've seen time and again, things like apps rewritten from scratch because nobody knew C++, and they only had C# devs. Or a massive runaround because the last guy on the team who knew C++ wrote a bunch of stuff and left a couple years back, and now nobody really knew how any of that stuff worked. > React has had tremendous success in the web world, so why not try and get those developers more comfortable producing apps for your platform? IMO - this is worth talking about. Zune, Windows Phone, and some others died when they did not, in fact, suck, and were pretty good products which while late to the game, could have competed if there had just been a decent app ecosystem.
  • Greed 9mo ago
    I maintain to this day that the Zune was one of the best designed hardware and software platforms I've ever used. Probably the only truly design forward product that MS ever produced.
    • midnightclubbed 9mo ago
      The Zune hardware was slick, particularly the solid state players. The music store worked great and their music licensing was so much better than Apple - $10 a month for unlimited streaming, unlimited downloads (rentals) to Zune devices and 10 free mo3 downloads to own. Their only misstep was making one of their colorways poop brown! That and being too late to market with a phone that used the same design language
      • SllX 9mo ago
        There was also the fact that Microsoft introduced it 3 months before Apple announced the product that would kill the iPod, leading with the HDD model (a direct competitor to what would become known as the iPod Classic line) when Apple’s real flagship was the iPod nano. There was also the crap that was Windows Media Player 11 which I tried to like for about a month. There was also the incompatibility with Microsoft’s own DRM ecosystem in PlaysForSure which was full of these subscription music services, some of which were quite popular with the kind of people that were inclined to buy a Zune: folks in Microsoft’s ecosystem that had passed up on using an iPod and used something from SanDisk, Creative, Toshiba or iRiver instead. This is because they wanted to replicate the entire iPod+iTunes model entirely. The 2006 lineup of iPods was also particularly strong, and included the first aluminum iPod nano’s. When Microsoft announced and released the Zune, they were counter-programming against that, right into the Holiday season with a new brand that had no name ID, with a product that was just like the iPod, couldn’t play any of your music from iTunes or Rhapsody, but with… HD radio. More than a few missteps were made.
• PunchyHamster 9mo ago
  I think it's more of result of "okay we made it and it works, how we now can excuse still being employed in same head-count" development. And the answer is of course "rewrite, rewrite, rewrite". UI works well, no major bugs ? TIME TO CHANGE IT TO BE "MODERN"
• bonesss 9mo ago
  > the result of Ballmer's "Developers, developers, developers!" attitude I think Microsoft’s framework chasing has been a betrayal of that philosophy. Internal divisional politics have been major drivers behind fracturing and refusing to unify the stack and its UI approach, and without clear guidance from the Office team the direction of the entire platforms UI is opaque. Short term resume and divisional wins at the expense of the whole ecosystem. A developer centric platform would let developers easily create platform specific UIs that look modern and normal. As-is the answer to how to ‘hello world’ a windows desktop app is a five hour “well, akshully…” debate that can reasonably resolve to using Meta’s stack. “VB6 for the buttons, C++ for the hard stuff” is a short conversation, at least.
• tonyedgecombe 9mo ago
  >Tangentially, see also the mixed reaction to Mac native apps switching from AppKit to SwiftUI I'll take AppKit -> SwiftUI over Win32-> windowsx.h -> VB6 -> MFC -> ATL -> WTL -> WFC -> WinForms -> WPF -> WinRT -> UWP -> WinUI3 -> MAUI. Even with all that Microsoft still went outside and used React Native for the start menu and Electron for the Visual Studio installer and Visual Studio Code.
• partomniscient 9mo ago
  Remember when Silverlight was _the_ future? How long did it last. Ironically it still gives me the shits because you can't select text on Netflix's front end.
• dep_b 9mo ago
  Problem with SwiftUI is that it only works well on macOS 26, maybe one version prior. AppKit works well on all macOS versions. Building a macOS 26 only app in SwiftUI today is a great UX, just as fast as AppKit. But it takes quite some effort to turn an iOS SwiftUI app into a real macOS experience. Though most macOS optimizations help for iPadOS as well.
• wolvoleo 9mo ago
  When I was a developer I was not amused at all with constantly changing APIs to be honest. And UWP was really sucky. Way too aligned with mobile and tablet which nobody actually uses on windows. Even as a user I'm glad it didn't take off.
• nightski 9mo ago
  Blaming this on Ballmer is a serious stretch, I can't see how you would come to that conclusion. Developers Developers Developers was for the launch of .NET and it brought us a platform that is still considered cutting edge 25 years later. UX was fine in the Windows Forms days, and WPF was a large step forward (responsive layouts, etc...). The problem was after that it all fell apart with Windows 8 and the attempt to switch to Metro, followed by the Windows Store fiasco and attempting to move to a sandboxed application model. It all comes down to Microsoft's failure to adapt to mobile/tablets in so many ways. Which is kind of hilarious, because they had some really cool tech for the time (the PocketPCs were pretty fun back in the day, before touch came along).
• GuB-42 9mo ago
  Changing UI framework all the times is fine, so is not changing anything for decades. Different strategies that both have value. Reasonably you want to be somewhere in the middle, depending on the use case. In an industrial setting, production infrastructure, etc... you generally want to change as little as possible "if it isn't broken, don't fix it". On emerging, consumer-facing technology such as mobile in the 2000s, "move fast and break things" makes sense. But anyways, it is not the problem. The problem is just that Microsoft today is doing a terrible job. The best example, I think, is the control panel. Starting from Windows 8, they changed it. Ok fine, you may like it or hate it, but to be honest, it is not a big deal. The problem is that they never finished their job, more than a decade later! Not all options are available in the new UI, so sometimes the old control panel pops up in a completely different style with many overlaps in features. And every now and then, they shuffle things around in hope that one day, the old control panel won't be needed anymore. If you make a change, commit to it! If you decide to replace the old control panel, I don't want to see it anymore. It is certainly easier said than done, but if you are a many-billion dollar company and that's your flagship product, you can afford to do hard things! Using a web engine to build UIs is fine too. As an OS-wide component, a web engine is not that big in terms of resource use, if properly optimized. The problem with Electron is that every app ships with its own engine, so if you have 10 apps, you have 10 engines loaded. But everything uses the same engine, and apps don't abuse it, then the overhead is, I think, almost negligible. It is rare not to have a browser loaded nowadays, so system components can take advantage of this. But again, you need to do it right and it takes skills, effort and resources.