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
