Skip navigation
water droplets on a spider web

Sizing Up Client Development Choices: XAML-Silverlight or JavaScript-HTML5

John Papa's perspective on the future of Silverlight and XAML development

Editor's Note: Welcome to .NET Rocks Conversations, excerpts from the .NET Rocks! weekly Internet audio talk show. This month's excerpt is from show 730, with John Papa, a former evangelist for Microsoft on the Silverlight and Windows 8 teams and presenter at conferences including BUILD, MIX, TechEd, DevConnections, and Visual Studio Live! In this conversation, John shares his perspective on the future of Silverlight, the benefits of XAML, and his renewed interest in JavaScript and HTML5.

Carl Franklin: Let me ask you to put on your opinion hat and give us a little thermometer of where we are in relationship to the XAML technologies. Of course, I'm talking about Silverlight, WPF, Windows Phone, Windows 8, Metro. XAML seems to have taken center stage of attention and less so the particular engines that interpret XAML on different platforms.

John Papa: I think that's true. Where we are is a complicated discussion obviously, but the thing I think that's interesting is, I think a lot of people have clung on to XAML as being the commonality between all these technologies, and the way you program against it is really what they're missing, what they don't want to see go away. It's not necessarily that it's the platform.

CF: Yeah.

Richard Campbell: The challenge, of course, is that it's actually different runtimes. XAML is not just XAML. There's quite a bit of variability between what you write [with] WPF and what you write, say, against WinRT.

JP: Absolutely, and that's been always one of the problems that people have had . . . originally we had WPF and Silverlight. We made two flavors of XAML, really. Now we've got, what? Four? Five?

RC: Yeah.

JP: And people were complaining that they weren't in sync. Now we've got so many that I think people pretty much have given up hope that all of them will ever be in sync, but they still love their XAML.

CF: Yeah.

JP: I still get emails like crazy about what's going on with Silverlight. Is there going to be a Silverlight 6? I've had emails from people, more than 100 emails saying, "Is there going to be a Silverlight 8 or 9?" So people are very interested in where XAML is heading and what the future is.

RC: What do you think? Is there going to be a Silverlight 6?

JP: I don't know one way or the other for sure. But at this point I'd be willing to bet that there's going to be another version of Silverlight in some way, shape, or form. Mostly just to help support the big companies, [those] like Netflix and NBC and the Olympics, things like that.

RC: What I found interesting about Silverlight 5 is that it was the quietest release of a Microsoft product I've ever seen. It just sort of quietly slid out in the middle of December.

CF: No fanfare.

RC: No fanfare at all.

JP: Especially compared to what happened with 2, 3, and 4 releases. I mean, they were major announcements. So yeah, it's an interesting strategy. There might be more versions, but there's not a huge amount of things to add to it at this point. That's not the reason I don't think there will be another version, but I just think the company is heading [in] other directions.

CF: One of my thoughts is that it's found its niche, you know? We didn't really know . . . when Silverlight 1.0 came out, it was sort of a glorified animated .gif player. Silverlight 2 started to creep toward [being] an application platform, and by 3 we had binding and data access and all this great stuff. So it sort of found its niche in the business world, I think, where it just solves the whole deployment of Windows applications apart from the obvious video stuff that can go mass market. That's great, by the way, and there's no better way to do it, and there's no other way to do, you know, that kind of streaming across all the platforms.

JP: Yeah, the video streaming is absolutely fantastic with it, but I think you're right. The key that a lot of people were clamoring about is they're building a lot of business applications with this framework.

CF: And, you know, it's done, it's good. It does everything you want it to.

JP: I mean, there's lots of people still using WinForms.

CF: You know, the tool vendors sell more Windows Forms tools than anything else still.

JP: Uh-hmm. That's true.

CF: That's because there's just an army of Windows Forms developers out there that are either maintaining or building new applications.

RC: And the tooling is very, very good. I still don't think we've got as good a tooling for Silverlight or any XAML development process as we've got for WinForms.

JP: Yeah, and I think that's the area that people are missing the most when they look at things like HTML5 and JavaScript and CSS. They look at the tooling story for things like Silverlight or Web Forms or MVC or even WinForms, then you go over to HTML5, and really it's a pitiful story at this point until something gets released.

RC: The other side to the whole Silverlight debate is that really Silverlight was cross-platform. That seems to be the thing that Microsoft is walking away from is that the strength of Silverlight was that it would run on the Mac. We just stopped talking about the fact that Guthrie and his team got a chunk of the CLR running on a Mac.

JP: Yeah.

CF: It's pretty awesome.

JP: It was pretty amazing. Yeah, you're right. In the beginning it was a media story, then it was a cross-platform story, and then the line-of-business thing kind of came later, but that was the one that really took hold. But the cross-platform story -- the way I looked at it was Silverlight was really a huge competitor for what Flash and Flex were starting to do in the business space, and the Microsoft team built a better Flash and Flex, in my opinion, to do line-of-business apps. And then all of a sudden things changed in the world.

