Silverlight: snatching defeat from the jaws of victory


We’ve started to use Silverlight which is a great idea hampered by terrible execution. Here’s a link to a control we’ve created and made a available (see previous post or goto http://www.lyquidity.com/silverlight). And this is part of the problem. Why is it necessary for a company to have make available something as fundamental as a reasonable message box. The default Silverlight message and prompt boxes uses the old grey JavaScript boxes. Is that acceptable? Come to that, given Microsoft’s resources and the controls available in WPF, why are there so few controls at all. Sure they’ve provided some (much needed) additional ones on the CodePlex site (http://www.codeplex.com/Silverlight) – a project that’s not been updated in 3 months (at the time of writing).

I’ve been tracking Silverlight for years because its seems a natural and really useful extension of the .NET Platform. It holds out the prospect that there’s no longer a need to have to put up with the limited UI available when using the venerable HTML/JavaScript combination. Flash has been an option for many years but this requires separate development skills and, anyway, it is really an animation engine not a development platform. I had hoped that Silverlight would enable us to leverage our investment in .NET skills and to make our applications available via an internet connection. Sure we can use ClickOnce but it’s not the same as offering a rich UI to clients wherever they are via their favorite browser.

My view is that problems have arisen because a good idea appears to have been handed to the wrong people. Of course it’s got “internet” and “web” in its description so it must belong to the internet guys right? Well, maybe, but the effect appears to have been to put the web developer blinkers around the technology. There’s been a vivid example recently in Tim Heuer’s response to criticism Adobe. The Adobe guys may have been wrong but to me his response underlines that Silverlight is being targeted at the Flash space which is, I think, is an error. It’s a marketing error to play the me-too game in an entrenched vendors space. If Flash is the solution, we’d all be using Flash write our app and we’re not. That means .NET does something much, much more which Silverlight ought to be able to leverage.

But it doesn’t because (I think) the wrong people are in charge of its development. And the effect has been (I think) to eviscerate the Silverlight potential. .NET is a large beast which has many capabilities not required in an environment like Silverlight. OK, so you are going base it on WPF which is itself a beast (did you see the rate at which GAC assemblies grew from .NET 2.0 to 3.5?). So you need to slim it down. But why to fit in 4MB? Why is this magical? The effect has been to cripple the product. There isn’t enough there to be useful. Sure, you can show a video. Great. Does everyone one want to show their videos on-line. No, everyone wants to develop great, easily accessible applications.

Also I wonder about the statistics Microsoft uses. How many of those installed copies of Silverlight are the result of visitors to any place other than the NBC Olymics site? How many can be attributed to Windows automatic updates?

I think the 4MB rationale is a misguided focus on Flash again. As I understand it, Silverlight has to be small to compete with the small installer offered by Adobe. This is patently ridiculous. Again, if Flash was the solution there would be no opportunity for Silverlight. Maybe 5 years ago 4MB would be appropriate but not today unless you are trying to create a solution targeting people still using dialup modems. In the meantime the rest of us regularly download multi-gigabyte movies and have a service that can cope with a one-time Silverlight download. And that’s the public internet, not the much faster corporate networks on which most SIlverlight apps would be deployed. To develop any application in Silverlight you have at least to use the Silverlight Toolkit (see link above) which adds 400K to your application every time the application is accessed. If these controls had been added to the base package in the first place the installer would have been 400K bigger but it would be a one-off cost. Instead a user’s experience of my apps is dragged down by having to download this (and other) payload each time they use it. Unacceptable.

And the 4MB limit has had other unfortunate effects. Why exclude the TextTrimming attribute from the TextBlock control? Why make it BitmapImage.SetSource() in Silverlight and BitmapImage.StreamSource in WPF? I pick a couple of examples from a field with many entries because they are examples we’ve run into recently trying to port controls between WPF and Silverlight. Surely it’s not too hard to have the same properties method signatures. This appears to be change for change sake.

More seriously, one of the requirements of a client-side, browser-based app is that it must communicate back to its server. On the server side .NET has the whole WCF infrastructure to call on. But Silverlight is severely limited. Unlike when using AJAX where we can use the full set of HTTP verbs, in Silverlight we are restricted to GET and POST. If you are creating a video player (how many players do we need – anyway why isn’t it a standard control?) this may be enough. If you want to develop a robust line-of-business app it isn’t. Silverlight *is* able to call and receive a SOAP response from a WCF server – but only if it never errors because Faults are not returned. Every single fault is returned as a 404 HTTP error and it’s not possible to find out the cause of the error. Instead we have to write more code (which means more to download *every time* the app is used) to work around the Silverlight limitations.

OK, some of these might be gripes. But after 5 years I think we might have expected more. My concern is that because Microsoft doesn’t make money from Silverlight it will not be the product we hope. If so, we should be told. I remain concerned that it’s product management is web and Fash focused. I don’t want to create rich *web* applications. I want to create rich applications *over* the web. There’s a difference but I’m not sure the Silverlight product management team sees that difference.

Of course, I’m writing this just before MIX’09 so maybe Silverlight 3 will answer my concerns. We’ll see.

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Be the first to leave a comment!