Silverlight is dead. Long live LightSwitch!

[SPOILER ALERT]I’m working on my presentation: “Visual Studio LightSwitch: Under the hood” for community days, and decided to post a little preview of some of the contents…  If you are one of the 8 (or more, hopefully a lot more) people that intend to join my session, don’t read on…

After the usual “TOC” and “About the speaker”, I show a very small demo on LightSwitch for those people that tend to sneak into level 400 sessions without knowing the technology (something I do a lot myself :-)).  Right after the demo, something along the lines of this follows:

So anyways, if this was the first time you have ever seen LightSwitch, I can imagine you’re thinking:

Man, I wish I had LightSwitch about three years ago… When Silverlight wasn’t dead.

As a LightSwitch addict, it must admit it hurts every time I see or hear this.  Silverlight is dead.  Stop saying that.

The truth is, Silverlight is not dead at all.  Microsoft just rolled out an update (5.1 was rolled out on May 8th 2012), and they commit to support SL5 untill at least 2022 on Mac OS 10.5.7 and Windows 7, or lower.  Besides, in my personal experience, when it comes to the technology that’s used to build their products, the business really doesn’t care…

[Small pause]

Did anyone buy a word of what I just said?  Anyone? Did you? 🙂

So here’s the truth, the whole truth and nothing but the truth… At least, what I, as a non-Microsoft-employee, think I know of the truth…  

Screw palliation: Silverlight is dying.  I know it’s a harsh thing to say and I tried to deny it myself for quite a long time, but it’s the truth, so you might as well skip right to the fifth stage of grieving: acceptance.  In the youth-oriented, fast-paced, ever-changing IT world that we live in today, every new technology will die at a certain point.  Silverlight might not be dead *right now*, but since Windows 8 going RTM in less than two months, it sure is dying a lot faster than some other technologies…


Meet Matt Evans.  Besides having one of the goofiest (I mean this in a good way) profile pictures out of all Microsoft employees, he’s a member of the LightSwitch team and an enormous help to anyone with a LightSwitch question on the MSDN forums.  One of his recent replies on those forums, was this:

The first line: “The LightSwitch team here at Microsoft is hiring people”, makes me question two things:

1) The LightSwitch team is hiring? What the h*ck am I still doing here in Belgium??!?

And, more realistically:

2) Why are they hiring?  LightSwitch uses Silverlight as a client, and Silverlight is dead.  Why on earth would you be expanding the team?  (Let’s pretend you haven’t read Matt’s second and third line in that post) I’ll tell you why!  Because they’ve got an ace up their sleeves.  And I personally might not know 100% sure what suit that Ace is, but I know for a fact that they don’t just have an ace up their sleeves… They got pocket rockets and the flop’s about to serve them four-of-a-kind!

I’ll let you in on a little secret

Back in the days, when I started programming, we used something called punch cards that basically contained machine level instructions.  This is of course a flagrant lie, I’m 27 and probably wasn’t born when some of you punched holes in paper as a living…

As technology evolved, and magnetic storage and more powerful computers became available, the world got rid of  machine language (1st generation language) and moved on to a higher level of abstraction: writing assembler (2-GL).

That might have been fun for a while, but to avoid unnecessary repetition,  macros were added and pretty soon the world discovered an even higher language of abstraction: 3GL languages such as COBOL, FORTRAN and LISP.  Random side-note: notice how all these 3-GL languages seem to have names in ALL-CAPS.  Ooooh, metro-ish!

Note that from 1-GL to 2-GL, and again from 2-GL to 3-GL, a important “compatibility” shift happen.  Instead of writing instructions that are tightly-coupled to the processor that will execute them, the 3-GL world is now at a level where they can write in a programming language, and then compile that into machine-dependent instructions.

Fast-forward to today’s situation, both the languages and the compilation process there-of, have taken on considerably higher forms of abstractions.  Object Oriented Programming languages like Java, C# and VB.Net, are a higher level of abstraction over procedural programming, and compile in an intermediate language, which is then (JIT-)compiled by a VM to OS specific instructions, who in turn translates these to machine instructions.

