4 ms·

They could easily have done this but instead chose to make several new frameworks that didn’t improve anything. Very sad. Now MS has several mediocre not well m

They could easily have done this but instead chose to make several new frameworks that didn’t improve anything. Very sad. Now MS has several mediocre not well maintained frameworks instead of a really good one. The constant churn also killed off a lot of open source efforts

DoofusOfDeath 7y ago
This isn't my area of expertise. What are some of the other MS frameworks or OSS projects you refer to?
- maxxxxx 7y ago
  WPF started XAML, then came Silverlight, WinRT and UWP. They are superficially similar but under the hood the code is quite different and each has its own set of weird limitations so you can't just reuse code. Also, in the case of WinRT and I think also UWP the new framework had less features than its predecessor so in a sense it was worse and less powerful which is not a good way to convince people to port their code. When WPF came out there were quite a few very cool open source projects that built on top of it because it's really easy to extend WPF and build components for it. But then every two or three years MS announced a new framework so most of these efforts died out. When you look at commercial third party suppliers like Developer Express they have the same component in three or four flavors. this must be a huge and expensive effort to maintain.
  - contextfree 7y ago
    "WinRT and UWP" in this context are just two names for the same thing, though
    - maxxxxx 7y ago
      Sort of. They were released some years from each other. WinRT was super weak and never took off and then suddenly UWP came up.
      - contextfree 7y ago
        APIs were the same, just with some upgraded and new stuff I think the various name changes have been extremely confusing and created the perception of more "resets" than actually happened at the code and API level. They dropped the ball by not bothering to have a good compatibility and migration story across WPF->Silverlight->WinUI, but since Windows 8 they've been pretty good about maintaining continuity for WinRT APIs
        maxxxxx 7y ago
        After trying WinRT and seeing that everything was async (WTF?) and a ton of APIs were missing I admit I stopped bothering to look any further. UWP (the UI part) is also not really a step up from WPF either.
        pjmlp 7y ago
        Because any UI code that requires performance should be async and lenghty work must be done outside the main thread. So Microsoft learned how lazy devs are and how ignoring such advises contributed to bad perception of GUI apps, e.g. Swing, and forced everyone to code the right way. It is relatively easy to turn async code into sync, if really required.
        m_fayer 7y ago
        If that was really MS's reasoning I find it risible. There are many perfectly good reasons to have synchronous IO APIs. Yes, in the wrong hands they can make for janky UIs, but then the problem is not the tool, the problem is the developer. MS's market was full of amateur-hour developers because their platform (WP7) was weak and lagging behind, thus incapable of attracting the top tier of devs. And then they poured gasoline on that fire with a barrage of silly incentives that were ignored by pros but attracted even more beginners. Now, to put a cherry on that fine mess, they attempted to remedy their bad business decisions with a technical solution that damaged the one asset they really had - an advanced and ahead-of-the curve app-development story. One own goal after another, really.
  - alkonaut 7y ago
    Those feel like they were created by orders from top management, because of some strategic decision (microsoft needed a flash alternative, or a Windows 10 store UI framework etc). They don't feel like the product that would come if DevDiv did their best to produce a sane UI framework. They feel rushed, semi-overlapping, half-finished. I imagine it should be possible to make just one more xaml framework which is cross platform, and much better than WPF (and it's derivatives), and much better than the js alternative (Because of deployment, not least). I'm not sure if there is any incentive for ms to put their weight behind it however.
    - m_fayer 7y ago
      Hopefully that last xaml framework is avalonia, it's definitely gaining steam.
      - alkonaut 7y ago
        Yes. But for one of these to really take off, I think what's needed is for one of the giants to throw their weights behind it. Basically "We're betting x billions on it, so you can be sure that lots of companies will be using this tech in the decade to come".
      - wiso 7y ago
        The XAML in Avalonia is great. There is even support for XAML to IL compilation during build so you don't have any parsing overhead when running your app.

DoofusOfDeath 7y ago

This isn't my area of expertise. What are some of the other MS frameworks or OSS projects you refer to?

maxxxxx 7y ago
WPF started XAML, then came Silverlight, WinRT and UWP. They are superficially similar but under the hood the code is quite different and each has its own set of weird limitations so you can't just reuse code. Also, in the case of WinRT and I think also UWP the new framework had less features than its predecessor so in a sense it was worse and less powerful which is not a good way to convince people to port their code. When WPF came out there were quite a few very cool open source projects that built on top of it because it's really easy to extend WPF and build components for it. But then every two or three years MS announced a new framework so most of these efforts died out. When you look at commercial third party suppliers like Developer Express they have the same component in three or four flavors. this must be a huge and expensive effort to maintain.
- contextfree 7y ago
  "WinRT and UWP" in this context are just two names for the same thing, though
  - maxxxxx 7y ago
    Sort of. They were released some years from each other. WinRT was super weak and never took off and then suddenly UWP came up.
    - contextfree 7y ago
      APIs were the same, just with some upgraded and new stuff I think the various name changes have been extremely confusing and created the perception of more "resets" than actually happened at the code and API level. They dropped the ball by not bothering to have a good compatibility and migration story across WPF->Silverlight->WinUI, but since Windows 8 they've been pretty good about maintaining continuity for WinRT APIs
      - maxxxxx 7y ago
        After trying WinRT and seeing that everything was async (WTF?) and a ton of APIs were missing I admit I stopped bothering to look any further. UWP (the UI part) is also not really a step up from WPF either.
        pjmlp 7y ago
        Because any UI code that requires performance should be async and lenghty work must be done outside the main thread. So Microsoft learned how lazy devs are and how ignoring such advises contributed to bad perception of GUI apps, e.g. Swing, and forced everyone to code the right way. It is relatively easy to turn async code into sync, if really required.
        m_fayer 7y ago
        If that was really MS's reasoning I find it risible. There are many perfectly good reasons to have synchronous IO APIs. Yes, in the wrong hands they can make for janky UIs, but then the problem is not the tool, the problem is the developer. MS's market was full of amateur-hour developers because their platform (WP7) was weak and lagging behind, thus incapable of attracting the top tier of devs. And then they poured gasoline on that fire with a barrage of silly incentives that were ignored by pros but attracted even more beginners. Now, to put a cherry on that fine mess, they attempted to remedy their bad business decisions with a technical solution that damaged the one asset they really had - an advanced and ahead-of-the curve app-development story. One own goal after another, really.
- alkonaut 7y ago
  Those feel like they were created by orders from top management, because of some strategic decision (microsoft needed a flash alternative, or a Windows 10 store UI framework etc). They don't feel like the product that would come if DevDiv did their best to produce a sane UI framework. They feel rushed, semi-overlapping, half-finished. I imagine it should be possible to make just one more xaml framework which is cross platform, and much better than WPF (and it's derivatives), and much better than the js alternative (Because of deployment, not least). I'm not sure if there is any incentive for ms to put their weight behind it however.
  - m_fayer 7y ago
    Hopefully that last xaml framework is avalonia, it's definitely gaining steam.
    - alkonaut 7y ago
      Yes. But for one of these to really take off, I think what's needed is for one of the giants to throw their weights behind it. Basically "We're betting x billions on it, so you can be sure that lots of companies will be using this tech in the decade to come".
    - wiso 7y ago
      The XAML in Avalonia is great. There is even support for XAML to IL compilation during build so you don't have any parsing overhead when running your app.