- Apr 09, 2012 at 3:23 AM
- Shawn Wildermuth
- 17 Comments
A lot has been made since a report from Microsoft late last week (http://shawnw.me/HPEh0R) 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!
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.
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. "
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.
The article says that the existing apps will run too without re-writing them.
Your probably correct that is doesn't matter but then Microsoft should come out and say it and not dance around the issue.
You have that wrong. C++/C#/VB with XAML all work on ARM (or are supposed to).
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.
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).
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.
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)
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.
You have trade-offs either way.
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.
But what about existing WP7 devices? Will we be able to upgrade them to WP8? MS refuses to give direct answer.
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.
-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.
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.
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.
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.