Sunday, 5 December 2010

The Future of Silverlight

I've spent most of my weekend watching downloaded HD video's of the Silverlight Firestarter event held last Thursday. (You can download all the video's from the day via links posted on John Papa's blog).

The first thing to say is, giving credit where credit's due, Scott Guthrie's team did a superb job at turning around all the negative stories about the death of Silverlight that have plagued the technology since rumours of its imminent demise first started to spread in August this year.

The really good news is that there's a ton of exciting new features coming in Silverlight 5 (You can read a very good summary of these on Tim Heuer's blog). These are important features regardless of whether Windows Phone 7 succeeds or not (and the signs for Phone 7 are not good, as an article in The Times (Warning: linked article is behind paywall) earlier this week demonstrated). The keynote did a great job of quickly and efficiently showing these new features off to best advantage. Indeed, it made the PDC2010 keynotes look like the tired, lame relics they were and I would imagine those UK Silverlight developers who made the expensive trip to Redmond for this year's PDC must be kicking themselves that they didn't opt to go to this 'free' Silverlight Firestarter event instead. I suspect many late nights have been had in Redmond to give this event the zing it needed, and Microsoft delivered on the zing big time.

So the good news for those of us working with the technology, and loving it, for the moment at least, is that Silverlight seems to have won something of a reprieve, especially for those wanting to write RIA applications that can run in a browser on the Windows platform.

However I didn't see anything that contradicted my last, rather gloomy, post about the longer-term future of Silverlight in a world full of new devices running non Microsoft software. Despite all the references to 'now' from the speakers, as if these much needed developer productivity features were here today, Silverlight 5 is a year away! A year is a very long time in the currently fast-evolving world of device and platform development, as the last 12 months have shown. I guess this long wait is understandable given that effectively we were being shown material originally intended for next April's MIX11 event, but Windows Phone 7 is proof that such delays can cause what is initially perceived as an exciting product to be delivered still-born. And as I said in my original post, there was never any doubt that there was going to be a Silverlight 5: it's after that which enterprises need to have confidence in if they're to take what is perceived to be the highly risky step of building new applications on top of Silverlight, whose long-term strategic (as opposed to tactical) importance is unclear.

The firestarter event keynote kept emphasising that '70% of user requests are being fulfilled in Silverlight 5', but nobody saw fit to point out that by far the most demanded feature - for greater reach - is being completely ignored. There's a reason why Silverlight was originally called WPF/E (the E being for 'Everywhere') and Microsoft are foolishly ignoring the no.1 most demanded feature from their user base, seemingly to concentrate on Windows-specific features. Bad move. Very bad move. Parity with (replacement of?!) WPF is OK I guess, but not if it comes at the expense of reach and if WPF already delivers what is required for the Windows client base, why waste effort on duplicating that in Silverlight instead of delivering what users have made quite clear what it is they really need. Microsoft had a great opportunity to improve things in this area with the purchase of Novell, who have been working on MonoTouch and Moonlight to port .NET and Silverlight to new platforms, but have foolishly let Attachmate sneak in and take over the company, making the future of these ports extremely uncertain. This is very bad news for those of us wanting to see the platform achieve greater 'reach' as well as greater 'rich' and who think this is the only way the technology will survive longer term.

The problems that have held Silverlight back (mainly around initial productivity because of the steep learning curve), at least as far as developer take-up is concerned, remain and don't appear to me to be being addressed. PRISM v4 has NOT delivered on the promise made more than 18 months ago that best practice guidance was on its way. Try finding anything on 'don't repeat yourself' validation typically required both server and client side in real world applications. Try and find information on taking the recommended Inversion of Control approach for things like event aggregation but also ensure your application doesn't blow up when opened in Blend (a reference to a non-existent 'Blendability' section, highlighted as if it were a hyperlink when it isn't, doesn't count!) Try finding anything relating to WCF RIA Services and how it fits into this MVVM architectural world view. Try finding any reference to Silverlight's Application Extension Services, or ... well you get my drift! There's nothing there!

PRISM v4 seems largely to have been a 'smoke and mirrors' exercise to patch the v2 release, with post-release blog entries rushed out to address basic questions like 'How do I integrate PRISM new 'roll your own' navigation with the Silverlight Navigation Framework?' It's just not good enough after 2 years waiting!

I've heard, unofficially, from contacts within Microsoft that the team working on PRISM was 'large' - but I see little evidence of that in what's been delivered: essentially a bit of freshening up of the release we got 2 years ago. There's some new stuff to support MEF and make sure the acronym MVVM finally appears, but important MVVM reference information hidden away in QuickStart tutorial appendices or great gobs of source code, rather than the main 'take a week off work to read it all' reference book isn't going to get seen or read. Worse, whoever put together the new 'MVVM Reference Implementation' appears to have a very different view of what a Reference Implementation should contain - it's far too simplistic to deserve the 'Reference Implementation' title and it does nothing to bring all the 'smorgas board' options available in PRISM together. So many different approaches have been taken in the different quickstarts that it's small wonder that most developers look at these, scratch their heads and want to run back to the safety of the ASP.NET/AJAX development environment which they understand and can relatively quickly deliver working applications in.

I've recently started work on a new project that is going to be using WCF RIA Services. Being pretty green with WCF RIA Services (It looked too much to me like 'drag and drop demoware' but that's not the message Microsoft are giving their corporate clients) I decided to run the planned architecture by WCF RIA Services MVP and all-round good guy Colin Blair for sanity checking. Over a few emails I mentioned how good I thought John Papa's PDC10 talk on Best Practices for MVVM had been, and how I wished I'd had that talk a year ago instead of having to learn things the long, slow, painful and totally unproductive way. Colin pointed out that John made a mistake using ObservableCollection to hold entities which is a big no-no with WCF Ria Services (some details on why here) which demonstrates how ridiculous claims that Silverlight automatically makes developers immediately productive is: if the Microsoft 'experts' who've been working with this stuff for years can't keep up with the disparate technologies needed for Enterprise Line-of-business apps and use them correctly, what hope for the average developer?

If my experience at several clients is typical, the reality is that most Enterprise developers are still pretty much stuck at an ASP.NET 2.0 level knowledge of C# because they haven't needed to get to grips with all the stuff that came down along the line later. So the real issue in moving to Silverlight is that not only will a developer have to get to grips with a completely new way of programming (XAML-based) and the core Silverlight technology itself, and also the MVVM pattern and far too many competing frameworks to help deliver on MVVM, but also basic techniques they won't have used before like asynchronous programming, understanding Lambda expressions and LINQ, and a seemingly never-ending series of 'supporting' (but required) frameworks like PRISM, MEF, Unity, Silverlight Navigation Framework, Entity Framework, the Reactive eXtensions framework etc all of which have equivalent 'open source' offering which may need to be understood and compared with before making a choice on which are 'the best' for their specific scenario's.

The Silverlight Firestarter was a great kick-off for of Silverlight, but there's still a long, long way to go if Silverlight is truly to move into the developer mainstream. I'm still not convinced that Microsoft (or their Silverlight MVPs) realise how big a task educating developers will be, or even understand that without it mass take-up of the technology is doomed to failure, despite all the enthusiastic reviews from those who have overcome the steep learning curve and learnt to really love the technology.