Cross-Training in Silverlight & Flex – The Future of RIAs

More Cross-Training in Silverlight & Flex

Shout it

What a week for RIAs!  The first half of the week was consumed by the Adobe MAX conference where we got to see the future of Flex.  The second half of the week was consumed by the Microsoft PDC conference where many of us were hoping to hear about the future of Silverlight.  Unfortunately, the PDC conference was noticeably absent of Silverlight futures.  This caused a ton of speculation about the future of Silverlight. 

One of the most prominent articles of the day was written by the prolific technical journalist, Mary-Jo Foley – Microsoft: Our strategy with Silverlight has shifted.  This article cause a huge uproar which then drew many people to weigh in on the topic (Is Silverlight dead?  Is Microsoft abandoning SIlverlight?  Is this the death of the RIA framework?).  Many blog posts have come out with plenty of opinions, but I think I have a different perspective.  One that looks further into the future and allows for peaceful co-existence between Silverlight, Flex and HTML5.

What I am about to write is purely speculative.  I am making predictions. Predictions are very often wrong.  Still, I think what I have to say adds to the debate.

Let’s Stop Thinking of Flex and SIlverlight as Separate Platforms

The browser is a platform.  With the introduction of HTML5 standards, we have all of the primitive structures that are required for a client platform.  The browser is ALSO a platform that lives on every web-enabled device we own.  Because of this, many have made the brazen statement: “We don’t need RIA technologies (Flex and Silveright specifically).  All we need is HTML5 and Javascript”. 

If you think of Flex and Silverlight as separate platforms, I think I might agree with that.  The browser is everywhere.  Flash and SIlverlight are not.  But is that REALLY where we are headed?  Or did the RIA plug-in come into existence because we needed to shoehorn something before wide-spread adoption of HTML5?  What if Flex and Silverlight were frameworks that sit on top of the browser platform instead of being their own platforms that compete with the browser?

Put another way, I will ask this question: “Why do we need Silverlight and Flash plug-ins?”  This is a serious question.  Now that we have all of the primitive components necessary in the browser to do everything we need, why can’t Flex and Silverlight compile down to HTML5 and Javascript?

Sound crazy?  I’ve been accused of this idea being crazy… but I don’t think it is.  Microsoft proved that managed C# can be compiled down to Javascript (as opposed to byte code) over two years ago with their Volta experiment.  Google has done similar things with Java.  What is to say that Silverlight IL or Flex ActionScript bytecode can’t be compiled to Javascript?  Continue with that reasoning and XAML or MXML (the declarative UIs of the RIA platforms) can be translated to the DOM.  All of the control sets can be delivered as Javascript libraries that build upon existing HTML controls, or build up new ones with the canvas.  Everything can run natively on the HTML5 engine.  Get rid of the plug-ins!

Silverlight and Flex as Frameworks

In a plug-in free world, we are left to develop in any language and any framework we want.  Silverlight and Flex become higher-level abstractions on the virtual machine that is HTML5.  Developers are given choices – not just HTML and Javascript, but XAML and C#, MXML and ActionScript, HAML and Ruby, FooMark and MyLang, whatever.  You won’t have to be confined to a single markup, control set and programming language.

In other words, if we start to look at the browser like a virtual machine, our RIA possibilities are endless.  What if HTML6 defined a bytecode format that the frameworks compiled to?  Skip the Javascript.  We can follow this idea to many conclusions.

EDIT: To qualify my statements further, I want to be clear: I don’t expect Silverlight and Flex projects will translate directly to HTML5/JS.  I think that Silverlight and Flex frameworks will become native browser frameworks (System.Core.js, or Flex.js for example).  Silverlight and Flex applications will run with the frameworks in the browser without a plug-in.  Doing so allows for these frameworks to be portable to all platforms (phones, tablets, set-tops, browsers and desktops).  See my conversation with Michael Washington in the comments for more on this.

So, is Silverlight Dead?

I don’t think so.  I really believe that SIlverlight is shifting towards being a development framework, instead of a development platform.  Look at the WIndows Phone 7, for example.  The phone OS is the platform.  Silverlight is the framework.  Adobe is certainly looking at it this way.  They have already created a tool that will compile Air apps down to the native iOS (iPhone) platform.  In addition, they have announced that Air will be available on every device that we care about (iPhone, Android, Blackberry, WebOS, GoogleTV, etc).  I fully expect Silverlight to do the same.

Somebody on Twitter said “They didn’t mention me at the PDC. Does that mean I’m dead?”.  A witty way to say it, but I think it rings true.  They didn’t mention Silverlight specifically, probably because they were focusing on other things.  They are taking a huge gamble on the phone, and I think it is necessary for the future of SIlverlight as a framework.  We will hear more about SIlverlight.  I am sure of it.  My take: SIlverlight isn’t dead.  It is only evolving.

What do you think?  Am I crazy? (I might be) If so, tell me why. 

Tags: , , , ,

