The post OpenSilver and The Return of Silverlight appeared first on Kill All Defects.
How an Open Source implementation of Silverlight aims to use Web Assembly to Compete with Blazor and Modern JavaScript Frameworks
OpenSilver has recently made its presence known and announced that Silverlight, like disco, is in fact not dead and is still more relevant than ever – albiet in a fairly changed form.
As a former Silverlight developer and XAML specialist, let me lay out for you what Silverlight was, how OpenSilver is different, and my initial take on whether this matters (and who it might matter to).
XAML and The Foundation of Silverlight
If you’re like many new developers I speak with, you may not be familiar with Silverlight or even XAML, so let me set the stage for you.
Back in 2006 Microsoft released .NET Framework 3.0, including a new desktop technology called Windows Presentation Foundation (WPF). WPF was (and is) an extremely powerful way to build and customize desktop user interfaces. It addressed many of the issues with Windows Forms and aimed to build a user interface technology centered around something called XAML.
XAML stands for eXtensible Application Markup Language and was a way of building a user interface in a tool-agnostic format based on a superset of XML, so designers could work with XAML in one tool and developers could use another.
WPF was a hit and its technologies made for an amazing development experience that still continues today with WPF being supported in .NET Core. Numerous other technologies have adopted XAML for their user interfaces, including Silverlight, Windows Phone, Universal Windows Platform (UWP), Xamarin, Uno, and potentially a few others I’m forgetting at the moment.
The Rise and Fall of Silverlight
Silverlight rose as a way of taking WPF’s rich application capabilities and applying them to applications hosted inside the browser.
At the time JavaScript frameworks were in their infancy, ASP .NET was transitioning from WebForms to MVC / Razor, and there wasn’t a great solution for web applications that needed to do a lot of client-side logic.
Instead, browsers relied on plugins such as Flash and Silverlight to deliver these rich capabilities to end users. This relied on individual browsers to support plugins and to continue to support them.
Unfortunately, plugins constituted security vulnerabilities and slowed down the browsing experience for end users so browsers, starting with Chrome, discontinued plugin support.
With the announcement that browsers would no longer support Plugins, Silverlight became a very expensive investment for organizations that had developed applications in that framework as they now had a fixed point in time when they would no longer run for end users.
This effectively stopped future Silverlight development and set plugin-reliant communities such as Flash and Silverlight into a search for something new.
The Rise of Single Page Applications
The lesson learned with Silverlight’s demise was not to rely on capabilities not inherent in established web standards. That meant that if you needed to do something creative at the client-side level, you needed to do it in JavaScript.
This sudden boom in applications that needed to be rewritten in JavaScript poured fuel onto the early JavaScript frameworks and essentially started an arms race between Angular, React, Vue, and others as web developers searched for the best frameworks to adapt their existing code to and the best ways to build new applications.
Author’s Note: I moved from Silverlight to Angular and loved it. React works well from folks coming from a MVC codebase, but Angular was well suited to MVVM architectures.
Web Assembly and Blazor
Web standards grew and matured and we actually had a – gasp – stable set of established JavaScript features that didn’t suck to work with when ECMAScript 6 came around.
With the maturity of web standards came the arrival of Web Assembly and a new wild west of development that is still in the early days of playing itself out.
Web Assembly is essentially an assembly language for your browser that effectively allows you to do client-side web development in technologies other than JavaScript.
The promise of Web Assembly is similar to the promise of Silverlight: If you don’t want to work with JavaScript, you don’t have to.
One of the early contenders in the Web Assembly arena has been Microsoft’s Blazor technology which aims to have .NET assemblies running in the user’s browser. This technology has just reached the early stages of maturity and adoption and it’s an exciting space to watch for .NET developers.
Unlike Silverlight, Blazor is built on established web standards and also focuses on using MVC / Razor style syntax instead of XAML.
OpenSilver and the Return of Silverlight
Yesterday the OpenSilver team announced OpenSilver and a way of running Silverlight inside of modern browsers.
How is this different than Silverlight?
To be clear: this is not Silverlight. This is, in fact, a re-implementation of Silverlight that uses Web Assembly instead of browser plugins to achieve its goals.
This means that OpenSilver plays by established web standards and will work with browsers that support them. Under the covers, OpenSilver appears to do a lot of the same things that Blazor does, with Web Assembly and Mono.
Silverlight is also significantly more mature than OpenSilver for obvious reasons given the recent unveiling of OpenSilver. OpenSilver is notably lacking ahead of time compilation and significant tuning and additional patches, though these should come over time throughout the rest of 2020 and into the future.
How is this different than Blazor?
Well, for one it uses XAML instead of Razor syntax for its views. This means that if you have a heavy background in XAML or investment in XAML code from Desktop, Xamarin, or deceased Silverlight applications that you may be able to get these applications running in OpenSilver much easier than if you were to do a rewrite in Blazor or a complete port to a JavaScript framework.
Less positively, Blazor is backed by Microsoft’s full power and force, OpenSilver is not. This means that it’s not guaranteed to get the same level of tooling support and treatment that other dialects of XAML and other .NET technologies get. That’s not to suggest malicious intent, just that it’s potentially less of a priority.
Does this Matter?
Okay, so OpenSilver isn’t Silverlight, but lets you do the same types of things with XAML you could with Silverlight. It doesn’t have the same plugin weakness that Silverlight did, and it’s still getting better. But does it matter?
The answer to that is the same as any new technology: it depends.
If you’re a .NET shop with a significant skills or code investment in XAML, it absolutely matters.
If you’re a team that’s more comfortable with MVC / Blazor or existing single page application frameworks, then OpenSilver matters significantly less to you.
With OpenSilver still maturing and with missing pieces like ahead of time compilation you won’t be writing production code with OpenSilver anytime soon. However, this early adopter stage doesn’t mean you shouldn’t watch and consider OpenSilver.
Helpful links for getting started:
The ability to write code in one place that runs in many platforms is the prize we’ve all sought after for decades since the invention of the internet. OpenSilver is the latest contender in this arena and it won’t be the last, but it is absolutely worth watching.
Top comments (6)
I had always thought Silverlight was great! That is, until MSFT capitulated to Apple's no plug in rules.
MSFT should have ignored Apple and continued to improve. Instead, they threw the entire Silverlight community under the bus.
It is for this reason alone I no longer trust MSFT and reject all Frameworks based on past projects.
I say 'just bite the bullet and learn Angular and CSS'.
Blazor/Razor are ok but 10 years behind the Javascrpt eco system. I don't see them catching up unless MSFT throws in serious development effort.
To be fair to Microsoft, they didn't have a huge choice in the matter. Chrome got such a high degree of adoption that Google could do what they wanted.
From a Silverlight dev's perspective, a lot of the appeal of Silverlight was that it could run on a mac and it ran in browsers folks already used. Microsoft would have had to restrict web traffic to certain browsers in order to continue to improve the technology. Getting traction is a war they likely wouldn't have won.
I understand not trusting Microsoft on some things. Their track record on upgrading the view layer in particular is rough, but .NET is fantastic as a back-end service for single page applications as well as general API systems.
And yes, I highly recommend Angular, Vue, etc. for front-end logic.
WASM-based projects are inherently going to appeal primarily to only a subset of the web development ecosystem.
Still, it's an option and an interesting one.
And we haven't even mentioned the fractured MSFT desktop world! :)
Oh yes, their infamous IE brand of browsers were a disaster!
What fracture?
I make references to it in my description of XAML dialects. We have WPF and UWP on Desktop plus Xamarin adding some complexity as well.
The day after writing this, I have a few additional thoughts: If OpenSilver interests you, check out Uno, which offers a greater degree of maturity, but Xamarin integration so larger degrees of cross-platform support (at a cost of higher complexity). Both are on the bleeding edge and not ready for real usage yet, but both are interesting uses of XAML technology reliant on Web Assembly and modern web standards.