Bugs in Silverlight?

Dr. Evil: Right, people you have to tell me these things, okay? I've been frozen for thirty years, okay? Throw me a frickin' bone here! I'm the boss! Need the info.

I've seen more than a few posts on the Silverlight Forums where people are complaining (or sometimes just asking for help / guidance) on issues where they appear to be attempting to "tax the system"  and thus expose what they believe is "a bug".  Hey - Silverlight has bugs - even release software does -- that's not the issue. But creating artificial programming situations where one can claim "It's a bug" is not always a  legitimate effort.

More often than not, this revolves around issues like "memory leaks" when attempting to set up some sort of "test" code that does some operation in a tight loop, or some similar operation that does not necessarily relate to what would likely happen in a "real world" Silverlight application. The poster then takes great glee in the assumption that they have "found a bug". Sometimes, it's just "attention seeking", and other times it revolves around an incomplete understanding of what Silverlight is, and what it's capabilities really are.

I think it's important to understand that the Silverlight runtime is based on a subset of the .NET Framework which is normally installed on the client in about 10 seconds - without the requirement to even restart the browser in most cases. In order to accomplish this, a lot of "stuff" had to be left out.

There are workarounds for some things, and for others, there are not any workarounds.

The key thing to remember here is that if you are designing a new Silverlight application that relies on some assumptions that you could normally make with some degree of confidence with the full .NET Framework, when attempting to do this with Silverlight, your assumptions may very well be "out the window". It "is what it is" - and you have to be able -- and willing -- to work with it. Not just that - but you also must be willing and able to invest the time to discover "why" you may not be able to do what you want.

What's important to keep in mind is first, to test your assumptions extensively and see how they  perform.

The second, and perhaps more important principle -- is to understand that in order to accomplish your objective, you may need to refactor your approach so that it does not tax the SL runtime - which is a subset of the full Framework that runs in the browser, on the client. 

For example, if you are going to create 10,000 UserControls in a tight loop, calling GC.Collect both immediately before and then after each iteration -- and then proceed to complain about memory leaks -- ask yourself if this is a scenario that is really likely to play out in a real - world Silverlight application. If you think it is, then maybe the problem is that you simply need to revisit your original assumptions and make appropriate adjustments that come into play a little bit closer to "runtime reality".

The SIlverlight forums are rife with this kind of "complainer post" - but they also have a significant number of interesting and extremely useful posts and answers. I saw one user who signed up with the name "SILVERLIGHTSUCKS" - and proceeded to make allegations that belied a true understanding of how Silverlight media streaming works, and why. You could see that one coming from a mile away :-).

I think Silverlight has huge potential for a variety of applications including LOB apps that present exciting UI interfaces to complex business scenarios. But like Flash / Flex, everything has its limitations. In general, Developers need to invest the time to learn what these limitations are and then they will be able to ask more intelligent questions.