Q&A

RIA Warrior

Microsoft's Brad Becker on Silverlight 2 and the enterprise market.

• By Michael Desmond
• 11/01/2008

Microsoft last month formally announced the Release to Web (RTW) version of Silverlight 2, ending a months-long beta cycle for the rich Internet application (RIA) framework and runtime. With its encapsulated subset of .NET Framework and a shared foundation of tools and architecture with Windows Presentation Foundation (WPF), Silverlight 2 opens an important new flank in Microsoft's development business.

A key person behind the development of Silverlight 2 framework is Brad Becker, Microsoft's director of Rich Client Platforms. Previously a senior product designer at Adobe Systems Inc., Becker was the lead designer for the Adobe FlexBuilder dev environment before coming to Microsoft in 2005 to work on the Expression Suite, WPF and Silverlight projects.

How did you end up with Microsoft after years with Macromedia and Adobe?
A lot of it came down to the fact that I spent the last year there actually building -- working on the consulting team at Macromedia, building solutions for clients, including the beta of Yahoo! Maps when they redid it in Flex for a while. As you know, they just kind of canned that and went back to AJAX.

But what I was running into was Flex was really good for starting a project, but it was really hard to finish anything with it. You'd start running into issues with performance and with scalability and things like that. So we'd end up having to go back to the metal. You'd have to dig into Flash itself and hand-tweak things in Flash, and then you'd be back into the morass of movie clips and timelines and cell-based animation.

	"It's kind of hard to get the vice president of marketing at some company excited about LINQ to SQL. But you show them Deep Zoom and they say, 'Wow, I want that.'"
Brad Becker, Director of Rich Client Platforms, Microsoft

So there was frustration with the technology?
Flash was designed for doing cartoons on the Web; It's actually really good at that. But at the end of the day, anytime you use a high-level framework, there's always times when you have go below the framework back to whatever is underneath. So it was still a pain.

At that time Microsoft had already been public with XAML and with WPF for quite some time. And right after I got to Microsoft, we realized that we wanted to have a cross-platform version of .NET and of WPF. It was great that you could build these sophisticated and powerful applications on Windows, but customers sometimes needed to provide something that spans platforms. And sometimes they just needed something that could run in the Web browser and could be deployed that way -- easily and lightly with a small deployment package.

How were you involved in the formulation of the Silverlight vision?
I advised the Silverlight team early on that video was what was hot on the Web at the time. And they made the right decision.

With a V1 product you can't do everything. You really have to pick what you want to be good at. The other thing is we really pushed on Deep Zoom as well, to make sure that was in, because we really wanted some innovative features that would move the needle on what you could do on the Web.

We have a lot of great developer features, and that's one of the strengths of our platform and our tools. We also wanted to have some cool things that our end users would say [are] great. It's kind of hard to get the vice president of marketing at some company excited about LINQ to SQL. But you show them Deep Zoom and they say, 'Wow, I want that.' You need those kinds of things in the platform to get it off the ground.

We're hearing reports that Silverlight 2 RTW breaks existing code developed for the prior Silverlight betas. How should developers work around this?
With the beta it was a go-live program. Businesses were supposed to contact us if they wanted to go live with it. And everyone who went live with it and contacted us as they were supposed to has been contacted by Microsoft; [they] were contacted early with a little bit of warning regarding the fact that they needed to upgrade their sites.

Now that that's over, the automatic upgrades are going to be kicking in for all the Silverlight 1 and Silverlight 2 beta users who had update turned on. So they do need to get their sites upgraded to the RTW.

Now, for many sites there will be very minor changes -- for some people it's just a recompile. But beta 2 sites will not work with the RTW player.

What's the migration outlook going forward?
We actually don't plan on doing big betas, go-live, that kind of messy stuff. I won't promise that it will never happen again. The reason we did it this time was really for the Olympics. We wanted to deliver a lot of stuff in Silverlight 2.

But the Olympics needed to go when the Olympics needed to go. The plug-in was in pretty good shape for beta. Obviously we pulled off the entire NBC Olympics site using a beta plug-in. From my experience and others in the forums I was reading, generally people have had pretty good experiences with the site. So we made a one-time exception, mostly because of the Olympics. But also because this was the first time we were adding .NET and so many other features and things that were a really big deal.

We were doing a lot of really foundational stuff this time, so we had to make a lot of substantial changes. Most of the future releases of Silverlight will be mostly about incrementally adding on top of what we were doing, so there should be less breaking changes.

With its encapsulated .NET Framework support, Silverlight 2 is obviously far more than a media vehicle, but it seems like we aren't seeing a lot of emphasis on line-of-business app dev yet. Why?
One of the things that we're working on -- and I can't give you dates for anything, but we're trying to do in the next year -- is kind of a design 101 for developers. Some of the basic, top 20 things you need to understand about design as a developer to kind of prevent the major faux pas and to deliver a better experience.

