Does Silverlight Matter to Windows Phone 8?

right-HERO_MANGO_062411A lot has been made since a report from Microsoft late last week ( that seemed to say that Silverlight on the phone was going away in Windows Phone 8 (Apollo). I liked a lot of what this article had to say (from e-week):

So it got me thinking that much of the Silverlight community would be jumping out of windows (lower case and not TM) this week due to the news. But of course, if that's the case for you, I'd urge you not to panic. Why? Let me tell you.

CAVEAT: I am guessing and have no inside knowledge on what Windows Phone 8 is going to do. Really!

Silverlight and Me

I came into Silverlight because of my prior work with WPF. But it's more complicated than that. I came to WPF at a time when I was primarily known as a database guy (my old moniker was "The ADO Guy"). So why would I care about WPF? Data binding.

I am not a UI/UX guy. I can barely match my own socks. But I came to XAML because I saw the potential of building apps using a smart markup language that has the possibility of a real data binding framework (unlike MFC, VB5/6, WinForms, ASP.NET WebForms before it).

I got into Silverlight because I lucked into being there at the ground floor (I taught a WPF/E course at Microsoft to MS employees and partners before it was publically named). But even in the early days of XAML + JS, I saw the potential of building apps (not sites) with XAML. The fact that Silverlight was originally to build them in the browser was tangential. In fact, I liked Silverlight (v2 and beyond especially) because it learned from the lessons of WPF (which in my opinion is over engineered somewhat) and simplified the XAML so that it was consumable in a short period. The lack of features like Triggers and a simplified text stack meant that people could get up to speed fairly quickly.

Windows Phone 8 and XAML

What the Microsoft folks said was that Windows Phone 8 development would be much more like Windows 8 XAML development. That meant that Windows Phone 8 would probably have the underpinnings of WinRT. Should anyone panic? Nope. Here is why.

The WinRT XAML stack is based on Silverlight 4. What losing Silverlight does is say that the XAML (and data binding stacks) are going to be unmanaged. That's a good thing. In Silverlight (especially on the phone) the managed part of the XAML stack (data binding et al.) got in the way of a great touch experience. In Mango, the Windows Phone team built several ways of keeping the experience smooth by doing a lot of tricks, but it is still pretty easy to screw it up as a developer. WinRT works differently. The entire XAML stack is in unmanaged code and the entire WinRT framework is built with async in mind. It makes it easier to build fluid, touch-enabled applications (or it should).

The other benefit is that it brings together the Metro-style application development on tablets and the phone. This is a big win for developers. This is likely not going to result in a single app working on both devices, but it should allow many of the assets to be more sharable. We have no details or promises yet, but if some of the features of WinRT come to the phone, we're all in luck. I am especially looking forward to Contracts.

WinRT XAML Development

I've been digging into the Windows 8 XAML stack and as of the Consumer Preview I am really enjoying the experience. The Consumer Preview build is pretty close to Silverlight's implementation IMO. There are likely some missing pieces, but all the big pieces are there. Adding to that, the great Visual Studio 11 XAML editing experience (powered by Blend) and I think you'll find the development experience is really good right now.

If you're a Windows Phone developer already, the experience of developing for Windows 8 (and Windows Phone 8 probably) will be pretty similar. App.xaml holds the application level events. Navigation to individual XAML files and support for a back-stack. Adding to the benefits here are things like Live storing of settings in the cloud (instead of inventing this yourself) as well as smoother touch APIs mean that the transition to WinRT should be smooth for Windows Phone developers.

If you're a WPF or Silverlight developer, there are pieces to learn (like Navigation and touch) but the XAML design experience should very familiar. If you're not digging into WinRT yet, it's time to dip your toes into the water!




Dave Baker Monday, April 9, 2012

Big ask of Microsoft for 80K of apps to be converted to Apollo. Will it run old apps or start from zero? I am a big fan of Silverlight. Moving to Mango was problematic, and SL4/Xaml to WinRT/Xaml has its moments. What about XNA and XNA/Silverlight? I hope they know what they are doing as I'm starting to doubt it. I guess I'm not seeing any credible 'big plan' which is needed for dev community to buy into.


Andrei Monday, April 9, 2012

Hi Shawn,

Nice rant on this subject.
Can you please an example for

"That's a good thing. In Silverlight (especially on the phone) the managed part of the XAML stack (data binding et al.) got in the way of a great touch experience. "



Erno Monday, April 9, 2012

To me it makes perfect sense to converge all development to native apps with xaml and your favorite language and widely available apps in HTML5 + javascript for browsers. I'll consider HTML5 + javascript for native apps when tooling makes me as productive as the xaml + C# stack.

For dev departments it is hard to switch if they've just gotten used to Silverlight because the most fitting migration from a deployment and reach view is HTML and javascript.

For native devs that are used to xaml, WPF, Silverlight, the transition to WinRT is easy due to the language projections except for the deployment but my guess is that there will be private/corporate areas in the marketplace.

After all the dust has settled, what is the difference between a tablet and a Phone? Between a tablet and a PC?

The tricky part is to plan the future of the current applications.


Shawn Wildermuth Monday, April 9, 2012


The article says that the existing apps will run too without re-writing them.


Marcos Monday, April 9, 2012

How Silverlight/WPF knowledge could be used in ARM tablets since Windows 8 will only run Metro applications(HTML + JavaScript)? Or am i'm wrong about that information?


Frank Monday, April 9, 2012

Your probably correct that is doesn't matter but then Microsoft should come out and say it and not dance around the issue.


Shawn Wildermuth Monday, April 9, 2012


You have that wrong. C++/C#/VB with XAML all work on ARM (or are supposed to).


Sam Covington Monday, April 9, 2012

This is a good thing!

Native XAML, with C#/C++ as the "Scripting Languages" is a real winner.

I won't go full C++ unless it's really needed, I think using C# with any critical parts written in C++ is the perfect blend of productivity and performance.

Microsoft has made this transition with all the diplomacy of a bull in a china shop, but it really makes a lot of sense.

Will it be too late? I'm not sure, but IMO, it will take success in tablets for the phone business to have ANY chance!

Nokia can't save them all by themselves.


Pete Tuesday, April 10, 2012

I think that most developers would be wary of going down a XAML route after the treatment that MS gave Silverlight. It would be different if WP7 had significant marketshare, but I personally will follow the HTML5/Phonegap route in future for fear of become obsolete (again).


Shawn Wildermuth Tuesday, April 10, 2012

Pete, I understand your concerns. The HTML5 and PhoneGap solution definitely works, but I would think that for deeper applications, it just isn't there yet. I still think of PhoneGap as a bridge to richer, native apps. But that's just my opinion.


SleepyDaddySoftware Tuesday, April 10, 2012

Yes, PhoneGap is just a stop-gap to a fully native app. On windows 8, you'd be better off just using winjs, as it provides deeper integration than ohonegap (supports charms, win8 controls, etc)


Jeff Ammons Tuesday, April 10, 2012

Like everything else, it depends on what you are building and what your concerns are.

If you can target Windows8/Phone/Tablet only, then the XAML + language approach is going to give you the most options for depth and richness on those platforms.

If you need to target as many different platforms as possible, then the HTML/CSS/JavaScript route is a nice option. Not every app could be built this way, but for the ones that can, you can increase your re-usability of code.

You have trade-offs either way.

I think my approach will be to approach projects with an HTML first approach for the broadest reach, then consider XAML for projects that require something I can't do in HTML/CSS/JavaScript.

The reality for all of us is that we can't stick by any such statement for long. We have to constantly re-evaluate our tools and skills to meet market changes.


Dee Tuesday, April 10, 2012

But what about existing WP7 devices? Will we be able to upgrade them to WP8? MS refuses to give direct answer.


Shawn Wildermuth Tuesday, April 10, 2012


I tend to agree, but I am not sure how much of the 'code reuse' story is. Skill reuse? Absolutely, but the WinJS story is different enough for me that I am not convinced. Though I do like the 'refresh-app' button in WinJS so that the change/continue model of web works in WinJS.


Dave Baker Tuesday, April 10, 2012


-The article says that the existing apps will run too without re-writing them.
Recent experiences would leave many people to disbelieve this, most like rebuild required and likely code changes, mango ans winrt required these.
As for xna/sl microsoft seem to have let those devs down very badly. Noone has a clue, including ms staff. Not willing to share the future which is iminent july 2012 means they dont have a clue either. If there was some big picture the trumpets would be blowing, they are not.
The picture looks rosy if you have zero investment in wp7 or silverlight. I like the new platform, problem is i dont believe the messages and have zero confidence in a smooth upgrade based on the last 12 months. Words mean nothing in the end.


Shawn Wildermuth Tuesday, April 10, 2012


I understand you're frustration, but I also am aware that they want to keep their cards to their vests like the other players are (Google and Apple). I know we're used to something different, but I am not surprised. Early leaks of features already led Apple and Google to copy them.


Jeff Ammons Tuesday, April 10, 2012

You are absolutely right regarding WinJS. Thing is, I'm not sure whether or not I'll write many apps specifically for Win 8. My experience with Win Phone has led me to stay in the browser with my apps until a new device has gained significant marketshare. In all honesty my time would have been better spent continuing to develop for WebOS than Windows Phone. I base that statement on stats for the same app on both platforms. I spent nothing and made money on WebOS vs. made nothing and spent money on Windows Phone. Who knows if I had moved to either iOS or Android instead.

But I'm not bitter... OK, I'm a little bitter. :-)

An awful lot of apps could just as easily live in a browser these days. Clearly not *all* apps, but way more than in the past.

The tech world has changed enough in the past 3 years that I'm taking some time to re-evaluate where I want to put my energies and time. Not sure where my thinking will wind up, but HTML/CSS/JavaScript seems the safest bet for the time being. I can't predict what the adoption of Win 8 on desktops and tablets will be, but pure web apps can work great there plus on iDevices and mobile OSes named for deserts.

On my Windows Phone I'm using several times more pinned websites than apps at this point too.

So far my favorite experience in Win 8 has been the plug-in free Metro version of IE. Well that and the damned addictive pinball game...

OK, I'll stop now so it doesn't look like I'm starting a new blog inside your blog (you may not have noticed, but I tend to be long winded)... I do plan to blog my thoughts once I get them a bit more organized.

Leave a Comment