Silverlight: Does the new path lead to the end of the road?
July 31, 2012 —
(Page 5 of 7)
Related Search Term(s): Microsoft, Silverlight, XAML
When Silverlight started, it was actually initially referred to as WPF/e. It was meant to allow WPF capabilities “everywhere,” but the features between parent and offspring diverged such that while there were always assumed to be things that WPF could do that Silverlight would not, there became a whole mass of things that Silverlight enabled that never found their way into WPF.
The ironic aspect to the speculation about Silverlight’s demise is that it replaces the speculation that WPF was being abandoned as it did not enjoy the rapid release schedule that Silverlight was pursuing. In Scott Guthrie’s blog post announcing Silverlight 5, he mentioned that the improved data binding would help with WPF convergence, but it does not help with the aforementioned features that Silverlight already has but are absent from WPF.
There is no reason to believe that anything untoward was planned with Silverlight that led to these convulsions along the way, but they do complicate decisions about when Silverlight is the best choice and when it is not.
Insulating against disruptive tech
Developers love new technology that makes solving previously hard problems easier. The price to be paid for this constantly evolving palette is high if solutions are not architected in such a way as to mitigate the risks. A common thread in my discussions with experts on the topic was the need to use architectural design for the solution to insulate against changes.
Next Version Systems’ Hollis recommended that you “ensure that your application is properly tiered, so that it can support any sort of interface or device it will need to support, including multiple presentation tiers. That primarily means good service design and a bias toward asynchronous operations.”
In light of the fact that the lifespan of presentation technologies is not as long as it has been in the past, he went on to suggest that presentation-tier decisions be put off as long as possible, lest the assumptions early on about the presentation tier haunt the design. He explained, “We have traditionally expected our presentation-tier solutions to last more than five years, but since no one knows what we’ll really need in five years, I recommend shorter time horizons: two to three years.” Even HTML5 is not a guaranteed safe bet against presentation layer fatigue.