Death, Taxes and Latency
By the time Silverlight came around, the problems afflicting web applications all round were well known and somewhat well understood. The burden of dealing with network latency, cancellation and errors should not be thrust on every web developer. Platforms have a unique role in abstracting away these problems. However, beyond band-aid solutions, web platforms haven’t provided any effective remedies. With Silverlight we’ve tried to tackle these head on. I wouldn’t say we’ve solved them, but we’re a ways ahead than many others out there in recognizing and fixing issues in this space.
Our strategy involves giving fish as well as fishing lessons. Silverlight enforces an asynchronous programming model for just about every latency, cancellation or conflict -afflicted scenario your web app would encounter. We further the mindset that much everything you’re trying to access can be on a remote machine or can take forever to return or can simply fail. This defensive posture is critical. And so whether it is invoking and consuming a web service, or modifying the UI from off-thread, there is an API in Silverlight that does this asynchronously. We go further though. Aside from areas where it simply must be compatible with prior art in Windows Presentation Foundation (WPF), it is de jure for events in Silverlight to be async. As of Beta 2 I can only think of layout events as being synchronous a.k.a. blocking and at least one more I can’t talk about just yet being added in RTW.
The novice developer may encounter a bit of friction in learning how to code to this asynchronous programming model. But there is friction in learning that Ctrl+Alt+Del unlocks a Windows machine, but you master it pretty quickly, and it becomes muscle-memory after a while. Likewise, we hope you will master async coding soon enough and be on your way to building web apps the way they were meant to. You and your app consumers will be the better off for it.
Another axis to this is the provision of tools and user experience options in Silverlight around async coding. This includes the options of using BackgroundWorker, multi-threading, splash screens and other forms of progress indication. Whatever your expertise, there’s an option available for you.
Still another axis is the defensiveness in the platform to counter issues like reentrancy. Silverlight has a reentrancy guard which will throw a Null AV (resulting in a process shutdown) if it detects reentrant behavior such as a draw call from within an existing draw call. You can be sure to catch these things at development time, rather than deal with them at runtime.
Given the ambient environment where Silverlight is hosted and run, the runtime needs to deal with problems such as message pumping and reentrancy arising from STA threads. Besides it doesn’t own its own UI thread – the browser does. Async patterns really shine here. Please tell us how we’re doing in this area. Has the predominantly async model been a hindrance in your development or had you not noticed until you saw this blog post?
Remember, like death and taxes, latency issues afflict all who build apps for the web. Asynchrony fixes one of those.
Our strategy involves giving fish as well as fishing lessons. Silverlight enforces an asynchronous programming model for just about every latency, cancellation or conflict -afflicted scenario your web app would encounter. We further the mindset that much everything you’re trying to access can be on a remote machine or can take forever to return or can simply fail. This defensive posture is critical. And so whether it is invoking and consuming a web service, or modifying the UI from off-thread, there is an API in Silverlight that does this asynchronously. We go further though. Aside from areas where it simply must be compatible with prior art in Windows Presentation Foundation (WPF), it is de jure for events in Silverlight to be async. As of Beta 2 I can only think of layout events as being synchronous a.k.a. blocking and at least one more I can’t talk about just yet being added in RTW.
The novice developer may encounter a bit of friction in learning how to code to this asynchronous programming model. But there is friction in learning that Ctrl+Alt+Del unlocks a Windows machine, but you master it pretty quickly, and it becomes muscle-memory after a while. Likewise, we hope you will master async coding soon enough and be on your way to building web apps the way they were meant to. You and your app consumers will be the better off for it.
Another axis to this is the provision of tools and user experience options in Silverlight around async coding. This includes the options of using BackgroundWorker, multi-threading, splash screens and other forms of progress indication. Whatever your expertise, there’s an option available for you.
Still another axis is the defensiveness in the platform to counter issues like reentrancy. Silverlight has a reentrancy guard which will throw a Null AV (resulting in a process shutdown) if it detects reentrant behavior such as a draw call from within an existing draw call. You can be sure to catch these things at development time, rather than deal with them at runtime.
Given the ambient environment where Silverlight is hosted and run, the runtime needs to deal with problems such as message pumping and reentrancy arising from STA threads. Besides it doesn’t own its own UI thread – the browser does. Async patterns really shine here. Please tell us how we’re doing in this area. Has the predominantly async model been a hindrance in your development or had you not noticed until you saw this blog post?
Remember, like death and taxes, latency issues afflict all who build apps for the web. Asynchrony fixes one of those.
Labels: Silverlight
13 Comments:
Yes, the async. model work to robust the user interaction.
By
Amit Malhotra, at July 23, 2008 at 10:32 PM
I really like the event driven async model, as it gives me greater control over when to do what in code. The whole "event thingy" is like evolution. Until you get the greatness of it, you dont really get it. I have even begun to fire my own events now :)
By
Anonymous, at July 24, 2008 at 1:24 AM
I also enjoy the event driven async model. I think this is the model that works best for a web-based UI platform. I think individuals will run into problems if they have two server calls that are dependent on each other. However, as you stated, its a learning process. Once you learn about it, it isn't a problem.
P.S. This post has made me think to add something to chapter 6 of Silverlight 2 in Action. Thanks!
By
Chad Campbell, at July 24, 2008 at 5:41 AM
All fine and dandy, but RIA generally needs a fast and efficient platform, and I am not sure wether Silverlight is really the platform for it anymore.
Software Development Expert
By
Anonymous, at July 24, 2008 at 8:12 AM
I love the async model! :-)
By
Anonymous, at July 24, 2008 at 9:05 AM
*Definitely* the right move in my opinion.
Anyone doing AJAX development is already familiar with the async patterns due to the fact that this is the way XMLHTTP works. Therefore it shouldn't present too steep a learning curve for those developers who are looking to step into the Silverlight world.
By
Anonymous, at July 24, 2008 at 9:06 AM
I am an old-time OS internals (and distrirbuted systems) programmer so it is not an "async" model that is difficult.
But what is hard is the lack of documetation about what runs on the main UI thread and what does not.
It seems that I don't need to use the Dispatcher for mouse events, keyboard events.
It seems that I can have multiple instances of a storyboard running that is modifiying Framework elements in parallel.
So other than webclient calls, what does not run on the UI thread?
Or am I playing fast and loose here?
By
DrYSG, at July 24, 2008 at 9:30 AM
Great. According to a couple Microsoft posters on the silverlight.net forums, the switch to async only was required by the various browser plug-in APIs, and NOT a "let's show them a better way" or "most developers are too stupid to handle sync programming properly, so let's take it away from them". If this wasn't in fact a technical decision, then it was a horribly stupid one.
So, short answer, yes, this has been a hindrance. I'm not sure how you see this as "giving fish and fishing lessons", you haven't given anything (quite the opposite), and you've taught nothing. You've stripped skilled developers of a vital tool, and attempted to tailor the platform to clueless dopes who ultimately try and simulate sync behavoir by doing stuff like:
while(SomeFlagHasntBeenSet)
{
}
So what really did drive this decision? The lack of the Invoke method on the Dispatcher object makes me wonder. And if this in fact a dumbing down of the platform, could you remove the int type, as well as all the other built in types? You never know, someone might attempt to calculate the last digit of pi, which will block the UI and other tabs. For that matter, get rid of for, foreach, and while loops, because those could clearly be misused. And please remove the System.Threading namespace, because someone might create lots of threads, which might bog down system performance. While you're in there, might as well gut out the new keyword, because someone might allocate lots of objects, and drain system memory. Just to be extra safe, please make event handlers such as button_click async as well, you never know what someone could do in an event handler. You also clearly need to disable access to the HTML dom, because someone could call the sync methods on the native XmlHttp object. No reason to have GC.Collect(), that's misused virtually 100% of the time anyway. Now THATS the platform we need. A super dumbed down POS that attempts to prevent morons from doing moronic things. Oh wait, we've already got one of those, I think it's called Javascript.
When they announced Silverlight 1.1 Alpha with the .net framework, I was really excited. I thought, wow, I can FINALLY do real programming. I would no longer be crippled by stupid annoying constraints or waste hours and hours working around retarded browser incompatibilities. Silverlight was going to be a REAL platform. Unfortunately, now it's looking like you guys are starting to dumb it down so that the average html weenie can't hurt himself.
By
Anonymous, at July 24, 2008 at 12:17 PM
From a business persective, the predominantly async model is a significant hindrance, as it may result in significantly increased development costs and delivery delays. When in question, it's best to let developers determine the most effective approach given their needs rather than imposing your view of what's best for them.
By
Anonymous, at July 24, 2008 at 3:14 PM
i like events, especially those party events with a lot of girls :D
Events are really revolution! Gopd bless events creator
By
Anonymous, at July 25, 2008 at 5:47 AM
While I can see that some people think it's a bit too paternalistic to make the choice for the developer, I like the fact that you push for the async model. I come from a webprogramming background and I only have limited experience of the async model in ajax apps, so yes, it was at first a hindrance for me to make my requests async. It held my progress back for like 30 minutes until I got the hang of it...
By
Anonymous, at July 27, 2008 at 4:53 AM
I've learnt to accept the async world we now live in. THOU i dare say that it will only get worse in a couple in a years time when we have parallelism engrained in our apps. We as humans don't naturally think this way thats why it will cause alot of pain for most developers.
Personally Ive encountered numerous situations that have required a sync model and have had to build my own queue mechanism to manage async calls. In time a common set of patterns and frameworks will arrive that will make this easier BUT for now I've had to write alot of spagetti code to fake Sync style calls.
If all the Midori rumours surfacing on the web are true then I can understand why MS want's all of us to go async.
By
Anonymous, at July 31, 2008 at 9:17 PM
Hey ashish very good blog and good technical knowledge by u .
I am really very much amazed with your technology understanding
I have also implemented my project as a social networking website
in java jsp
https://www.fabgabs.com
Keep it up with ur projects
we young indians will make every indians proud
By
Anonymous, at September 10, 2008 at 10:28 AM
Post a Comment | Home | Inference: my personal blog