Really moving forward, as history proved, means moving towards higher level of abstractions…

I say this of course in an attempt to make you wonder about what the next level of abstraction is that we can make over Object Oriented code…  Well, the next level of abstraction, X-GL (the value of X kind of depends on who’s counting, meaning I really don’t know) is this:

Quick: out of the programming languages you know, randomly pick either your first, your latest, or your favorite.

Now, in that language, imagine you’re giving this UML-like requirement and you’d have to implement it, ie. write the OOP code.  Can you do it?

Of course you can, and the fact that you can is simply amazing!  Not so much that YOU can, in particular, but the fact that based on the same UML-like input, we were able to write (well: imagine writing) implementations in probably half a dozen programming languages.

Let’s do the same exercise again: here’s the requirements to a query, imagine writing it.


Some of you envisioned Entity Framework, some were thinking of LINQ, others had an SQL query in mind.  Based one one input, we can come up with several actual implementations.

See where I’m going to?  Ok one last time, create this screen, mentally, in the technology that you used last before coming to this session:

Were any of you creating this screen in WPF?  Silverlight? HTML5? Swing? A free WebFormsBuilder tool? WinForms?  (If you raise your hand when I say “WinForms” by the way, I do feel for you…)

The point is: based on the same input, you can write all kinds of working applications, varying on (the experience of the developer, and) the requirements of the customer.

And I don’t want to offend anyone’s intelligence here, but if this input is provided in a standard format, a smart compiler could do that too.  Perhaps even better, most definitely even faster.  And if the requirements change to the point where you need to rewrite your application in a different technology, simply take the same input and hand it over to a better compiler…

Pocket Aces, I told you!

This idea is called Metadata driven development, and it isn’t new at all.

In fact, there’s a book called “The pragmatic programmer” (a book I feel everyone should read), which was first printed in 1999, where the DRY-principle was tossed for the very first time…

Although almost everyone will claim to know what “Don’t Repeat Yourself” stands for, I found that a lot of people think it simply means one shouldn’t copy&paste code.  It doesn’t, in fact it describes how every piece of knowledge in a system should have one and only one, unambiguous, authorized source of truth.  Andrew and David describe metadata, and code-generation or interpretation techniques, to accomplish pure “DRY” implementations.

Implementing this DRY principle, the LightSwitch IDE might seem “simple” at first sight, and thus “likely to be inferior” to what you have been doing as a professional developer over the last couple of years. It is easier to dismiss it as a tool for non-developers, than to admit it is actually a higher level of abstraction over the OO code you might have been writing so far.

Each designer in the LightSwitch IDE is in fact a graphical layer over metadata, which is stored in several LSML (“Lightweight & sexy metadata language”) (“LightSwitch Markup Language” actually) files.  This, is the input.

Given enough time and resources, the output, can be whatever you want it to be.

No wonder they are hiring…

Silverlight is dead.  But that was just one way to interpret LSML.  That was just the Ace-ten suited that LightSwitch v1.0 opened with.  Pretty soon the flop will be dealt.  My money, is on the team with the pocket aces up their sleeve…

Silverlight is dead.  Long live LightSwitch!

And then of course I pop open the hood, as we dive deeper in  the metadata driven client, where the metadata is interpret at run time, and in other different engine parts… What do you think?  Good? Bad? Barely staying awake or eye-opening?

