3 ms·
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 fo
by 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.