The other thing we're going to do is we're actually looking at creating some tools that will help developers do basic designs. And we're going to create some more scenes and skins for WPF and Silverlight, where you can reskin/rescene the controls, the basic Silverlight controls.

Those are all things that are going to help developers do better applications that need some design. I think, for most business apps, you're just talking about following basic usability rules, a lot of which haven't changed since WinForms or even since Win32 or Win16 applications. Some of this stuff is basic -- how to lay out controls. There's also going to be sample apps that we deliver, and we're hiring designers and developers to work with us on those. So there's actually quite a bit coming out in the next year for .NET, WPF and Silverlight.

How does Silverlight development fit the needs of corporate application developers?
When you look at business apps, generally they're not well funded or well staffed. You're having them make do. If you're somebody working on an internal app or a typical line-of-business application or departmental application, you don't get a lot of resources to do that. And so you're just trying to get the job done as quickly as possible.

That race is going to go to whoever can really make it easy and cheap to build quality applications. It's a problem we've looked at before with both Visual Basic and ASP.NET, and even Microsoft Access. Microsoft has a history of delivering in that space for people who need to just get the job done and deliver something good with a small amount of effort.

I think for the more custom types of business applications, where it's more of a strategic initiative for the business and it [involves] better resources, we're in fantastic shape. I think we have the best tools and we have the best platform for that. Again, it's in our DNA at Microsoft to support developers who are building applications.

Who are you targeting with Silverlight 2? Are you hoping to win over Flash developers?
We wanted to basically do some significant innovation in the way that people can build apps using declarative syntax and have richness of UI. The domain has changed; the bar has been raised by customers. But we want them to be able to preserve the knowledge they already have of our tools and platforms, like .NET and the way classes work, and they can continue to use VB.NET and C#.

We wanted to bring all those people into the RIA space. We also wanted to make it possible for people who are doing Ruby development or working with Python -- we have IronRuby and IronPython support for now with Silverlight as well. Somebody coined the term 'ARAX' and 'APAX' applications.

It's not really so much about converting people who are perfectly happy doing Flash. If you're really happy doing Flash or if you're building cartoons for the Web or whatever, by all means keep doing what's working for you. But there are a lot of people right now who have looked at the various other frameworks and other alternatives out there and have found them wanting.

What challenge do Adobe Flash and Flex pose to Silverlight in this space?
Long-term, the biggest threat is really the threat of mediocrity -- the threat of good enough.

Again, cartoons on the Web -- I definitely concede that to Flash all the way. I think that if you really want to build scalable, secure business applications that are maintainable [consider Silverlight]. If you've ever tried to open up somebody else's Flash project that is a legacy thing and work on it, try to find where the code is hidden and all that stuff. I've had to do that many times and it's a nightmare.

I think we've got a pretty time-tested way to build applications. That's going to be a strength for us.

With WPF being a superset of Silverlight, in theory I should be able to write a Silverlight application and have it ready to roll on WPF-enabled desktops. Is that right?
I don't want to say that it's free. Anytime anybody in this industry tells you something is completely effortless, run for the hills. It's really very, very compatible. Our goal is to make things 100 percent superset. But it will never exactly be that, because we want to continue to innovate on both platforms as well. So certain features like Deep Zoom are not in WPF yet. But we'll keep rolling anything we innovate in Silverlight; we'll roll it back to WPF as well.

So what should developers keep in mind if they hope to also port their Silverlight apps to WPF clients?
You have to know the differences. You want to know what's not in them. WPF has full 3-D, it has triggers, there's a few other things that it has. It's important to know the limitations of the platform. Or just to stay with Silverlight for both, and then add on what you need to in WPF.

Another thing is clearly you want to stick with the same language. You can use the same tools still when you're working on it. But the biggest thing, honestly, is people say start with Silverlight, because it's a lot easier to start with Silverlight and then add to it than it is to write a full WPF app and then rewrite the portions that aren't in Silverlight.

Mobile is a fast-growing segment. What's the outlook for code reuse between mobile and desktop?
When you go to target a mobile device, it's such a different form factor: it's different I/O, different usage patterns for the user. So I think most of the time people aren't going to want to run the exact same UI on a mobile phone that they do on a desktop or a laptop. I think you have to make changes for the user experience to be good. But the business logic should be the same, and certainly you aren't going to have to learn a bunch of new tools, new languages, new frameworks.

There's Silverlight support in the works for Windows Mobile and for the Nokia 60 Series. Any other mobile platforms coming online?
We haven't announced anything. We're basically working through, talking to partners, trying to get so we can be everywhere they need us to be. Scott Guthrie mentioned the other day that if Apple opens up the iPhone, we'll go to the iPhone.

Tell Scott good luck with that.
Thanks. We'll need it.