Silverlight is dying

Brian Minert, Steve Hanka and I were on our ritual lunch walk when Brian asked me, "How do you like programming in javascript?" 

"I like it just fine", I responded. "It's just another programming language".

"And you're a programmer" he replied.

I am a programmer I thought, and as a programmer I can pick up any programming language and begin producing quality software.  It shouldn't matter what programming language I'm using.  I can wield that language.  After all I was picking up on how to use javascript rather quickly.  In just two weeks I had researched out various programming techniques with javascript.  I knew how to create custom objects, simulate inheritance, and make asynchronous calls back to the server.  I knew how to serialize objects to JSON, and I knew how to manipulate the DOM.  Not bad for someone whose only professional software experience was with C# and C++.

I had been given the exciting task of porting our call center agent client software, written in Delphi, to a thin agent that ran in the browser.  The criteria for the thin agent was rigorous.  The thin agent needed to let the user make outbound calls, transfer calls to other agents, and create conference calls.  In addition it needed to let the user know when a call was coming inbound.  In fact it needed to let the user know right away, and a delay of a few seconds was unacceptable.  The thin agent was supposed to be the user's interface into our call center platform, and it's a big platform.

As time progressed I was able to make good progress on the thin agent.  Making outbound calls was easy.  Notifying the agent about inbound calls was substantially more difficult, but under the direction of Shane I was able to get that working.  I began the work of displaying other pieces of real time information.

Displaying real time information was painful.  We had chosen to display this real time information in a grid like fashion, and we chose to use HTML's table for the grid.  The HTML table is a poorly crafted and often abused tag in HTML to begin with, but dynamically adding rows to an HTML table multiplies the convoluted nature of this tag by ten.  No matter, I slogged through the complexity of HTML's arcane table, and I was able to display the real time information.

Then I got new requirements.  On the surface these requirements seemed simple enough.  They certainly were no more complicated than the requirements I had implemented previously.  However these new requirements were being added to a code base that was starting to grow out of control. 

Suddenly the code was becoming difficult to comprehend.  I had tried to apply object oriented principles to the thin agent by creating javascript objects, but I still found myself constantly looking through code files to remember how to make calls to the different objects I created.  I even tried to encapsulate the various portions of the UI in my own version of user controls but to no avail.  Simply put the code was in a state where I had to remember too many things to understand how to maintain it.

To make matters worse the code was degrading in quality quickly.  I would make changes to one of my objects to support a new feature, update all of the calling code, and execute the thin agent.  Everything would appear to work for a little while, and then all of a sudden the code would crash.  It turned out I had forgotten about a piece of code that made calls to my javascript object.  I would fix the piece I missed and run the code again.  Once again I would execute the thin agent.  Once again everything appeared fine until I hit another piece of code that I had forgotten about, and the thin agent would come crashing down again.  Whenever I had to make a change to one of my objects to support a feature, I found myself spending hours tracking down all of the calls that were made to the altered object.

Then I hit the classic javascript problem.  I was getting different behavior in different browsers.  To be exact I was getting a memory leak in Mozilla's Firefox browser, but I wasn't getting a memory leak in Microsoft's Internet Explorer browser.  The thin agent had gone from being an exciting project to being a complete nightmare.

Why was I having so many problems?  The thin agent may be a big program in javascript, but it's not that big.  I've written applications that were orders of magnitude larger than the thin agent before, and I've been able to incorporate changing requirements.  In fact at Erudite if your code couldn't cope with changing requirements it was destined to find itself in the bit bucket.  Yet here I was working on the most brittle code base I had ever worked on in my short career, and it was a code base written largely by me.

Was this code a mess because it was largely implemented by a javascript rookie?  To a degree there's probably a good amount of truth to that.  However my experience with writing an application in javascript is hardly the exception.  There are a lot of good software engineers that struggle against javascript's arcane programming structure.  At the end of the day I was wrong when I thought that the programming language you use doesn't matter.  It does matter.  The programming language is a software engineers primary tool in developing software, and it has a huge impact on his/her ability to produce quality software in a timely manner. 

