Matt ElandThe 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.
