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 737, with Jeremy Likness, a Microsoft Silverlight MVP, who discusses some of the improvements in Silverlight 5 and makes the case for Silverlight's viability as a rich Internet application platform.
Carl Franklin: Jeremy Likness is a senior consultant with Wintellect and a Microsoft Silverlight MVP. He's been working on enterprise web applications for over 15 years and has used Silverlight since version 3. He is the author of the book Designing Silverlight Business Applications. Welcome, Jeremy.
Jeremy Likness: Hello! Glad to be here.
CF: Glad to be talking about Silverlight again because everything has been phone, tablet, tablet, tablet, phone, WinRT. Damn it, I want my Silverlight back. What's wrong with Silverlight? It's awesome.
JL: A good point. I'll tell you what. People are talking about it. I just had a talk at a local users group on Silverlight, and we had a full room. Lots of people [were] saying that they're heavily into Silverlight development and expect to be for a while. That was reassuring.
Richard Campbell: So they didn't all ask, "Is Silverlight dead?"
JL: No, they didn't. We had groups of people from a lot of different companies, and they're saying that, yes, there's a new tablet, there's this and the other, but when you get to the core of what we have written, a lot of our Silverlight applications for -- which is that line of business -- a lot of people aren't sold that the line-of-business apps can have the same level of functionality on a tablet or smartphone form factor. So there's going to be quite a bit of work on that desktop platform for a while.
CF: Nothing is faster than the keyboard.
JL: That's right.
RC: I don't think the keyboard is going to go away anytime soon, and there is no other method that you can actually fill in a form in any reasonable fashion.
CF: Is it easy to do keyboard shortcuts in Silverlight?
JL: Probably not as easy as it is on WPF. With Silverlight 5, it got a lot easier because there's a lot more support, and you can latch into it to P/Invoke and whatnot. But I wouldn't say it's as straightforward as in WPF where you can have your top-level command handler and bind the keyboards there. It's a little more specific in Silverlight, but it's possible. All the applications that we build that are our line of business, that's always the risk, and that's always something that the customers are very focused on. It's making sure that as nice as it looks with touch, we still have to have our path to be able to tab and focus and type and all of this and jump here.
RC: So the answer is no.
JL: No. My answer is maybe.
RC: Or it depends. But you have to write it. I mean, it's not like there's a class just sitting there and just taking care of it for you. You do have to write it.
JL: You do have to write it. We actually just did an application for a customer that was literally taking WinForms and flopping it straight over into Silverlight. So it's a very WinForm look and feel Silverlight application. To get that actually takes some work. It's a lot easier to build a more touch-friendly and sort of Silverlight experience. So doing all the key bindings, key press, right-click, and contact was a challenge.
RC: It's interesting how Silverlight really does bounce back and forth between a line of sort of that WinForms origin and the SGML sort of the web origin.
CF: We call that the glorified animated GIF player.
RC: Yeah. There was a webby world once.
RC: Wow. Well, that's sort of the compelling thing. We've always had the sense of how quickly can you do the development. Like the difference in productivity. It's not just building code but the maintainability and debugging, which is always a struggle on the website. Do you feel like the tooling is good for Silverlight in that space?
JL: Oh, I think it's fantastic for Silverlight in that space. I think like anything else you can have a poorly written application that makes it a nightmare when you're in the debugger time to try to figure things out, and it doesn't have all the features that the desktop debugger has. You don't have data, and continue, and some of those nuances. But for the most part, you can create nice, well-defined classes and behaviors, have clean code, well-commented code, and step through it, and you can run test, which is what we love. The fact that there's a parity between the Silverlight runtime and the .NET runtime, there's a lot of code we can share between both and run our traditional MSTest through Visual Studio or through an integration test without even having some sort of harness for the Silverlight piece. So there are a lot of advantages for an enterprise development there.
RC: What about Mac support for Silverlight 5? Did they maintain that?
JL: The support is still there. You can still run on Mac. Now having said that, I see two concerns. One is that Silverlight 5 was loaded with a lot of features -- for example, P/Invoke, Platform Invocation Services. The big rumor was that Silverlight 5 would be...so this was before BUILD, before this tidal wave called Windows 8, and the rumor was Silverlight is going to die. They're not even going to finish 5. And then it was, well, they'll finish 5 but it will only run in Internet Explorer, and it won't run on Mac.
The fact is, it's got full support across both. There are a lot of new features in 5 that don't run on the Mac, but you can still create offline out-of-browser applications, you can interact with the file system. There's parity with some of the elevated trust features. You obviously are not going to do P/Invoke and some of those others, but that, of course, is there. I think the big worry or concern, though, is as OS X releases future versions and as the browsers on OS X iterate to later versions, will Microsoft invest in that support of maintaining the plug-in for it?
RC: And the only thing Microsoft said in this area at all publicly is that Silverlight maintains PSS [Product Support Services] support until something like 2021.
RC: That's the only thing they said. They did not say there won't be another version. They haven't said anything.
CF: So the 3D support, the XNA API built in [Silverlight 5], that's pretty nice. I haven't really seen much of it. I've seen a little bit of course, demos and things, but I haven't had the chance to play with it.
JL: Yeah, I haven't done much with the 3D either. In fact, the book that I wrote, it just hasn't been a prime factor in any of my projects, so I left it out and still managed to get a pretty sizable book. I think you can have an entire book devoted just to the 3D aspects. One of my problems is as a developer I'm aesthetically challenged, and so anything having to do with the graphics and sound is really not my area or my forte. But it's very interesting. I've played with some of the demos, the Babylon and the Model House Builder, and it looks very compelling, and there's definitely some line-of-business applications I can see. Of course, the big demo [at] the Firestarter was the 3D anatomy explorer and things along those lines.
RC: Yeah. I'm still pretty confident that there's stuff we can do in Silverlight 5 that HTML5 can't do.
JL: Oh, yeah. Absolutely. Well, I mean, we've had the advantage. As a company, we've been approached by several customers who want to do a prototype or proof of concept, really, in both HTML5 and Silverlight. We could do it. I tell people, "You know, it's not that HTML5 can't do a lot of things." And people say, "I want a rich UI. Should I go with Silverlight?" Well, you can get a pretty rich UI through HTML, and the tools and libraries are out there. It's looking at how long does it take to get there? How painful is it? How powerful are those tools, and how maintainable is it when you're done?
RC: Right. Yeah. So your point being you really can build it all in HTML5, but it's going to cost you.
CF: You learn.
JL: And again...when we're looking at the customers, they're building an application that has an install base that they're in charge of, so we know there's going to be a Silverlight plug-in, then we can start to look at things like, well, development time, code sharing, reuse of existing libraries. There's a lot of advantage there. There are buildings and applications that are out on the open web, and we want accessibility by as many devices as possible. I can't change the fact that it does not run on the iPad or on the Android, and so that just changes the target. It's that you're crippled. You can still provide an experience you have to be smart about, and it's probably going to be a bit more painful than the workflow we're used to with Silverlight.
RC: And it all will consequently cost.
JL: Exactly. That's the bottom line, it's the cost.
CF: Can we talk a little bit about the under-restricted access to any file on your drive in a trusted system? Is that just any trusted application because I make it or [because] it requires a certificate?
JL: There are two flavors of trust right now. There's a trust that is out of browser, and that hasn't really changed. That still requires that you sign your application and validate that you are who you say you are and you have a trusted source. Of course, the user could overwrite that if they wanted to and put an expired or invalid certificate and then restore. I would not recommend it.
CF: You can still publish without having a certificate. It's just that the user will see a thing that says this is a potentially untrusted source. If they still trust you, they can still install the app.
JL: Yeah, that's right. They get two very different experiences. They get, one, if you're signed, that gives you control. You can give a nice logo and icon, and it says, "Hey, look at this plug-in application, and it wants to do some things to your computer. Let's go along with it," versus the "it's not signed-in." It's like a big exclamation mark warning sign: "Danger. We will let you install, but..." type of thing. But yeah, ultimately they can, and then they've got that access.
But what's new with Silverlight 5 is the trust in-browser. And the way that they tackle [this], and this is just based on research and tinkering with this, it's a lot easier for developers because local host is just trusted. But if you really wanted to build an application and deploy, it involves registry settings to enable that level of trust. So the thought there is that it may make sense to deploy in-browser in some sort of an Internet environment, but we want to make sure that the administrators have access to set their appropriate policies on the systems to allow that type of access. You know, with the different tools for managing Microsoft networks, you can easily push out some policies that will make -- I say "easily," I don't want to trivialize it, but you can push out these policies and make those changes. But those involve a registry hack and certificates to get that in-browser trust.
CF: Jeremy, it's been a pleasure talking to you.
JL: Thank you for having me on. It's been a lot of fun.
CF: Viva Silverlight.
JL: Silverlight is not dead.
There's much more! You can find the full interview at dotnetrocks.com/default.aspx?showNum=737.
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.