Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Why all the "WPF/SL is gone" claims make no sense

DZone's Guide to

Why all the "WPF/SL is gone" claims make no sense

·
Free Resource

I've seen a lot of controversy lately about the fact that BUILD was primarily focused on a set of new development technologies and less on the older (to some extent) ones. Specifically, there is one article that bases its assumptions on the fact that in the Developer Preview there is no support for Silverlight and other plug-ins in the Internet Explorer integrated with the Metro shell.

Though it has been hard, we have been trying to avoid reporting on rumors about the death of Silverlight for quite some time. [...] Unfortunately the end of Silverlight is no rumor; if Microsoft doesn’t change course it, as well as Flash and other plugin technologies, will be effectively unusable when Windows 8 is released.

First, let's get this straight - the Metro shell is targeting touch-based devices. In the first place, for now, those devices would be tablets. Now let's look at the current tablet market - think of how many browsers support additional plugins and why those are not really supported. Then get back to the Metro shell.

The article I linked seems to avoid mentioning the first fact that Windows 8 is not made only of the Metro shell. There is also the regular full desktop experience, with the same build of IE (although not adapted to the new environment) that supports plugins and extensions. Only at the end, we see this:

It should be noted that Flash and Silverlight will continue to run just fine using Internet Explorer in “desktop” mode. Likewise users can elect to switch to one of the other browsers such as Firefox, Safari, or Chrome. But again, those run in desktop mode.

So what exactly is the problem here? I am familiar with the fact that some developers will be unwilling to write HTML5/JavaScript based applications, so being cut out of the Metro browser might be a problem - but is it really?

If there is a Silverlight application that you are eager to push through the browser, you might as well push it as a separate application, and Windows 8 will let you just do that with the upcoming Marketplace. Maybe not every single app can be done through Metro, and that is exactly the reason for the Desktop mode.

During BUILD, there was mostly no direct mention of Silverlight as such, but the development still can be done through XAML, C# or VB.NET, and on top of multiple well-known APIs.

Since they cannot simply port their code to Metro they will need to need go rewrite the components from scratch using HTML and JavaScript.

To be honest, that is not going to be a problem at all - the codebase can be mostly preserved with some small modifications to ensure that the application fits the system requirements. Nobody forces developers to use JavaScript coupled with HTML5. We saw this in a couple of demo sessions, and this is one of the strong points of development on top of WinRT - a pretty good set of choices that should fit various groups of developers.

How do developers expect to be building innovative applications if they don't expect technologies to change over time? One of the first things developers should always remember is things change. Fast. Your knowledge today can become somewhat outdated in a year or even less, so be used to re-adapt, especially if the technology in question doesn't disappear but is redesigned.

Silverlight has been around for almost 5 years, WPF - for almost 6. With their development timeline, it is normal to expect that some of the APIs will get changed, removed, extended and maybe re-integrated. This is exactly what happens with Windows 8. XAML and the .NET API is there. It's all simply remodeled to adapt to a new environment, even if it doesn't carry the WPF or Silverlight labels.

It's all still there, in a different shape. You already know most of that stuff if you are a WPF/SL developer.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}