“OpenSilver is a plugin-free, open-source reimplementation of Silverlight”

JAXenter: Thank you for taking the time to answer our questions. First things first: What is OpenSilver? Can you tell us a little bit about the project and what it accomplishes?

Giovanni Albani: OpenSilver is a plugin-free, open-source reimplementation of Silverlight that runs on all modern browsers. The whole project and idea behind OpenSilver starts when Silverlight died in 2011. We think that Silverlight was a great concept and technology with a few evident drawbacks, and in that context OpenSilver is aiming at correcting these drawbacks to build upon the foundations of Silverlight. We are contacted by people who spent their careers developing apps over decades on Silverlight, and we aim to help them and other .NET developers have an alternative without rewriting and throwing everything away.

OpenSilver wants to be the modern version of Silverlight, based on a community of developers and making use of modern features.

JAXenter: What’s under the hood? How does it work and what can it run on?

Giovanni Albani: Silverlight had two main components: the SDK for the devs and the plugin for the user. OpenSilver only has the SDK, as the plugin is no longer required.

To understand how OpenSilver works, we need to talk about Blazor and WebAssembly. Blazor is powerful and is ideal for .NET developers but it still doesn’t allow use to only use .NET to build web apps, you still need to write HTML and CSS. OpenSilver builds a XAML layer upon Blazor and makes it a full .NET stack.

Instead of using a plugin, the output of OpenSilver is in WebAssembly, an open W3C standard which allows a plugin-free technology in the browser. The files with a .wasm extension are recognized by default by browsers, just like any .png or .jpeg would.

Ultimately, OpenSilver runs on every browser (as it uses a standard browser technology) and all platforms capable of displaying a browser: iOS, Windows, Android …

SEE ALSO: Why you should consider a Databaseless architecture

JAXenter: As Silverlight nears its end of support date, what should developers do to prepare? How can someone migrate to OpenSilver?

Giovanni Albani: As Silverlight nears its end of support date, developers should prepare by looking at their options: either rewrite with a web technology or use OpenSilver to keep the existing code and further build upon that.

Migrating with OpenSilver consists in recompiling the app from the source code and replace the Silverlight references with OpenSilver. Here are the steps we follow when we migrate an application for a customer:

1. To convert a project, we analyze the XAP files first and identify what is currently not supported by OpenSilver in the app.
2. After the XAP analysis, we recover the source code from our customer and start with the environment setup on a local developer machine. We then create OpenSilver projects and copy the legacy projects inside to recreate the original structure.
3. The next step is fixing all the compilation errors. Errors are of 2 types: they are either unsupported third party libraries, or Silverlight APIs not yet implemented in OpenSilver. To make the code compile, we repeat the steps above for third party libraries source code: create OpenSilver projects and copy the source code inside, then we reference them to the client’s project. At this point we do not implement unsupported features; we use stubs and make the code compile properly.
4. Then we setup client-side and server-side communication and move on to implementing the unsupported features and debug the ones that behave differently from the legacy app. Some browser sandbox limitations also force us to make occasional changes to the client code, such as “Open File” dialog being necessarily asynchronous in the browser, whereas it could run synchronously in Silverlight.

We are working on integrating all the functionalities from the Silverlight API. Migrating can be done by developers themselves, finding workarounds for unsupported features. If they can’t or get stuck, they can ask the OpenSilver team to prioritize the implementation of features they need, just like we do with the migration of entire apps.

JAXenter: Will all original application features be kept after migrating?

Giovanni Albani: Yes but it might need some work.

First of all, the browser has its own limitations due to the browser’s sandbox. It limits the access to files on the disk, and you can only “Open” a file or “Save as”. Silverlight had the same limitations, but they could be bypassed.

However, this makes OpenSilver much more secure than Silverlight as WebAssembly uses the browser’s sandbox and not a plugin. For example: “Open” is synchronous in Silverlight, and asynchronous in the browser. Or a web app cannot force the display of a “Save as” dialogue, because it is handled by the browser, not the app.

Then you have third party libraries. When they exist in .NET standard, all we have to do is to reference them. If not, we can recompile them with OpenSilver if we have the source code. In the case we have neither a third library in .NET standard or the source code, we replace that library with another one, in which case we face the same issues as we would if we were rewriting the application: UI differences, etc…

Finally, features we do not currently support can be worked around, but they would look or feel different than if we implemented them in OpenSilver.

JAXenter: What was Silverlight used for exactly? Where did it excel, and what drawbacks did it have?

Giovanni Albani: For consumers, Silverlight was mainly used for video media with smooth streaming and DMR, or ad banners on website. However, it was used by companies to develop internal, line-of-business apps in a controlled environment. The incredible productivity and the speed at which you could create an app was unmatched, and it solved a lot of the deployment issues you had with desktop applications. It had all the advantages and none of the drawbacks.

It was also very convenient for a company to work with Silverlight as the dev team could be built around .NET and Microsoft skills to facilitate integrations with other Microsoft technologies like ADFS.

At the time, Silverlight had superior performances compared to JavaScript, a superior programming model, superior compatibility because the browser landscape was fractured, and superior UI features and implementation rate.

In terms of drawbacks, Silverlight had security issues due to the use of a plugin. Since the plugin was out of the sandbox, it had full access to the disk via Windows and could be prone to security breaches. This is now fixed thanks to WebAssembly.

Silverlight also never really had support for Linux or other platforms. It was proprietary, hence dependent on Microsoft and its politics as well as dependent on a non-standard technology (plugins) which meant that a decision of abandoning plugins from the major browsers would also mean the end of Silverlight.

SEE ALSO: Please stop sharing your private keys

JAXenter: Congrats on the beta release! What’s on the roadmap for the future?

Giovanni Albani: Thank you!

We plan on supporting 100% of the API, and then support additional technologies such as VB.net, LightSwitch and WPF. Silverlight was actually named WPF/E in its early phase as it is a subset of WPF. WPF is still very used for Windows applications. Our plan for the future is to bring the Silverlight community together, maintain the ecosystem and make it grow over time, offering new ways of building web apps to .NET developers. After that, we just want to keep building upon the foundations to push the technology even further.

JAXenter: Now that Adobe Flash has reached its end of life, do you worry about lost media? Just as we lost many Flash web applications that never received a backup, will we lose many Silverlight applications?

Giovanni Albani: Silverlight applications do not really disappear because they were used in companies’ internal environment. Even though the app is rewritten in another technology, it still exists after a company moved on to a web based technology. What is lost is the skills and knowledge of the developers, and the decades of investment in Silverlight for large LOB apps: man-hours wasted and source code left to die. But the app itself is most likely not deleted, companies tend to keep what they developed even though they’re not using it anymore.

There is a real impact however for companies with customers in the health-care industry or security sensitive industries for example, as rewriting can be longer and more difficult than expected. As the deadline is getting closer they need a quicker way to keep using their legacy app, and most of the time migrating to OpenSilver is faster.

OpenSilver 1.0 is available for download at: https://www.opensilver.net

Source code: https://github.com/OpenSilver/OpenSilver

The post “OpenSilver is a plugin-free, open-source reimplementation of Silverlight” appeared first on JAXenter.