At the end of the day javascript/HTML/CSS were not well suited for large software applications.  This is in large part because javascript/HTML/CSS were not built with application development in mind, they were built with document creation in mind.  It was becoming more and more clear to me that we were trying to use web technologies in a way that was not intended, and we were suffering the consequences of trying to force these web technologies to meet our demands.

javascript is not a language intended for writing large pieces of software.  Object Oriented languages are the favored languages for large applications, and javascript is not truly object oriented, as it does not even support encapsulation (all members of a javascript object must be public).  javascript is not expressive, you have to craft your javascript objects imperatively.  Finally javascript requires the programmer to have all of the code in his/her head at a given time; especially if the programmer needs to make changes to an existing object.

As I was struggling with the thin agent I kept thinking to myself: if I could just write this in a decent programming language, like C#, this project would be so much easier.  It was just a few short months later that Microsoft would announce Silverlight.

Unfortunately Silverlight 2's release was a ways out, and so we went with Adobe's Flex instead.  It wasn't until my next job that I got the chance to begin coding in Silverlight.

Silverlight was the answer to my prayers, pardon the cliche.  I loved everything about the platform.  Xaml was just such a simple and intuitive way to define your UI.  No more arcane programming logic to add objects to a grid, with Silverlight all I had to do was bind the DataGrid's ItemsSource property to an ObservableCollection of objects that I wanted to display.  If I needed to add a new object to display, all I had to do was add the new object to the bound collection, voila the new object would be displayed in the U.I.  If I needed to customize the look of the DataGrid, Silverlight gave me all of the tools necessary to do so through Templates. 

Xaml was just one of the reasons to use Silverlight.  The biggest reason was the programming language support.  With Silverlight I could use my favorite programming language, C#.  In fact Silverlight supported several programming languages including: VB.Net, Iron Python, Iron Ruby, and javascript, and these were just the languages supported by Microsoft.  Since Silverlight executes IL code the platform could be extended to support a new language simply by writing a compiler that targets Silverlight's IL code.  This made a lot of sense to me.  Developers want to be able to use their programming language of choice.  We certianly don't want some asshole at Netscape telling us what programming language we have to use to target a platform.

Programming the client in C# was a dream.  Now if I needed to make a change to a class I could make the change, hit the compile button, and fix up all of the code that was calling that class.  What used to take me several hours in javascript I could do in minutes with Silverlight.

Silverlight development kept getting better too.  After we hired Keith, he introduced us to the MVVM pattern.  The MVVM pattern was a major architectural change, but it also promised huge improvements to our code base, testability chiefest among them.  We decreed that we would do all new development in MVVM, and we even fixed legacy code to use MVVM.  Once again Silverlight was allowing us to make the code improvements that never would have been possible if we were using javascript.

Silverlight kept maturing.  The patterns and practices group at Microsoft ported Unity over to the Silverlight platform.  Once again we were able to incorporate Unity into our Silverlight application, and we were able to take advantage of Unity to write unit tests for our Silverlight application.

The more I used Silverlight the more I loved it.  This is in contrast to javascript, where the more I used javascript the more I loathed it.  Once again my experience with Silverlight is hardly unique.  In fact I'm yet to find an experienced Silverlight developer that hasn't fallen in love with the platform.

With Silverlight life was good.  We got the productivity benefits of leveraging the .Net framework, along with Silverlight's declarative Xaml.  We also got the ease of deployment benefits that come from the browser, as well as cross platform support.  Silverlight offered us everything we were looking for in a platform and more.

