Where is Silverlight now?

Time ago I wrote an article about the comparison between of HTML5 and Silverlight. That article was indeed about the "comparison" itself rather than another attempt to compare the two; mainly because I consider that kind of measuring to be pointless. Then again with the pass of time the same question arises: is Silverlight dead?

Before going into trying to answer that, allow me to be clearer than what I was at the time and let me rephrase the question: is the silverlight plugin for browsers dead? Well... the answer is yes, not even a "maybe". But as with any existing software, dead is not actually extinct. We still have people writing code in COBOL, FORTRAN,  DELPHI and VB6. And this is because the enterprise market does not move at the same pace as the consumer market. They invest in infrastructure, they keep it, and they treasure it. And Silverlight was highly adopted in the enterprise for LOB applications. So in that area, Silverlight is going to be there for some time.

So why do people complain? Well the media helped. Panic: Silverlight is dead, go to HTML 5! And when there is a fire, people's first reaction is to scream and run away, instead of finding the origin and trying to do something.

Now, to be honest I was quite disappointed when I saw everybody at Microsoft just jumping off the Silverlight ship. As a C#/XAML developer I felt betrayed, I could not imagine how someone could drop all those really cool, dynamic, responsive and beautiful applications for basic HTML pages. And when they announced that ARM versions of the Surface (the RT) wouldn't run Silverlight I was really mad. But I was short-sighted. It took me a bit until I realized the obvious: I could do the exact same thing that I was doing with a "plugin in a browser" with "an app"; a mobile app, a windows store app, and it would be better fitted for my Windows Phone or my Surface table than any web site. The skills are transferable, and the underlying is similar,it is not a hard task at all. 

And then everything made sense, Microsoft would support HTML5 for the web, pushing the standard along other big guys, and Silverlight was repurposed to fit other roles, and as of today 200.000+ apps in the Windows Phone Store shows that it is not dead.

HTML5 is going to be there, so we have to support it, because it is all we have. Yes, is sad to admit it, more than 20 years later, we have nothing better. HTML is terrible, JavaScript is terrible, and the new potpourri called HTML5, is still terrible. But again, let's face it, there is nothing better. 

A Windows Store app where you see XAML and .NET is not technically Silverlight, but it will take you no time to convert your Silverlight app into a new one, either a regular WPF, windows phone, or windows store (ARM or x86). A lot of the code can be reused, with little to no modification at all.

Silverlight is not dead, it evolved. You have it on your pocket in your Windows Phone, your Windows tablet, on your Windows computer at home; it is just not constrained anymore to be a hanging plugin at the will of a browser. It does not require a browser anymore. It's transparent to your eyes, you don't see it, and all you see is an app. Because that's all you need.

Comments

Post a Comment

Popular posts from this blog

Get-ChildItem vs Dir in PowerShell

Image
Batch as usual Recently I was in the need of modifying a huge amount of files across a network share. After installing Serviio media streaming service I noticed that it will crash "randomly". After checking the logs it was clear that ffmpeg was crashing when trying to open subtitle files that were not in the encoding indicated by the Serviio console. I needed a quick way to update all subtitle files to a common encoding, so I decided to convert all files to UTF8. Since I use a windows environment I went directly to PowerShell and wrote this.  Get-ChildItem -path .\ -filter *.srt -file  | ForEach-Object { (get-content $_.FullName) | Out-File $_.FullName -encoding utf8 } This worked almost right except for files with "[" or "]" (among other symbols) on the name or path. To solve it, just added the "-LiteralPath" switch to tell powershell not to consider any wildcards on the path name and just use it exactly as it is.  Get-ChildIt...
Read more

The case for a 4 week sprint

Image
Every time we talk about SCRUM, the length of the sprint is stated as a period of "two to four weeks", rarely, however, have I seen people going outside of the 2 weeks. This is not written on stone of course, and while 3 weeks might seems odd, there is a benefit to using a longer period for your sprints.  Image is taken from scrum.org Without any hard data to back that decision, the answer I get from asking about this decision seems to be related to "delivery speed", we assume that because we deliver value to the business every 2 weeks, we are in a more "agile" environment. Well, that might not be so true in every sense or for every project. Let's break some arguments: 1. Sprint length is not equal to the speed of delivery There is more to the speed of development and delivery than the timeframe of the delivery cycle, in a world with DevOps and full CI/CD implemented for your project, you could (should?) actually deliver features every single day all t...
Read more

NODE.js fs.readFile and the BOM marker

Working on a ReactJS project, got a small glitch while trying to read a JSON file and parse it as a javascript object. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString); } output:   SyntaxError: Unexpected token   After checking, double and triple checking again that the file was correct I went deeper and realized that "fs.readFileSync" was returning me the BOM for the UTF file at the beginning of the string. So we just need to strip it out. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString.replace(/^\uFEFF/, "")); } I then checked and there are "packages" for this, however I don't think is proper to just import a new dependency just to fix something this small. The big issue here is why is this considered correct. The BOM is not ...
Read more