Implementing The Functionality Of A Large Silverlight Application In New Technology – Part 1 – Technology Choices

The challenge

Optimium Health delivers and supports a workflow guidance tool. The tool is composed of multiple servers performing such functions as document production, eFax generation, eMail generation, and on-demand report support. An additional component is the user interface which is used both by end users and system administrators. The user interface and the product is referred to as Optimi$er.2012.

The environment of the server is Microsoft Windows Server and the user interface is a Microsoft Silverlight application hosted in Internet Information Services (IIS) and deployed in Microsoft Internet Explorer. Silverlight enjoyed great popularity particularly for video streaming (2008 Summer Olympics in Beijing, 2010 Winter Olympics in Vancouver, 2008 political conventions, Amazon Video & Netflix [Source: Wikipedia]).

The Adobe Flash plugin dominated and was subject to many security breaches. This was the genesis of a movement away from browser plugins. Microsoft announced in July 2015 that Silverlight End Of Life (EOL) would be October 12, 2021.

Replacing a large application with an extensive user interface with backing logic became a strategic concern but not one that overrode the necessity of enhancing and extending the Silverlight client.

Initial technology candidates

An initial survey of browser client technologies performed in 2018 resulted in a dismal set of options.

AngularJS was a client library written in JavaScript that was initially developed in 2009; Although still supported, it was superseded by Angular. AngularJS and JavaScript were deemed too low level with primitive tooling, a type unsafe environment, and lowering popularity due to the release of Angular.

Angular V4 was the latest in a TypeScript rewrite of AngularJS. Tooling was still relatively primitive but at least the language was type-safe.

Aurelia was a new Typescript library favoring convention over configuration. It had no track record as a useful library in actual use however, the creators had a successful previous library (Durandal) and were bent on radically improving the implementation.

Uno platform was released in early 2018. It was a multiplatform tool supporting Windows desktop, Android, iOS, and web browsers. Developed as an internal tool at nVentive, it was later open-sourced.

A choice is made

A decision was made in early 2018 to prototype a client replacement with Angular V5. Basic functionality was created. Data support was a large ‘sticking’ point with the conversion from the C# types supported by the server and the JavaScript types.

There was enough “friction” between the language types to make the examination of other frameworks continue. The plan at this time was to build a minimally viable client during 2019 that addressed one of the four major areas of functionality.

A dark horse appears at the end of 2017 and beginning of 2018

A series of blog posts on the Microsoft Developer site appeared at the end of 2017 and into 2018. These posts detailed an experimental technology (called Blazor) which would bring the .Net environment to the server. This was pretty exciting in that it would remove the ‘friction’ between client and server in much the same way as Silverlight did more than a decade earlier. The major difference was that no plugin was required and the execution could be upon and modern browser (Google Chrome, Mozilla Firefox, Microsoft Edge).

A prototype client was developed and followed the pre-release cadence of the experimental Blazor implementation. The prototype quickly surpassed the Angular prototype in functionality and reliability.

Microsoft emphasized the experimental nature of Blazor throughout 2018 and it wasn’t until October that a full commitment to Blazor was announced. The commitment was to ship the server hosted model of Blazor by the end of 2019 as of October 2019. Blazor became an official part of .Net 3.0 preview 4 in April of 2019.

Switching horses midstream and initial implementation

After the commitment by Microsoft the decision was clear that a Blazor client was to be the preferred technology. The initial implementation would be of the OR Tracking application (a new facet of Optimi$er). The intent was to improve communication and safety of the intra-operative processes.

Optimium Health and a large hospital group partner iteratively developed the tracking application through most of 2019 with a goal of live implementation in Q1 2020. The development process was smooth and we were ready to perform the initial implementation in March of 2020, calling the product Optimi$er.2020;


An odd thing happened while getting ready to implement, that being a global pandemic of a seriously deadly virus with the moniker of COVID-19. All plans for implementation of the OR Tracking application got put on hold while everyone tried to ascertain how to live safely in this new environment.

Finalization of the replacement application

After several months of being stopped in the implementation of the OR Tracking application, the remainder of 2020 and first half of 2021 was devoted to transitioning the Pre-Anesthesia and Surgical Office portions of Optimi$er.2021 (renamed from Optimi$er.2020 because we wanted nothing to do with 2020). The first preview release of Optimi$er.2021 occurred in July. A full transition in two of three departments occurred in October with the third department expecting to finaliz

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.