18 Responses to “Cross-Training in Silverlight & Flex – The Future of RIAs”

  1. Cross-Training in Silverlight & Flex – The Future of RIAs…

    Thank you for submitting this cool story – Trackback from DotNetShoutout…

  2. [...] This post was mentioned on Twitter by Brian Genisio, Larry King. Larry King said: Cross-Training in Silverlight & Flex – The Future of RIAs « Brian … #SL #RIA [...]

  3. [...] Brian Genisio's – Cross-Training in Silverlight & Flex – The Future of RIAs [...]

  4. [...] This post was mentioned on Twitter by Michael Chandler, José F. Romaniello. José F. Romaniello said: This is an interesting idea, worth read [...]

  1. I also considered the “hit a button and get a HTML 5 version of my Silverlight application”. I will evaluate it when/If I see it.

    Anything else, for example “pound out the application using JavaScript and the HTML5 canvas…” seriously? We did this already 10 years ago, remember? :)

  2. admin says:

    @Michael: Yeah, I think that is what keeps me gounded in Silverlight and Flex right now… the hopes that I can continue to write applications at an abstraction higher than HTML. Every time I go back to HTML, I find myself feeling like I am missing the nice things… like data binding. Oh, how I pine for data binding in HTML.

    But if we get to a place where these frameworks sit on top of the HTML/Javascript platform, then HTML never needs to support data binding directly. The frameworks that want it can implement it.

    I dunno… I might be hoping for too much.

  3. I know you are ‘just thinking out loud’ and I also Tweeted something similar a few weeks ago.

    But, I am working on an app using Sterling Object-Oriented Database for Silverlight and Windows Phone 7 ( and MEF and reports using the Silverlight Reports project.

    I am unable to imagine hitting a button and getting that in HTML 5. I mean I plan to be DONE with this application TODAY (and I started this morning).

  4. admin says:

    @Michael: Well, I suppose I’d ask the question (as respectfully as possible): “Why Not?”

    If it is the case that we can compile C# down to IL and IL to Javascript (as Volta showed), it is conceivable that every Silverlight DLL we have can also be compiled down to Javascript. This would mean that you could have Javascript versions of Sterling, MEF and Core.

    If the performance improvements of the new Javascript engines live up to their expectations (with JITting, and Hotspots and what not), then I think it is completely conceivable that anything we write in C# can execute in Javascript without out ever knowing or caring. Think about the size and power of jQuery, for instance.

    I suppose I will argue it from a different angle… I think that it is inevitable that we will see higher-level abstractions that live on top of HTML5 and Javascript. They will come organically and be a lot more powerful from a development perspective than raw HTML and JS. If these frameworks materialize, I think that they will look a lot like Silverlight or Flex. And if they do, they will give Silverlight and Flex a run for their money.

    I am thinking about an analogous landscape to the current server language/stack story… so many frameworks exist that we can’t keep track of them. I think we will see the same on top of HTML/JS for two reasons: People don’t want to stay as low as HTML5 primitives. Also, people want to work with the metaphors that work best for them.

    I think Microsoft is anticipating this, and I think they have plans to support this.

    All that being said, I will say this: Close friends of mine, whom I respect, think my views on this are crazy. I will be the first to admit it… I might be crazy :)

  5. As to “Why Not” I only ask “How are you able to translate my MEF/MVVM/Dynamic injected/Media Driven Silverlight application to HTML5? or create a HTML5 output?”

    They may have a “Design it in Silverlight and run in HTML5″ it’s called Silverlight 1.0 <- Seriously I was programming Silverlight in Silverlight 1.0 and you can do a LOT in it.

    But, that is 3 HUGE Silverlight versions from Silverlight 4 :) :)

  6. admin says:

    @Michael: Ok. I see the disconnect. Let me try again. It requires a different viewpoint, so be prepared to think outside the box.

    I am not suggesting that the XAML translate down to div, span, form, button, etc. I am suggesting that the canvas has the capability of managing the drawing primitives that Silverlight needs to implement its own controls on the canvas. I am suggesting that Silverlight is a framework that runs on top of HTML5/JS and your Silverlight app runs at that higher level.

    In Silverlight today, as we know it, there is some sort of frame buffer that it ultimately renders to. The Silverilght libraries simply create controls from drawing primatives (line, rectangle, text, path, ellipse, etc). When we have a Silverlight Button control, it is a high-level abstraction that ultimately gets down to the drawing primatives.

    With the HTML Canvas, it becomes a frame buffer for Silverlight. If we can compile System.Core.dll and System.Windows.dll down to Javascript instead of bytecode (which we can), then there is a version of System.Windows that writes to the HTML5 Canvas and Video elements instead of what it is currently doing. All of a sudden, you have System.Windows.Controls.Button drawing on a canvas. StackPanels, ItemsControls, Labels, whatever, all draw to the canvas.

    So to answer your question: “How do you do MVVM in this environment?”. The answer is: Your C# ViewModel compiles down to JS. It data binds to the Silverlight control that is drawn on the canvas. The JS-compiled version of System.Windows.dll manages the data binding using the exact same mechanism that Silverlight uses. Your ViewModel is handled just as it normally would. HTML elements are nowhere to be found.

    How do you do MEF in this environment? MEF compiles down to JS instead of bytecode, so it works against everything in the framework. System.Windows.Controls.MediaElement is implemented in terms of the Video tag.

    In other words, your Silverlight app does not translate over to HTML5/Javascript. It runs in a Silverlight framework that sits on top of HTML5/Javascript. The browser becomes your CLR. You, as a programmer, never need to think about HTML5 or JS.


    Now, after all of that, I am SURE of it. You think I am crazy.


    Someone once told me: “There is no problem that can’t be solved without another layer of abstraction.”

  7. I brought up Silverlight 1.0 because I think is shows that Silverlight can be controlled by JavaScript now so replacing the Silverlight Canvas with a HTML5 canvas is not unthinkable. So MY point was that a lot of what you are saying IS possible.

    However, I see that what you are really saying is, No the programmer can still write in C#, it would get COMPILED into JavaScript.

    On that issue we will have to wait and see if someone shows us anything close to that.

    However, performance… consistent performance is an issue whenever “JavaScript” enters the conversation :)

  8. admin says:

    @Michael: Now we’re talkin’ :)

    Michael said:
    “will have to wait and see if someone shows us anything close to that”

    This is where I think that MS is poised to give us something that does this. They had a research project in 2007 called Volta that did exactly that — compiled IL down to JS instead of bytecode. It was a system like Google’s GWT where you wrote all your code one place, (in C#) and you used attributes to declare where it lived (server or browser). Volta dropped off the face of the (public) net about one month before Silverlight 2 was announced.

    This is where my speculation/prediction is coming in. I think MS has the IL -> JS technology in their back pocket, ready to unleash. Before they do that, they need to make sure their browser can handle it. I am speculating that one of the reasons that MS is putting so many resources torwards HTML5 and efficient JS is because they want Silverlight to run directly in the browser without a plugin (, perhaps?)

    Ultimately, I think MS is not killing SL. Instead, I think they want SL EVERYWHERE (all phones, all set-tops, all tablets, all browsers, all desktops). Getting it to run natively in the browser without a plug-in feels like an obvious vehicle to me. (plug-ing would still need to exist for legacy browsers. They would be more lightweight, introducing Canvas and Video, essentially.)

    Michael said:
    “performance… consistent performance is an issue whenever “JavaScript” enters the conversation”

    Yup. Totally agree. And if the perf is not there, then I think the assertion that HTML5/JS can do anything SL or Flex can do falls out the window. In that case, we will still need our plug-ins. I hope this is not true.

  9. Andrew says:

    For some time, I also believe that having a feature to compile to Javascript+HTML5 will be a total blast.
    I mean you take developers which are not web savvy and give them a tool to become so instantly. It’s huge.

    However, I am wondering if the effort of building this isn’t much higher instead of coming with something new for the web.
    I am thinking about Microsoft coming with great framework for the web (Javascript + HTML5), I mean some similar XAML stuff from Silverlight and WPF.

    My feeling is also that Microsoft might really be cooking something good. I think what they did with WPF and Silverlight might had give them some cool ideas on what can they do next.
    However, I cannot stop thinking about Muglia’s unfortunate comments on Silverlight regarding “shifting priorites”.
    I am not sure exactly what was the reporter’s question and in what context.


  10. Brian R says:

    Different Brian here.

    I did a LOT of work with GWT & AppEngine last year and then with Silverlight & Azure this year. Having used both, I can say there is an enormous amount of convergence in the technologies. I would not be surprised to see Silverlight take a page from the GWT handbook and compile into HTML5 and JavaScript in the future.

  11. Vic Klien says:

    > …Air will be available on every device that we care about
    > (iPhone, Android, Blackberry, WebOS, GoogleTV, etc).
    > I fully expect Silverlight to do the same.

    But I think that was one of the key points in the “shift” Muglia described. They are NOT going to port SL to Android, etc.

    You can hope for some exotic way of getting SL to run on those other platforms, but that is, as you’ve said, pure speculation.

  12. Mike says:

    I hope you’re right about Microsoft being able to transition the Silverlight Runtime into a compliant HTML 5 runtime. That would be epic.

  13. Interesting article and comments – I definitely think you’re on to something here Brian.

    For the record, I do believe that interview was taken out of context – however I suspect you’re right – there is a clear implication that thinking on Silverlight has taken a turn at Redmond.

    Nevertheless, I have concerns – especially on the Flex/Flash side of things. Flash has a long history of ubiquity and its designers and developers are accustomed to graphics and animations rendering EXACTLY the same in each and every browser/platform. This had traditionally been one of the strongest arguments behind a Flash/Flex application. This new methodology your suggesting – whilst a real contender for universal “reach” – is going to sacrifice a fair amount of fidelity as it spans so many different browser implementations.

Leave a Reply