I just arrived back from teaching Silverlight in Toronto and was thinking about what I was doing this time last year. A year ago I had just finished spending a couple of months with WPF/E (the name before it was Silvelright) and had given a two day class in Seattle to some internal groups on WPF/E. In addition, I was just finishing up the first draft of the WPF/E (previous name of Silverlight) appendix for Chris Sells/Ian Griffith’s WPF Book. I’ve spent most of this year working on Silverlight (both articles, the courseware and actually teaching the Silverlight Tour). Its been a great year.
With the Silverlight 2.0 release on most people’s minds (with its probable Beta at MIX 08), I’ve decided to take a look back and note some of my major observations about where Silverlight is now and where I think it is going:
- Silverlight 1.0 is a great platform for creating interactive or video solutions.
- Silvelright 2.0 will be a great platform for creating Line of Business applications in addition Silverlight 1.0 capabilities.
- Silverlight still has to catch up with Flex on features (even after 2.0 I think) but the tool story is surprisingly mature for a product of its age.
- When you can view advertising in Silvelright, the plugin will be officially ubiquitous (e.g. users won’t install the plugin to view an ad).
- Silverlight 2.0 has a real control model, Silverlight 1.0 does not.
- I wonder how much of a story the DLR support for Silverlight really is.
- Silverlight needs a packaging format similar to .swf files to compete in some situations…should be an option not the default behavior.
- The Designer/Development story is great for Silverlight…hopefully MS will do the same for HTML (e.g. allow Expression Web to open .sln files please please)
Other than the normal features coming in Silverlight 2.0 (read Scott Guthrie’s blog here to see the roadmap), i’d like to publically lobby for the following features/changes:
- A solution similiar to Flash’s for a white-list of allowed cross-domain requests. The existing cross-domain scripting limitations is great for security but makes building solutions tougher.
- Assembly resolution in the current request is just broken. Its too hard to package up multiple assemblies unless they exist at the root of the web server (which is the wrong place). Hopefully a web-enabled fusion solution will appear.
- Allow assemblies to work with WebResources so that we can embed assemblies into ASP.NET AJAX controls to simplifiy the deployment strategy.
- Support some sort of obfuscation to help 3rd party control developers protect their IP.
- In the upcoming ASP.NET Silvelright Control, support embedding the XAML into the page to reduce roundtrips.
- A better solution for additionally downloaded fonts than have to assign font packages to each and every TextBlock individually.
- More controls are better than data binding…so if you have to made a decision between delivering data binding and reducing the #/controls…please give us more controls and no data binding.
What do you think?