Microsoft looked incredibly committed to the Silverlight platform too.  In fact Microsoft chose Silverlight as the development platform for targeting Windows Phone 7.  At one point Steve Ballmer even declared Silverlight to be Microsoft's unified platform strategy.  You could use Silverlight as the Platform to target the Phone, the Web, and the Desktop.  There was even a promise of being able to target the T.V. with Silverlight in the future, Microsoft's famous three screens strategy.

Then Microsoft's PDC 2010 happened.  Silverlight was notably missing from PDC 2010.  When Mary Jo-Foley asked Bob Muglia about Silverlight she got this response: "our strategy has shifted" and " HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform".

I was completely taken aback when I had read Bob Muglia's response.  I wasn't alone.  The outrage from the Silverlight community was palpable.  Microsoft quickly tried to contain the situation by hosting the Silverlight firestarter in December 2010.  However the firestarter only succeeded in creating a mixed message about Silverlight.

That mixed message would continue.  The excitement surrounding Silverlight at Microsoft seemed to virtually disappear.  Things only got more muddled when Microsoft announced their new Metro UI for Windows 8.

Windows 8's Metro UI was a perfect fit for Silverlight, but while demonstrating a demo app for Metro, Microsoft's Vice President Julie Larson-Green said: "our new developer platform, which is, uhh, it’s based on HTML5 and JavaScript..."

Things were looking worse than ever.  Not only did Silverlight appear to be dying, now Microsoft wanted us to develop Windows applications with HTML5.  Why would anybody want to do that?  Sure HTML5 adds some neat capabilities, but it still relies on the same lousy javascript programming language it is has always relied on.  Once again Microsoft's developers were outraged.  Microsoft's response was that we should wait for their Build conference, which was three months away.

We waited those long three months for the Build conference.  Finally at Build Microsoft unveiled their Metro UI platform, called Win RT.  Sure enough developers could target Win RT using HTML5 and javascript.  Microsoft had even extended the javascript libraries so you can make Win RT specific calls in your javascript code, albeit making these calls makes your javascript specific to the Windows platform (I wonder if that was on purpose).  Fortunately for .Net developers you could also build Metro apps using any .Net language, or even native C++, and we could use Xaml to markup the UI. Our worse fears were not realized.  Microsoft was not pushing .Net developers out of the fold, they were merely bringing web developers into the fold, and they were even re inviting C++ developers back.

The .Net solution for building Metro applications immediately looked familiar to those of us who have been developing in Silverlight.  In fact aside from some minor changes, the .Net solution for building Metro applications was Silverlight.  In some ways this was reassuring to Silverlight developers, because we now knew that our skill set would continue to be valid inside the Microsoft eco-system.

Unfortunately our skill set would only be valid inside the Microsoft eco-system.  There are two huge difference between Silverlight and Metro.  Silverlight is cross platform, as Silverlight applications can execute on both Windows PC's and Macs.  Furthermore Silverlight applications can be delivered via the browser.  Metro applications are delivered via Microsoft's app store, but there are some reports that Metro applications can be delivered over http, and they can even benefit from sandbox security.

Clearly Metro is not a complete substitute for Silverlight, and unfortunately Silverlight was hardly mentioned at all at Microsoft's Build conference.  After Microsoft's Build conference it seemed more and more evident that Microsoft had little intention of continuing Silverlight for much longer.  When pressed about the future of Silverlight Microsoft was consistently changing the subject back to Windows 8.  Finally on November 8, 2011 an article by the well informed Mary Jo-Foley appeared, reporting that Silverlight 5 will be Microsoft's last version of Silverlight.  While her article has not been officially confirmed by Microsoft, her narrative is consistent with what we've been seeing from Microsoft.

I'm sorry fellow Silverlight developers, but Silverlight is dying.  The past year many of us have been going through the seven phases of grief, I know I have.  I've even found myself mad at Bob Muglia and Mary Jo-Foley for reporting the bad news.  However with a heavy heart I've come to accept Silverlight's fate.

Fortunately the future probably isn't all that bad.  Make sure to check back for my second part: Where do we go from here.