6 ms·

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 "re

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.
    - pjmlp 7y ago
      "Keeping apps fast and fluid with asynchrony in the Windows Runtime" https://blogs.msdn.microsoft.com/windowsappdev/2012/03/20/keeping-apps-fast-and-fluid-with-asynchrony-in-the-windows-runtime/ https://blogs.msdn.microsoft.com/windowsappdev/2012/03/20/ke... As for the rest, I only agree it was a big mistake not to have a proper migration path. However, WinRT was anyway the result of Synfosky's team (aka WinDev) being on the winning side, after they won over Longhorn, so not so much .NET love was going on back then. And we had to wait for iteractive releases of Windows 10 slowly fix all those mistakes.
  - maxxxxx 7y ago
    There are other ways to deal with this besides async. It would have been fine if they had added async but you can’t just remove the synchronous functions and expect people to port existing apps with perfectly fine multithreaded code to async. This would be a lot of work without any payoff. Whatever their reasoning was it was just plain dumb, heavy handed and unrealistic.

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.
  - pjmlp 7y ago
    "Keeping apps fast and fluid with asynchrony in the Windows Runtime" https://blogs.msdn.microsoft.com/windowsappdev/2012/03/20/keeping-apps-fast-and-fluid-with-asynchrony-in-the-windows-runtime/ https://blogs.msdn.microsoft.com/windowsappdev/2012/03/20/ke... As for the rest, I only agree it was a big mistake not to have a proper migration path. However, WinRT was anyway the result of Synfosky's team (aka WinDev) being on the winning side, after they won over Longhorn, so not so much .NET love was going on back then. And we had to wait for iteractive releases of Windows 10 slowly fix all those mistakes.
- maxxxxx 7y ago
  There are other ways to deal with this besides async. It would have been fine if they had added async but you can’t just remove the synchronous functions and expect people to port existing apps with perfectly fine multithreaded code to async. This would be a lot of work without any payoff. Whatever their reasoning was it was just plain dumb, heavy handed and unrealistic.