Many ideas in software engineering can be described as “so crazy they just might work.” And then others are just plain crazy.
At first glance, OpenSilver, a new open-source implementation of Microsoft’s shuttered Silverlight platform, seems to belong to the crazy category. But at second glance — well, not much changes.
A very brief history of Silverlight
Silverlight was a plugin-powered framework for building browser applications, much like Flash. Microsoft released the first version in 2007, which is a century ago in internet years. At the time, Google hadn’t even released their Chrome browser. Flash was everywhere, except iPhones. (Forget iPads — they didn’t exist yet, either.)
Silverlight began its life as an almost-accidental offshoot to Microsoft’s WPF technology. WPF was all about building graphical Windows applications, but Silverlight took the same user interface model and wedged it into a browser. It took plenty of WPF developers along with it. (I was one.)
Despite Silverlight’s poor reputation today, most Microsoft developers were excited when it first appeared. No one really needed a Microsoft-built Flash competitor, but Silverlight filled an important gap in WPF. It gave developers a way to create rich client applications without needing to worry about deployment and setup issues. Sweetening the deal was the fact that Silverlight worked on most Mac computers, which was unheard of at the time.
The most exciting part of Silverlight was its fast pace of change. By 2011, Microsoft was already releasing Silverlight 5. It ported over a boatload of useful features from WPF, including data grids and 3D graphics. Then the party came to an abrupt stop. Microsoft deprecated Silverlight, and loyal developers were once again furious at the tech behemoth.
The gap between the native web and plugin-based applications closed. And once it was possible to build browser applications without a plugin (however painfully), all plugin technologies were on borrowed time.
Silverlight was officially deprecated in 2012 (although its end-of-life date, when it loses all Microsoft support, will be in 2021). But seeing as Silverlight development ground to a halt almost a decade ago, a new technology that supports it is an unusual choice. But here we are, with OpenSilver.
OpenSilver’s claim to fame is that it avoids Silverlight’s critical weakness: the plugin. OpenSilver doesn’t need one, because it’s built on a pile of new and emerging technologies, like a Russian Doll of tech.
That’s where OpenSilver comes in. Technically, it’s a reimplementation of Silverlight using WebAssembly. But it doesn’t start from scratch (because that would be too difficult and buggy). Instead, it piggybacks on Blazor, Microsoft’s next-generation framework for building single-page C# applications that run in the browser. All modern browsers support WebAssembly, and so they can also use Blazor, which means they can also run plugin-free OpenSilver. It’s a long road that leads through two new technologies to get back to a really old one.
It’s painfully clear that OpenSilver is still a work in progress. If you visit the OpenSilver showcase page, you’ll find real Silverlight demos running in the browser sandbox with no plugin, just as promised. But you’ll also find some missing features, including some — like 3D support — that may never appear. OpenSilver currently has about 60% coverage of the Silverlight libraries, but it has ambitious plans to include all the most commonly used bits, including the popular package of controls from third-party developer Telerik. (Nice!)
But OpenSilver is also slow. The sluggishness is noticeable enough to warrant an angry red disclaimer on the showcase page, promising faster speeds in the near future. But it’s hard to fault OpenSilver for its performance shortcomings because it’s built on Blazor, a technology that won’t be finalized until late 2020. When that happens, the maintainers of OpenSilver expect its speed to increase by a factor of 30.
Does any of this make sense?
Microsoft has a history of creating ambitious new technologies and then sidelining them, leaving a wake of frustrated developers behind. But when they returned to the world of browser-based applications with client-side code, it seems that Silverlight example was still on their minds. Microsoft could have used WebAssembly and the expertise they acquired from Mono to build a new version of Silverlight. But instead, they decided to create an entirely new application model that closely follows their popular sever-side technology, ASP.NET Razor. And that decision makes sense. While it’s still too soon to know if Blazor will live up to its early promise, it clearly delivers on speed and ambition.
Some developers have floated the idea that OpenSilver could evolve into an alternative to Blazor — in other words, that developers who happen to prefer the WPF libraries and the XAML markup model can use OpenSilver as a personal preference. This seems unlikely in the extreme. Never mind the performance concerns about the extra layer, it’s almost impossible for a framework to get traction with Microsoft developers if it isn’t explicitly supported by Microsoft. (See, for instance, the Uno platform.) Even the excellent muti-year Mono project, which was endorsed by Microsoft, never took off with the business world until Microsoft bought the company and incorporated its ideas into other products like Blazor.
So what problem is OpenSilver trying to solve? If it’s a way to run old and abandoned Silverlight applications, that’s a small but useful niche. But if it’s intended as a tool for extending the life of old business applications, that’s shakier ground.
If OpenSilver had appeared eight years ago, it would be a lifeline to companies that had invested in Silverlight and were feeling around for ways to keep using their legacy applications. But now, the world has moved on. If there are companies that have spent nearly a decade clinging to a deprecated technology with serious limitations, perhaps OpenSilver will be a viable last resort. But the odds are good that there will be more work migrating, recompiling, and patching missing features. If you’re one of the very few people in this situation, waiting for a signal, then here it is—now is the time the move on. And I say that as one of the few developers who will admit to liking Silverlight a decade ago.