Linked by Kyuss on Mon 13th May 2013 01:31 UTC
Microsoft "Most people understand that Windows is used by a variety of people who have a variety of needs, ranging from corporate server to workstation to POS terminals to home PC and beyond. Most people accept that whenever Microsoft updates Windows, it has to balance the competing requirements to find some kind of workable compromise. There is however another set of competing requirements that many do not really register, even those that call themselves power users or are IT admins. It is a conflict between developers/programmers and Microsoft itself."
Permalink for comment 561312
To read all comments associated with this story, please click here.
Comment by Nelson
by Nelson on Mon 13th May 2013 02:51 UTC
Nelson
Member since:
2005-11-29

The death of Silverlight is an understandable one. Times changed. Just like WCF, which was a typed approach to web services, Silverlight is just mismatched for the current times. As originally envsioned, Silverlight was much more than a LOB app platform. It was an entire RIA stack and video delivery framework. HTML5 and especially the video tag took over for a lot of the reason that Silverlight existed. The things that remained that Silverlight was *really* good at was a small niche which didnt have enough clout to matter.

An interesting twist being Silverlight being repurposed for Windows Phone. It is still pretty actively used there but its obvious that Windows development is trending towards the Windows Runtime. The latest Silverlight incarnation in WP8 exposes a small subset of WinRT APIs on the phone.

Generally though, from the perspective of developers that Microsoft targets, they've done well. They target existing mobile app developers (Windows Phone, iOS, Android) and they target existing Game vendors with DirectX and various middleware technology.

For the purposes of Windows 8, this is enough. On the enterprise side, they have a very sizable and growing presence in Windows Azure along with SharePoint and other Office related properties. That's significant and is attracting a new breed of developer to the Microsoft stacks.

What also cannot be downplayed is the fresh talent that the Windows Store platform is attracting. There are over 65,000 Windows Store applications. The barrier to entry to making money on Windows has never been lower. It is easier for small time developers to make money on Windows.

So, really the issue is that Microsoft is taking a phased approach to transitioning developers to the Windows Runtime. This time around, it was a consumer focused release with consumer focused APIs getting the lionshare of attention. WinRT is already in Windows 8.1 showing signs of improvement in functionality.

That's not even mentioning the fact that today native developers can use a subset of the Windows Runtime APIs from their Desktop applications.

WPF turned into Silverlight which turned into the Windows Store platform. Its all the same underlying technologies, albeit smarter implementations with varying feature sets. Silverlight was always an offshoot of WPF for a different use case. The WinRT APIs are more comparable to WPF in use case, but pared down for the Windows Store sandbox.

Btw: Windows Forms was always a managed wrapper around MFC, a wrapper around Win32. Most of us understood that it was a stop gap measure, plus WPF was already showing up in PDC builds as Avalon. We knew more was coming. The only people who got fucked over on WinForms were the LOB people who generally don't have much forward facing agendas once they're developed to spec.

The Windows Runtime is Microsoft's attempt to fix the problems of the past. WinRT enables a language neutral rich API set to be exposed to many languages. You can invoke an asynchronous API in WinRT, await its value, and chain a response with Javascript Promises. You can do the same in C++ with the PPL or in C# with async/await and the work stealing task scheduler.

It blurs the line between managed and native code. Microsoft can write WinRT components in C++ and consume them naturally from JS and C#. They can write the less performance sensitive ones in C# and consume them from JS and C++. Its really flexible.

It will make the exact problems this article brings up a thing of the past. The WinRT XAML stack is the UI framework for native AND managed code in Windows going forward. That's the richness of WPF with the performance characteristics of native code.

From another angle, Microsoft is improving managed code performance with Cloud Compilation on Windows Phone 8 which makes start up times for apps nearly instant.

Microsoft is unifying its platforms across various form factors and execution models. Looking forward, things are incredibly exciting.

This is Microsoft's .NET, Longhorn, and Avalon vision imagined.

Reply Score: 2