CF: The iPhone.

JP: A few years ago the iPad came out. The iPhone was out [the] year before that. Things started changing, and then cross-platform didn't seem so important.




CF: Well, all the fun stuff was being done on those platforms, and that's where the demand for apps was.

RC: Yeah, I mean Apple decided they weren't going to run plug-ins, and you can argue the merit of that one way or the other, but the reality is once that decision is made, it doesn't really matter what technology you're using.

JP: Yup.

CF: Here's the bottom line. Developers want tools that they can build apps with that run on as many popular platforms as possible, and the popular platform is really what it's all about. Their users and our users are demanding that we have iPad apps, so that's what we built.

JP: If you're building a consumer-based app, the stories really changed dramatically over the last couple of years. If you're building business apps for the enterprise for big companies, the stories changed a little bit, but I think that's where more of the concerns come in from people. They're like, "Why can't we use XAML still," and the truth is they can. They can use XAML, they can use WinForms. They're all still viable technologies, but the interesting space is the consumer space because three years ago there was no consumer space.

CF: So let's talk about HTML5, CSS, JavaScript, that whole camp. This is something that you're very interested in these days, are you not?

JP: Yeah, I've been kind of an architect of all levels for many years, and the area that I focused on in the last five or six years has been the client space. I got into JavaScript and HTML before I got into Silverlight, and basically backed off it because I didn't like the state of affairs and went down the WPF-Silverlight route. But I got back in over the last year and a half here because primarily I wanted to figure out where things are heading. Everyone's talking about HTML5. I'm not just going to go out there and say I love Silverlight. HTML5 is bad.

CF: Yeah.

JP: I want to know what are the good and bad points. What's evolved? So I spent a lot of time looking into the good and the bad points, and there's a lot of both. A lot of things have changed, and it's quite an interesting space right now.

RC: I don't feel that HTML5 has the strength that Silverlight has in terms of just building a rich client. We can make stuff look good in HTML5 and look like Silverlight, but that state-management space, the ability to do complex manipulation and to work in a really robust language, I don't think it's comparable.

JP: I think the experience, the development experience, I agree with you on that. Let's put it in simple terms. I think it's a lot easier to do things with XAML, for example, or some other Microsoft web technologies than it is to do in HTML5, CSS, JavaScript. I'll be very blunt. There's things I could do in Silverlight that would take me maybe three times the [amount of] time to do with HTML5 or JavaScript. Are there things I can't do with HTML5 and JavaScript for Silverlight? That separation is getting much, much narrower at this point. There's a lot of things you could do and even things like data binding you can do with JavaScript now with multiple different libraries that have come out.

CF: So tell us about some of that. Are we talking about Knockout?

JP: Yeah, Knockout is something I'm really, really big on. It's basically a JavaScript plug-in that you can use to do data binding between HTML, CSS, and JavaScript. It has the concept of observables, which if you're familiar with XAML, the observables are basically these objects that you create with JavaScript that are kind of implementing the INotifyPropertyChanged interface in XAML. There's another library, though, for data binding that will be coming out in a couple of months. I don't want to go too much into it yet, but the quick history on it is, Boris Moore, who also works for Microsoft [and] is one of the creative influences behind jQuery Templates, is actually working on JsViews and JsRender, which are two JavaScript library plug-ins that do templating and data binding as well.

CF: So I guess are you looking down the road at JsRender to be the model that you're going to be using most? How does it work?

JP: I haven't decided yet between Knockout and JsRender and JsViews, which one is kind of the primary, but they have different keys. So for example, Knockout is a little more robust at this point because it's been around longer and there's a lot of people using it. There's a very active community and even plug-ins to enhance it. I've done a couple of apps with it, and it's really, really nice. JsViews and JsRender are in the alpha stage right now, but the things I like that they have over Knockout is in Knockout every JSON object that you get back you really need to convert that to an object that has these observable properties. So you're not just taking your JSON object, you've got to take it and then make the properties of this Knockout observable. Even your arrays are like observable arrays. So it's not just POJO, Plain Old JavaScript Objects.

But with JsViews, you can actually just take your plain JavaScript JSON objects, and you can use those with the data-binding mechanisms. That's one difference I do like on the JsViews side. Another one is the syntax: In Knockout you have to have a data-bind property and all your HTML elements, and then you put all your data bindings in that one attribute separated by commas since you want to bind like the value property of an input, the

enable property, the visible property, all those are in one attribute inside your tag. With JsViews you actually bind each individual element inside your tags. So if you've got a visible or enable or a value property, your binding goes in each individual one of those, which is a little bit more like the XAML syntax.

CF: Yeah, I was going to say it's very XAML-ish.

JP: Yeah and obviously, I kind of like the XAML side of the world. They're both very popular, though.

There's much more! You can find the full interview at

Richard Campbell and Carl Franklin are the voices and brains behind .NET Rocks! They interview experts to bring you insights into .NET technology and the state of software development.


Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.