Why I stopped my Silverlight 1.1 Work

Pete Brown - 03January2008

You may have noticed that I stopped putting Silverlight 1.1 code out on my blog and stopped talking about 1.1 at local events. I even keynoted the Silverlight FireStarter back in December and barely mentioned 1.1 in the process (I think it rated one slide). There are a few reasons for that:

1. 1.0 code is far more stable. It's not an alpha or even a beta, it's production. Silverlight 1.1 is alpha code - an early "look at what the future holds" type of release. If you are looking to do something on a production system in Silverlight today, you really want to use 1.0 and enjoy what it can do when integrated into your real AJAX-style application. If you want to do Silverlight sometime later this year, you'll want to follow some of the 2.0 guidance below.

2. Pushing 1.1 out to clients is causing confusion and install issues. I see this on Silverlight.net, and that is primarily a developer portal full of bright folks. While 1.1 is great as a way to learn about Silverlight, it shouldn't hit end-user computers; only developers. There have been a few proof-of-concept exceptions to this, but otherwise broadly exposing 1.1 to non-developers is only going to leave a bad taste for Silverlight. Why?

1.0 has had bug fixes that the 1.1 alpha has not had.

1.1 alpha will not auto-update to 2.0. It's a manual step and likely messier than end users are going to tolerate

3. Silverlight 1.1 alpha is like the concept cars shown at the major auto shows. While they give you a flavor of what is coming, the final product is often quite different (not to mention that concept cars are often plywood and blow-molded plastic <g>) Given what Scott Guthrie (look in the comments too), Tim Sneath, and others have said about Silverlight 2.0, some of the 1.1 code and XAML would likely change in a 2.0 world to provide a more consistent and feature-rich developer and end-user experience. If you do anything complex, you'll probably find yourself removing all sorts of workarounds at the least, or completely rearchitecting your application.

If you want to learn Silverlight today but don't plan to deploy until 2.0 is out, what would I recommend? I recommend a two-pronged approach of learning 1.0 with JavaScript and learning how to write basic WPF XBAPs using features that Scott and others have announced will be in Silverlight. IMHO, this is the best way to prepare yourself for 2.0. Learning 1.0 will get you familiar with how the browser-based Silverlight applications work, and how they fit into larger web pages. Most importantly, you'll be able to write real production-ready code, even if it is just proof of concept. Learning the basics of WPF will prepare you for some of the things that may end up in Silverlight 2.0, as mentioned by Scott and others and will also teach you another valuable RIA platform in the process. It's win-win.

When Silverlight hits beta around MIX (per Tim), then you can switch over to learning 2.0 with all the support a go-live license has attached to it.

That all being said, don't let me discourage you from tinkering with Silverlight 1.1 alpha, just do so with your eyes open, and understand it's temporary. [:D]

7 comments for “Why I stopped my Silverlight 1.1 Work”

Well, I'm currently not using Silverlight 1.1 in production, too. I think the next beta will change things (because of the Go-live license).

What I don't understand is that in the past too many technology previews made available to everyone. Nobody understood the difference between 1.0 and 1.1. Now, with 2.0 it can change a little, but others are asking: why develop for 1.0 when there is 2.0 available near in the future?

I hope that future technology bits will not made public available to ensure that there is a higher acceptance for new stuff.

<p>Hi Michael</p><p>1.0 is very compelling if you are looking to do rich media and/or want to integrate the Silverlight content into an AJAX application using JavaScript.</p><p>If you're a .NET person, starting from scratch, and want to code in .NET on the client, it's harder to make a case for 1.0. </p><p>For .NET developers, there's no doubt that 2.0 is the more compelling choice. However, for a lot of web developers, client-side JavaScript is just as comfortable, and they'll be able to do some pretty cool things in 1.0. Plus, all the code they write in 1.0 will be forward compatible with 2.0 unmanaged JavaScript silverlight applications.</p><p>Pete</p>

Really the only thing that slowed down my 1.1 development was ScottGu's announcement of form objects.

Right now we're creating everything from scratch and who wants to maintain a private textbox-ish user control in their managed code when there very well will be an official MS supported TextBox control to inherit from?

Right Ian, but there's much more to it if you're doing anything deep. For example, using JSON was cramping what we could do in terms of returning real objects full of data. The announcement of SOAP support helps eliminate that problem. Similarly, the annouced change in the package model made me question how I would do preloader-type stuff.

I totolly agree on controls. If the model is to move to one like WPF, it will be totally different. For that reason, I temporarily stomped on my own 1.1 versions of custom controls projects. I hope to have some new things ready once 2.0 hits beta.

If you have a real deadline, you can definitely make some educated decisions based on what was annouced. You can also work on business logic, service tiers etc.

MS completely gimped 1.0 by announcing 1.1 so soon. Made it completely irrelevant except in the small cases you mention in your post. They should have just announced 1.1 as 1.0. It would have been a much more compelling technology and announcement. Now, 1.0 is barely a Flash competitor and it'll go away completely once 2.0 is released. There wasn't really any market pressure to announce early because they weren't really in that market yet.

From my perspective I could not have been more happy with Microsoft releasing 1.1 to the developer community. It has given myself and fellow collegues the opportunity to get up to speed with key concepts of silverlight from a c# perspective. When 2.0 comes out I'll, and my fellow collegues, will be able to "hit the ground running" and churn out some really compelling stuff.

Playing with silverlight 1.1 and wiring up the xaml to c# has really given us a huge head start against those that haven't touched it at all.

Making my own controls in silverlight 1.1 (textboxes, dropdowns, etc. ) has been an invaluable learning experience. I keep telling people that what we build today with 1.1 will hold us in good steed for the future.

I keep looking at samples and creating my own because i know that it will benefit me in the long run.

I agree. Developing in 1.1 was a lot of fun, and I gained a lot from it. I don't expect a lot of that to translate cleanly into 2.0 from a code perspective, but conceptually much of it will.

I'm just starting to see folks building a lot in 1.1 and expecting it to just work in 2.0, and that is unlikely to happen. I'm also seeing a lot of installation issues, many of which are due to 1.1, and may hurt adoption at least in the short term.

That all being said, 1.1 doesn't help adoption right now, but 1.0 will. If you build a 1.0 solution, you'll get silverlight on an end-user desktop and help with increasing the number of installed desktops (the main hurdle with sl right now). 1.0 will auto-up to 2.0, whereas 1.1 will not.

Pete

Comment on this Post

Name (required)

Email address (will not be published) (required)

Website url

Remember me

Your comment is being submitted, please wait...

Your comment has been posted, thank you. (If your comment does not appear shortly, it was marked as spam.)

I previously blogged about why I stopped coding in Silverlight 1.1 . I want to make it clear that that

Pete Brown is a XAML and Blinky lights guy at Microsoft who focuses on Windows XAML (WinRT), WPF, Silverlight, .NET Micro Framework and other "code on the client" and "code on a device" technologies. This is his personal blog.
About Pete/Full Bio | Contact | About 10rem.net