There is a great deal of interest and concern in where Silverlight is going next, so much so that in most of the conversations seen across developer communities, the question has turned to whether there even will be a next round for Silverlight.
Some have said that it does not matter, that Silverlight is a powerful tool and serves a great purpose. It has become very popular in areas such as media streaming and Windows Phone development, for example. The logic for this position goes that Microsoft needs to keep the problem that Silverlight solves solved.
Maybe in this case we can say that the solution is in the eye of the beholder, but now, even though most of the facts of the case have been revealed since the controversy started last year, there is still a great deal of disagreement as to what it all means for developers that have elected to plunge into using Silverlight and those thinking of using it for upcoming projects.
To untie this knot, I talked to several enterprise development experts, including Billy Hollis, co-owner of Next Version Systems and author of Pluralsight’s new course on user-experience design. I asked him what he would advise someone who was on the fence about building a solution with Silverlight. He said that he often hears this question, but in his experience, what people are really asking for is what the safe choice is from among the many technology choices available for developers.
For a short answer, Hollis offered that there is not a safe choice because the game is rapidly changing, especially among presentation technologies. He went on to explain that with cloud, touch and numerous other new technologies disrupting the development ecosystem, “no one can predict what things will look like even five years down the road.”
The upshot of this is we must seek to use what works, and we will be best served if we follow some rules that insulate solutions from the changes in the landscape. We will go into some of those strategies later in this article, and endeavor to take some of the hype out of this controversy. The scariest aspect could well be that the crazy pace that we have tried to survive at for the last 20 years may actually be accelerating in precisely the places that will make life hardest for those that have to make decisions about which technologies to use.
Why Silverlight matters
Silverlight was initially introduced in 2007 to serve as Microsoft’s rich Internet application (RIA) platform, and it eventually expanded into niches beyond building RIAs for corporate line-of-business solutions. It has become popular for streaming media for everything from technical training to the Olympics. Finding this special niche has also helped to shape the nature of new features that have evolved in Silverlight.
From the very beginning, Silverlight was to be a strategic play to fill a void in Microsoft’s coverage of developer technology needs. Silverlight introduced Microsoft’s answer to a very real problem that developers had to choose between two extremes, namely native client development or Web development.
Native client development on Windows at the time primarily consisted of building Windows Forms applications or resorting to C++ development. The advantages of native clients include robust access to the underlying hardware systems such as the graphics systems and file system. There is also a standard rendering with no concern for browser versions and such.
The weakness of the native client is limited reach. If an organization needs to allow clients other than Windows, or even just needs to allow the use of the system outside the organization, then installation is either impossible or at least problematic.
Web development does not suffer from the deployment problem of native clients, but introduces a whole raft of other issues in addition to the fact that, over time, browser support makes for a moving target if you really need a consistent experience and care about the solution months after it is initially released.
The concept of a middle ground that solved the problems of both extremes fostered greater interest in plug-in technology and ushered in a surge of interest in Flash development. Not to be left out, Microsoft introduced Silverlight and indicated it would provide an aggressive release cycle from the outset. Silverlight provided an environment to develop a rich Internet application that promised to provide the best of both worlds and to push the drawbacks away.
This was a compelling proposition, provided Microsoft could make the underlying plug-in technology ubiquitous. At the time, Microsoft Internet Explorer enjoyed massive market share, which made possible the assumptions that Silverlight might get bundled with the browser, or would be mass-deployed through some other vehicle only available to Microsoft.
Fast-forward to about a year ago, and there was a very different landscape, with fears for the future touching virtually every contemporary development technology, save C++, which was promised a renaissance. Assertions were made that .NET was dead, that Silverlight was dead, and that Windows 8 would break with the past and render all software previously developed unusable. Today, we know that .NET is not dead, that Windows 8 has full support for .NET and Silverlight via the desktop, and that there is a new platform within the platform in the form of Metro.
Microsoft’s failure to comment on Silverlight’s road map beyond Silverlight 5, and questions about the role of Metro, are the primary sources of the continued sense that Silverlight will not see a version 6. This has to be very frustrating to Microsoft, since even releasing a new version of Silverlight has not quelled the storm. Silverlight 5 came out in December 2011, and yet the conversation continues.
To the best of my knowledge, Windows 8 desktop will not include Silverlight 5—or any other version of Silverlight—out of the box. While I understand the mixed message including it would send, since Silverlight is not enabled in the Metro side of Windows 8, I cannot help thinking that this would diffuse much of the fear, uncertainty and doubt that is currently circulating.
When Silverlight makes sense
If you look at Silverlight not as a specific tool set, but rather as a vehicle among several for delivering a XAML-based experience, then the path forward is clearer. Russell Fustino, senior developer evangelist at ComponentOne, said, “To me, it is very clear that XAML is here to stay. So, with one skill set, developers can develop for all of these different platforms, and Silverlight is just one slice of it.”
HTML5 has been embraced, to an extent, by Microsoft, but HTML5 is not a panacea and it is not ready to displace other tools in the area of rich Internet applications.
The threat of Metro to Silverlight relies on a specific flow of events. WinRT on Windows 8 has much promise, but betting on WinRT is still a gamble until it proves to be a platform that the market chooses. Even if that happens, it will be years before targeting WinRT brings a majority audience, and there are many assumptions built into that result ever coming to pass.
If your application does have to target WinRT eventually, then Silverlight is an ideal holding action. Virtually everyone who has dug into XAML of WPF, Silverlight and WinRT agree that Silverlight is closer to the WinRT variant of XAML than WPF. Next Version Systems’ Hollis observed that his customers “prefer WPF to Silverlight for internal corporate desktop app development by about 2 to 1. Silverlight tends to be chosen when great user experience is needed, but there’s less control over the machine or more geographical reach.”
There have been some serious twists in the road between the first version of Silverlight and the latest release of this past December. For example, I am not alone in my opinion that the “out of browser” capability seems to fit a square peg in a round hole. If you do not want to run inside a browser, then why not just use WPF rather than Silverlight?
As new versions of Silverlight were released, features have crept in that do not work across all platforms. For example, the new 3D graphics capabilities in Silverlight 5 rely on DirectX and are Windows only. This and other features like it seem to fly in the face of the main selling point of Silverlight: the ability to deliver a consistent experience across multiple platforms.
Finally, there is the version of Silverlight that is used for developing Windows Phone 7 applications. It is really not full Silverlight, so it stretched the brand and confused developers. Now that Windows 8 will be the core of Windows Phone 8, it is not fully clear where Silverlight fits in the phone development strategy. Perhaps the short answer is that is does not fit anymore.
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.
Hollis provides his formula for insulating against these kinds of disruptions at the presentation layer. He said that you should “get a strategy for building a navigation shell in place very early. This is, more or less, the analog of what MVC does for websites, but in Silverlight, the navigation shell normally works on the client machine. There are several choices out there to use as starting points, and all of them will need additional work to fit an organization’s needs. Getting an appropriate shell in place improves user experience and speeds up development all through the process.”
ComponentOne’s Fustino said he also believes design is the key to surviving the tides. “The great data-binding in Silverlight allows developers to easily separate the display logic from the business logic and create more maintainable applications,” he said. This separation of concerns is something that has been advised often in the past and is more important now than ever.
Fear and future versions
Even before Windows 8 was announced in September 2011 at the Build Conference, the developer community and blogosphere were buzzing about the hints that Metro and the new XAML development were the beginning of the end for Silverlight. The fear persists even after Silverlight 5 was released.
Microsoft has already released an update to Silverlight 5 in the form of a patch. The 5.1 patch does not add new features or capabilities. The conspiracy theory crowd has pointed to this as proof that there will not be a version after Silverlight 5, since many of the items fixed in the patch could wait until a service release. In light of recent displays of near-perfect secrecy, it is more likely that either Microsoft is keeping its options open in this regard, or it does not want to provide clues.
Time will of course tell if Silverlight 5 finds its stride. It is still early, but a bellwether I consider worth watching is the showcase of applications at Silverlight.net. If you look at the Silverlight 3 applications submitted, you will see there are only a few (literally three when last I looked). The Silverlight 4 showcase is bursting with applications. As of this writing, more than six months beyond the release of Silverlight 5, there are no applications listed.
I confess to not knowing how long the process takes, but I think it is safe to say that this is a symptom of the fear rather than proof that the fear is well-founded. The counter-evidence to this last point is that component vendors, including ComponentOne, Infragistics and Telerik, are all investing time and energy into their Silverlight tool sets, including updates for Silverlight 5. Fustino told me that since the merger of GrapeCity with ComponentOne, they are now providing Silverlight versions of their ActiveReports, Spread and ActiveAnalysis products, which definitely show they are not sitting Silverlight 5 out.
Finally, as you dig into the code of some of the new features, there are indicators that Microsoft has left the door open to future versions. For example, there are values for the MediaCommand Event that are currently not supported, but according to a blog post by Microsoft’s Pete Brown, “Those commands are reserved for potential future support.”
Yet there remain just as many reasons to believe that Silverlight 5 is the last full version of Silverlight we will see released. In the final analysis, it probably does not matter, since Microsoft is not orphaning the XAML skills of Silverlight developers. While we have seen Microsoft orphan developer technologies in the past, there is a long tail of developers still using some of them and still benefiting from extended support. After all, we still hear of Visual Basic 6 being used for development though it had been “orphaned” many, many years ago.
The better question may be whether Silverlight is complete enough to be useful without future releases, and I think the answer is clearly “yes” for many media scenarios. As Fustino put it, “According to Microsoft, Silverlight will be supported for at least the next 10 years, so even if there are not any new major releases, it’s not going anywhere and it is rock solid as is.”
The lack of a delineated road map by Microsoft for Silverlight could be an ominous sign for many who crave new capabilities, but it’s more likely that Microsoft just does not yet know what role Silverlight will need to play once Windows 8 has been finally released and realizes its full potential market (or fails to realize a sufficient market share). Silverlight could very well be part of plan B in the grand scheme of things for Microsoft, or perhaps it thinks the features delivered in this latest round polish off the major things missing from Silverlight.
Only time will tell, but I think it is a mistake to assume to know for sure where things will go when Microsoft itself likely only hopes to know where the path will lead in its quest to once again dominate the developer landscape.