16 thoughts on “Silverlight is dead. Long live LightSwitch!

  1. hehe . . . I’ve been telling folks that SilverLight is evolving . . .
    Do you think that XAML will stick around? Do you think that LS will have options to generate both XAML and KnockOut (like) View clients?

    BTW: Your articles are wonderful. I appreciate the reusable Modal Window.

    • Hey Garth!
      I’m sure XAML will stick around because just like HTML, using an extensible markup language to define your UI is a good idea. The specs however (WPF? SL? WinRT?) will change.
      Thanks for the kind words by the way, really appreciate it!
      Hmm, I’m quite sure you know the answer to your question of LS will have options to generate both XAML and other View clients 🙂

      Keep rocking LS!


  2. There is a noticeable shift that occurred in the latest version of LS 2012 RC which is a separation of client lsml from the data lsml. In LS 2011 this was one file, now it’s more than one.
    That should be a big clue to all that there will soon be multiple clients for LS. That’s cool but … the one client that will have the most utility on the broadest OS platforms will remain as SL. Yes HTML 5 will ultimately win but it will take at couple of solid years before HTML 5 catches up to SL and then what.. do all SL apps stop, nope .. they continue to work just as they always have even in Windows 8 (X86 version… which will likely be the hardware platform that most businesses will choose to deploy Win 8 many moons down the road. Heck most are just converted to Win 7..

    In the end it really doesn’t matter. I look forward to seeing all the clients come to market.


    • Hey John!!!
      Thanks again for posting back! Indeed, it looks like the splitting of the LSML was a first step towards creating multiple clients.
      Although it would be nice to see even more client technologies (WinRT, WP8 for example) supported from LS, I currently feel that we’re good to go with SL5 & HTML5 for at least 5 more years.
      I suggested this to the LS team as well, hopefully they’ll agree and move on to other things, like modularity 🙂

      Keep rocking LS!!


  3. The world changes! But does it really? We were doing metadata development before 1990, but doing metadata development to generate VB3 back in 1994, the same product generating VB6. Oh wait, its still running in 2012! With LightSwitch 2012 the time has finally arrived to migrate said product and LOB apps. You know what, the 1990’s metadata is surprisingly similar to the LightSwitch lsml. Will LightSwitch LOB apps be still running beyond 2020, you bet ya! Which Windows OS versions and UI’s, I don’t really care.

    • Honestly, I didn’t know so much about metadata driven development before LightSwitch, so that was a big eye-opener for me (keep in mind I’m very new to IT in fact). Apparently, a lot of good systems use it (Enterprise Architect, SharePoint, Dynamics AX, xRM, …)
      “Will LightSwitch LOB apps be still running beyond 2020, you bet ya! Which Windows OS versions and UI’s, I don’t really care.” > Hell yea!
      Keep rocking LS!


  4. Pingback: Silverlight is dying, long live LightSwitch! « Jan Van der Haegen's blog

  5. Pingback: HTML5 is in town! Long live LightSwitch! « Jan Van der Haegen's blog

  6. Another great article, but I have to disagree that SL is dying. MS have stated they will support it for another ten years or so, and there are enough SL apps around that it will stick with us for some time to come.

    Even though MS just made the awesome announcement that v2 of LS will include HTML5 client support, they have stated clearly that for most cases, the SL client is the choice of preference.

    SL isn’t dead, it just has competition. That’s a good thing, as it allows us to explore the other options whilst still having a very rich and powerful technology in the meantime.

    • Hey,
      I totally agree that SL isn’t dying, I was trying to build up suspension towards the HTML5 client. Tbh, since Win8 supports Silverlight OOB applications, LightSwitch is good-to-go with the HTML5 + SL5 combination for at least half a dozen more years! At that point, SL will die but I’m sure LS will have a solution for that problem (WinRT will have evolved, etc).
      Keep rocking LS!


    • Rory dear sir you couldn’t be more wrong! I would wager a bet and a big one to boot, that you have spent very little time with LightSwitch and further, you have you never tried to build a multi-tier RIA based LOB solution. Not that I care if you do spend the time or not, but you should not post negative comments without some kind of claims to back them up. Share with us your negative feedback or experiences within LightSwitch.

    • Just like John, I’d like to hear you explain one negative thing about LightSwitch. Is it too easy? Too fast? Too adaptable?

      Keep rocking *insert-your-favorite-technology-here-then*! 🙂


  7. I have gained basic knowledge of LS in view to using it with my next project. I read the article with great interest (although you kinda knew where it was going from the start, sorry!). I am happy with the LS side of things, but its the SL side of things. I am assuming (well, I know for the most part) my applications will require branding, content enrichment through ‘externally’ (that is external to LS) developed controls/visual elements and other integration points that are needed in order to read/write to the end screens which are in SL. I guess my question is if SL is dying, then is it wise to make such a huge investment in SL side of things?
    I was hoping someone else would touch on this side of investment …

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s