Windows Presentation Foundation is one of the most interesting new developments in .NET 3.0, we sat down with WPF trainer and author Ian Griffiths to talk WPF, Silverlight and what Microsoft has over the competition.
What do you think is most exciting about WPF?
So the biggest thing for me was that it was something of a "Finally!" moment for me when I saw what they were doing, because there's lots of irritations that you run into with Win32 development of user interfaces, and in particular the way that none of the pieces fit together. You could do 3D, or you could do video, but doing both together was a pain in the neck, and if you wanted to do user interface components like buttons and listboxes in conjunction with these it becomes sort of impossible to mix everything together.
If you want to have a mixture of video and graphics, 3D and text you don't need to have different platforms.
On the advantages of WPF.
WPF integrated all these things into a single platform, so if you want to have a mixture of video and graphics, 3D and text you don't need to have different platforms. It's not like having HTML, Flash, Win32 and DirectX — it's all just the one platform. You can combine these things — it's not that you can put rotating video on a button — that's not actually so interesting, it's more that there's no limitations. So for example for the BBC we've been using video, in conjunction with presenting a lot of information through data binding. It's being able to use both in the one application and not have to have one thing that looks like a windows app, and then have to flick over to something that has a video thats playing, we can just integrate it and have it feel like a single consistent application. That would have been essentially impossible without WPF. It's enabling those sort of combinations that would have been much harder.
What's the benefit of the separation between the business logic and the user interface in WPF?
Well that's important in all user interface areas to be honest, I mean if you look at something like web applications they've been doing this sort of thing for years. And I'm sure we've all worked in a few applications where all of the logic was in the HTML and it's just horrible to do that. So separation of concerns really is just a good principle. So WPF is just about learning the lessons that have been learnt elsewhere in the HTML world. But, you could argue we've had that before in Windows Forms, you've got the design surface and the code surface and it sort of feels the same, but the big difference with WPF is that now we've got a markup language, the XAML representation of the user interface. You can have tools that are able to work with the user space that are not developer tools, whereas with Windows Forms it's really all code under the covers, so when building a tool that is able to design a user interface, you've got to include a build system as well, it's really a developer tool.
With WPF it doesn't have to be that way, you've got things like Microsoft's Blend tool, which is able to build XAML. So too is their drawing package, Expression Design. Then you're also seeing plugins for things like Illustrator being able to export directly into XAML, so designers can use the tools the already know to construct markup that can be dropped into the UI. That sort of thing really wasn't possible with Windows Forms. Again, it's stuff the web world has been doing for awhile, you've had things like Dreamweaver and Frontpage that have just focused on the markup. WPF brings that kind of design with all the benefits of being able to run on the client side as well, the full access to security controls and hardware and so on.
So if you develop something in XAML, can you use it both as an application and a web page?
Short answer is no, and this is something that's widely misunderstood about WPF. Largely because for a while Microsoft were using the slogan: "Best of the web, best of Windows". People assumed you'd be able to build one thing that would automatically work in both places. And that's not quite how it is. It is possible to build an app that will run in a Web page, we have these things called XBAPS, XAML Browser applications, but that requires WPF to be installed on the client side to run the application, so it's not going to work on Mac OS X or on Linux, and it's not going to work on a Windows PC that doesn't have the .NET 3.0 framework installed. If you do have the .NET 3.0 framework installed then it'll work just like a WPF application inside a browser frame, in that case it'll look exactly the same because it is the same. But the thing to understand that the extent to which you can build stuff that will actually work is quite limited because it requires .NET 3.0 on the client side.
A lot of what makes WPF really interesting to developers just isn't there in Silverlight.
There's also Silverlight, as it's now called, formerly called WPF/E. That actually moves the boundary a little bit, the idea there is to address a much broader range of hardware so that will run on Mac OSX, both power pc and the intel versions and it will run outside of IE, it runs on firefox as well. But there it's not really using WPF. It's using XAML, so it's the same family of markup language, but its a fairly limited subset of XAML that it supports, so you don't have data binding, you don't have layouts, you don't have controls, you only have a limited version of the event model. It's a very, very small subset, and to be honest a lot of what makes WPF really interesting to developers just isn't there in Silverlight. This is because they're trying to fit it all into a very tiny download, they're trying to get the rendering, the runtime, the video playback all into a download that's measured in one or two megabytes, rather than the forty or fifty megabytes it takes to get all of .NET 3.0 on your machine. So inevitably you have to pay a price in terms of flexibility.
You can build a Silverlight app but it's not really all that meaningful to build one that works both as that app and as a full WPF app at the same time, there's no real path to doing that right now. Maybe the tools will emerge in the future, because it's very early days for Silverlight, but at the moment if you're doing Silverlight, you're doing Silverlight and it's browser only, if you're doing WPF and XBAPS then they'll look the same so long as you can count on .NET being on the client.
Do you think theres any reason why Macintosh was chosen specifically as a platform for Silverlight?
Well I think it's partly making a statement about the cross platform nature of the thing, this is not just about Windows. By showing, look it runs on Mac, it runs on Firefox, it runs on Safari, it runs on all these different processors, it's their way of saying that it's not the same as WPF. You don't need to have this Windows specific platform to run this thing. As to why they would do that beyond the statement, why would they want to make the statement in the first place, it's because they recognise that theres a whole class of people who are not running Windows, and they want to be able to reach them. They want to say "Look, you're not locked out of Microsoft technologies just because you have people running Mac OSX."
It's a small but a significant portion of people running computers, and in particular, even though it's a small fraction of the overall PCs in use, in certain industry sectors it really dominates, and if you look at where Microsoft seem to be going with things like the Expression Suite which is gradually coming together they want to be more in that world than they are, so they pretty much have to embrace Macs, since they're quite big there, otherwise they're not going to be taken seriously. So it's just a question of reaching the whole market they want to address.
Where do you see the future of XAML being, is it being used outside of WPF?
It tends to work a lot better when the framework has been designed with XAML in mind.
It already is in the Workflow Foundation, which is part of .NET 3.0, it's the same language although it's not the same compiler, since they have different things they need to do at build time, but it's the same specification. So it's been demonstrated that it's the kind of thing you can use in a broader scope. Where it's natural applications will be is less clear, because one of the things about XAML is that although you can build more or less arbitrary trees of .NET objects with it, it tends to work a lot better when the framework has been designed with XAML in mind. So you can build a Windows Forms app in XAML but it's a lot easier with WPF, because every API feature they designed they said "How's it going to look with the markup in mind".
With Windows Forms you never had that because that was never part of the design brief. So you sort of need APIs that have been designed with XAML for it to work, it's not the kind of thing you can bring to an existing technology and harness that technology with it unless you're lucky, it's more something that needs to be thought through. So I don't expect it to just be bolted on and enable things in other areas, what will happen is that people will look at it and say "Oh that works quite well for Windows Presentation and for Workflow, can we do something similiar to that?" But I think that will take some time, I mean look at how long it has taken for .NET 3.0 to get out the door, it's essentially an API design issue, and API design is a slow and complex process.
I don't know in the long term where its going to go outside of where it is already, we'll just have to wait and see for that. At the moment the obvious direction for new things to appear based on XAML is WPF specific tools that extend whats available from Microsoft. I think we're going to see more drawing tools supported, more third party equivalents to Blend, for instance, because at the moment Blend is the only thing that does what it does, it's a very WPF specific thing, it builds WPF user interfaces, nothing much else does that. Right now all the other things thats support XAML do so in export only mode, you can go to Illustrator and say "spit that out as XAML please" and it's a one way trip. Whereas Blend understands XAML, so what might be interesting to see are more tools that work with XAML that have an intrinsic understanding of it, either to do things like what Blend does, competing products or by extending that space, tools that can help you work with XAML. Now I don't know quite what that could be, but theres a lot of scope there simply because XAML is so easy to parse, it's just XML, its not hard to read. So I'm looking forward to seeing what people come up with there.
There's a lot of options recently becoming available for a platform to develop Rich Internet Applications, and that's one of the areas WPF is aiming at. Why would a developer choose WPF over say Apollo or XULRunner?
It depends of course on what your target platform needs to be, because some application areas you can just say a Windows platform is a given, particularly if you're building something that needs to be a rich application but is going to have a limited scope: say if you know exactly who's going to be running it. For the last project I was doing earlier this year, this was exactly the case, we were building an online application, but it was invitation only so we were able to say exactly what would be running it. And at that point you're able to narrow down the platform it enables you to do things that you wouldnt otherwise been able to assume, you can do all these things with graphics, we can have this much going on, we can do this much with video, we can maybe do high defintion. All these things that would have been much harder to do if you were going for a broader scope.
It's the classic lowest common denominator versus narrowing your scope problem, you've got to choose one or the other. Because WPF is up that end of the spectrum where you are assuming that you're working with a PC that is capable of running .NET 3.0 and a relatively recent version of Windows, it is therefore prepared for WPF. You've already decided that you're limiting yourself to that scope and you get to take advantage of that, whereas if you look at things that have a broader reach you've got the advantage of being able to reach more machines, but you've got to give something up for that, there's always a tradeoff. So WPF is partly interesting simply because it's at that extreme.