Rich Internet Applications (RIA) is a term used to describe non HTML based, low impact Internet applications. RIA’s typically run in the browser (although they don’t have to) and get their data from the Web server over HTTP. One of the big selling points of RIA’s is that they provide many of the benefits of HTML based Web applications, but without the limiting HTML interface, instead replacing it with a richer user interface framework that allows presenting of a more desktop like user experience.

This is a concept that has been a long time coming and is slowly picking up steam. Some years back I wrote a column for CoDe that (wrongly at the time) predicted that this type of application would soon replace pure HTML based applications because users would no longer put up with arcane HTML based interfaces. The other thing at the time that prompted my original editorial was the fact that Web based data access via standardized XML services and official SOAP based Web services was starting to take shape.

Well, it didn’t quite happen that way. Today in 2007 we’re still looking at HTML as the king of the hill especially in corporate application development because HTML is often perceived as the ‘easy to deploy’ and ‘works everywhere’ technology and for many a company that’s where it starts and ends. Add to that the recent revival of the HTML flame with the emphasis on AJAX and its focus on providing richer and more interactive user interface in the browser and you have a deep rooted handicap in favor of HTML based Web applications.

But as new and more powerful user interface frameworks emerge many people are asking the question of why they should continue to fight with the browser and its inconsistencies and limitations to build rich UI’s when there are much richer alternatives becoming available. A lot has changed in the way rich applications deploy as well and it’s now possible to build even desktop applications that can automatically deploy and update themselves.

A number of these alternatives can provide most of the benefits that the HTML platform provides, but add a much richer client front end that allows for easier creation of user interfaces, and especially of sophisticated user interfaces that take advantage of media and extensive graphics.

The Industry is recognizing the need – finally!

Things are slowly changing. Over the last couple of years there’s been much more discussion and investment from the major vendors in building rich client platforms that can provide the benefits of a Web application without relying on HTML based interfaces. In the Microsoft world the effort has been centered around the new and fledgling Windows Presentation Foundation which shipped last November with Windows Vista, and for Windows XP and Windows 2003 server. Various flavors of WPF have the ability to run inside of the browser. Adobe last year released Version 2 of its Flex framework as a major update for this Flash based user framework geared towards building line of business applications, and this product has enjoyed great popularity since its release. Microsoft doesn’t have a comparable Web based UI framework at this point, but WPF’s overall design and concept is much more developer friendly than the Flash platform as a whole and there is some hope that Microsoft will better address the browser hosting scenario with a new lightweight WPF version called WPF/E(verywhere) that will run on multiple browsers on Windows and the Mac (initially). Let’s take a look at some of the contenders.

Windows Presentation Foundation

Windows Presentation Foundation (WPF) has now been out for nearly a half a year. I’ve been following WPF for some time more or less from the sidelines because, frankly I’m not quite sure where the sweet spot for WPF is at the moment. WPF offers a new display engine for the Windows platform that provides very rich graphics and media functionality and many advanced features that were previously unavailable in the WinForms platform. WPF mixes many different concepts including WinForms for the windowing metaphor, HTML based flow and styled layout as well as markup using an XML based dialect called XAML, and the high end graphics and animation features of DirectX.

XAML is the XML based page layout language that can be used to describe a page or control layout using declarative markup. It’s easily one of the most compelling features of WPF because it provides an abstraction layer between code and design similar in the way that ASP.NET works with code behind pages where the design is handled in markup documents with code that operates on the markup in a separate file. XAML uses a very similar approach, but unlike HTML the XAML syntax is much more flexible in that it supports a rich set of operations that can be natively performed through markup. For example, animations can be run through a timeline through element and attribute definitions and markup based triggers can do things like databinding, set property values, even cause methods to be fired entirely through markup without ever writing any code.

Incidentally XAML is a key technology in .NET 3.0 that goes beyond WPF page layout: It’s a generic XML syntax that is specifically designed for expressing and persisting objects as well as operations. XAML is used for many other .NET 3.0 components like Windows WorkFlow and other domain specific portions of .NET 3.0. The WPF specific version of XAML is a design specific XAML dialect that works in conjunction with WPF and expresses the hierarchical control tree layout, styling and templating and resource embedding syntax.

Because XAML is XML based it is also inherently easier to create custom designers because rather than code generation a tool can describe a page layout simply by generating an XML document. This opens the door to third party tools that can generate XAML output easily and it also makes it possible to import XAML from other formats such Flash SWF.

The first version of WPF feels pretty low level leaving most of the presentation aspects and control creation to developers and designers. There’s not a ton of built in control functionality shipped in the box and most developers building day to day line of business applications will probably find using WPF a very tedious experience at best. It doesn’t help that currently tool support for WPF is severely lacking. XAML support in Visual Studio (through a beta .NET 3.5 Framework SDK) is horrible with a very slow to load XAML editor that crashes on even fairly simple XAML code and that cannot be bypassed for simple XAML source editing. And then there’s a sophisticated graphics tool called Expression Blend (http://tinyurl.com/2n6jvr) which is very slick but clearly focused at designers and not developers. This leaves the majority of developers who want to check out WPF with only a very inadequate toolset for designing their XAML. Thankfully there are a few third party products out that can fill the need. I’ve been having good luck with Aurora (mobiform.com/products/Aurora/aurora.htm) which is easier to use for non-designers and more responsive than Blend.

WPF in the Web Browser

One of the aspects of WPF is that it also has the capability to run inside of the Web browser in a variety of different ways. Although WPF is primarily a desktop technology, the capability to run a WPF application inside of Internet Explorer is available including the ability to automatically load the latest version of an application from a Web server.

This opens the door for some interesting possibilities. WPF itself supports two mechanisms for publishing WPF applications in a browser hosted fashion: XBAP (XAML Browser Applications) which is essential a specialized ClickOnce application that is hosted inside of the browser frame and Loose XAML which supports XAML only pages loaded from disk with the limitation that no code can execute in these pages. Both XBAP and Loose XAML have security restrictions when executing in Internet Explorer.

XBAP

XBAP basically is a full blown WPF application that is published to a browser via ClickOnce. Unlike full WPF applications XBAPs are special in that they are hosted inside the browser and must render inside of a NavigationWindow which is a special WPF top level frame control that provides a mechanism for browser style navigation from page to page. Although XBAP can run in the browser it’s still a full WPF application meaning it requires that .NET 2.0 and 3.0 are installed and that the application is run through Internet Explorer, so it’s definitely not a broad reach type of environment yet. But remember Vista includes the .NET 2.0 and 3.0 so the usage base will increase significantly over time.

XBAP also runs inside of the browser sandbox by default which means security is set to the Internet Zone: No local disk access, only same site HTTP access, no Reflection, no Interop etc.  However, you do get access to same server HTTP and network access, so it’s quite possible to build a rich UI with data that is retrieved from a Web Service or just a URL from the original hosting site. It’s also possible optionally to deploy XBAP applications in full trust in which case the user gets a warning dialog before executing the application for the first time, but after that the application runs in full trust with access to all machine resources.

Because XBAP is based on ClickOnce it enjoys the same feature set, which means installation is very easy – one click and the application loads and starts executing directly in the browser. The application also automatically checks for new versions when it’s run again, automatically detects changes and can then pull down any updated files automatically.

I often here people belittling ‘desktop’ technology because it’s not easy enough to update, but ClickOnce really has come a long way towards making a full blown application derive the same “store in one location and update everywhere” promise that Web applications have long enjoyed.

If you need rich UI that can’t be served by HTML and you can live with the Windows and you can dictate Windows and .NET 3.0 XBAP can be a good solution to provide rich Web based content inside of the browser.

Loose XAML

In the same vein as XBAP, WPF also allows loose XAML pages, which also require Internet Explorer and .NET 2/3. Loose XAML pages are simply codeless .xaml markup files that cannot contain or be associated with code or ‘code-like logic’ like databinding. Loose XAML is primarily meant as a graphics only driven display and is most useful for embedding as IFRAME content to provide rich functionality in an HTML document.

WPF/E

Late last year Microsoft also released a preview of another WPF based technology called WPF/E (for Everywhere). WPF/E is a light weight version of WPF that can run independently in the browser, without any requirements for .NET 3.0. The current preview is tiny – 1.3 megs in size – and can run in Internet Explorer 6 and 7, Firefox and Safari with both FireFox and Safari supported on the Mac. WPF/E is currently in the preview stage and available from the Microsoft Web site.

WPF/E is a small graphics centric subset of the full WPF, focusing mainly on the graphics and multimedia features of the framework. Most of the 2D graphics features of WPF are available in WPF/E currently, but there are differences and omissions that won’t quite allow straight across usage of full WPF code in WPF/E. If you want to use content in both WPF and WPF/E you have to carefully decide which features to use to make sure they are WPF/E compliant. Among the missing features are most of the top level panel containers of full WPF, databinding (that’s a big bummer!), the more advanced templating and more. However, it’s very early in the release cycle and Microsoft is still looking at which features to actually include in WPF/E so the current subset is not final and most likely will get bigger.

The current focus of WPF/E is on providing a rich graphics and multimedia engine that can enhance existing Web pages with functionality that is difficult or not possible to achieve with HTML by itself and provide it in a browser independent environment. WPF/E’s goal is to provide a dependency free installation that can be loaded into the browser with a single small download.

Microsoft has not yet announced the full plans for the WPF/E feature set and the current version is fairly limited in its feature set. WPF/E currently relies entirely on external JavaScript automation of the WPF content and is hosted in an HTML document using the JavaScript client script code to access the control and its content model (west-wind.com/WebLog/posts/16785.aspx). Any network connectivity or other interaction with the server needs to be handled through the HTML page interface and requires using an HTML based AJAX library like MS Ajax to provide the connectivity.

Since WPF/E controls are embedded in an HTML page, they can interact with the page and be a part of the HTML page.  One important feature of WPF/E is that it can create a windowless controls that essentially work with a transparent background, which allows overlaying of WPF/E content ontop of the HTML content (http://tinyurl.com/3945my). Windowsless controls can also be overlayed by HTML controls which is also important because WPF/E doesn’t include any input controls of its own. If you need user input in your WPF/E controls you either need to create the control manually via XAML layout and event handling (for key events etc) or you can use HTML controls for capturing input and passing the content to the WPF/E control.

Although WPF/E addresses the browser scenario in a safe and low impact manner, remember that WPF/E provides only a subset of the full WPF functionality. Many important features – like databinding, advanced templating, many of the top level control container panels and even any sort of input controls – currently are missing. This means it’s not going to be quite so easy to take existing WPF content and use it in WPF/E. Furthermore some work will likely have to be done to create basic control support if you require input of any sort inside of the WPF/E component. Currently your only choice is to use Html controls and pass that data into the control or create your own input controls.

But even these limitations aren’t stopping some very creative folks from going all out and pushing the limits of what you can do by creating the missing pieces on their own. Check out this Vista UX implementation running in the browser using WPF/E here: http://www.vista.si. It’s important to understand that much of what you see in this sample is custom created control content and is not ‘in the box’ of WPF/E. A lot of work likely went into creating the various control implementations. But this sample also demonstrates what is possible with the technology in the hands of creative people – it certainly opens up many possibilities for user interface magic that simply isn’t possible with HTML alone.

In my own experimenting I found WPF/E powerful yet frustrating at the same time, precisely because it lacks so many of the primitive features you take for granted. The features that are provided are squarely aimed at the designer set, not the typical developer building business applications. You can roll your own of almost everything though – it’s sort of like going back to Windows API programming of a Windows app after you’ve used advanced designer tools.

The good news is that Microsoft is still working hard on the design of WPF/E – according to early reports they are going to significantly enhance WPF/E’s feature set in the future. More information will be announced at this year’s MIX conference at the end of April. One feature that is particularly interesting is the addition of a small version of the .NET runtime that will be able to execute .NET code. This means that the logic driving WPF/E can be written using any .NET language. We’ll have to wait and see what features Microsoft sees fit for this version of the .NET runtime and whether it will result in a better encapsulation scenario than the current implementation.

My WPF/E Wishlist

I was excited to see the announcement of WPF/E originally because I was hoping it would provide a self contained client for building rich client applications that can be browser hosted. But the current model doesn’t address this scenario at all because it’s driven through HTML to WPF/E interaction only and doesn’t make it possible to really abstract functionality into a self contained component. Also the complete lack of control support and the powerful WPF databinding features really put a crimp in my usage scenario.

My hope is that WPF/E will eventually bring a component model that will allow creation of self contained modules that can be downloaded into the browser. My wishlist for WPF/E looks something like this:

• A component architecture that allows self-contained control creation
• Downloadable controls/resources (load only what you need)
• .NET embedded code support (not relying on HTML scripting)
• Support for easy network connectivity back to the host server
  At least basic HTTP support, but preferably Web Service support – something that can return typed data back to the client.
• WPF style DataBinding
• Basic set of input controls
  
  

I think the component model for WPF/E can’t be overstressed! Components/controls and extensibility have always been enablers for Microsoft technology in the past and I think it’s no different this time around as third parties can then pick up the slack of the native platform by providing control functionality that Microsoft is not ready put in the base line itself.

But it also seems to me that a component model would allow Microsoft to deliver a relatively small core runtime with additional modules that get downloaded as needed only - so if a developer doesn’t need remote Web access that functionality isn’t loaded for example. Keeping the footprint small is a big concern for Microsoft and is in line with the tiny 1.1 meg download for the Adobe Flash player.

Personally I’m more concerned over a functional engine than a tiny download size. If the engine is small to download but doesn’t serve the needs to address common business scenarios the technology becomes worthless. Functional first download size a distant second please.

Microsoft has additional strict limitations they have to deal with in WPF/E: The core engine that they provide has to work on multiple platforms and whatever version of .NET plugs into WPF/E and any of the advanced graphics and media features must also support these other platforms.

Why not Flash?

So WPF/E is a light weight browser hosted interface for providing rich graphics, media and animation. Hmmm… that sounds a lot like Flash doesn’t it? The first question that comes to mind is, why would you want to even consider using WPF/E and not Flash given that Flash is ubiquous with nearly 95% browser penetration?

For all the advantage that Flash has in installed user base, the fact is that Flash hasn’t made big inroads beyond the designer market and certainly very little in the Microsoft community. Flash today is used primarily for movie viewing, banner ads and some very visually appealing Web pages. However you’d be hard pressed to find distributed applications that are taking advantage of the Flash platform to drive a distributed business application with rich distributed data access to the server.

Flash has the capability (it has both HTTP access and Flash Remoting for example) but to date this functionality has not been widely adapted, primarily because Flash is widely viewed as a ‘design’ tool rather than an application platform.

But this is changing, especially recently since Adobe has introduced Flex which is more developer centric frameworkthat runs ontop of the core Flash engine. Flex provides access to the core Flash engine as well as providing a rich User Interface and Forms centric framework that is quite capable of creating attractive line of business applications that mix both necessary form based UI basics as well the visual pizzazz of the flash framework to provide visual effects in a straight forward manner (ie. you don’t necessarily need a designer to skin a Flex app!). Code is written using the ActionScript language which is a ECMA Script derivative nearly very identical to JavaScript , that can script the framework. The framework provides core services like Http access, Xml and Web Service data parsing using a very WPF like data pathing binding mechanism.

It’s kind of ironic to see Adobe – the big design company – taking steps to move into the developer and enterprise market, where Microsoft – the developer centric company – is moving in the other direction trying to appeal to the designer crowd.

Is it time yet?

I’ve been involved with two projects since the beginning of the year that have Flash front ends to a couple of very sophisticated line of business applications. These applications aren’t especially flashy (pardon the pun), in that they present fairly standard but very dynamic forms based user interfaces. One is a financial application that displays a variety of financial data in a myriad of different ways and views that update dynamically in many places. The other is a very heavy data entry application for a catalog company. The former is meant as an open access, broad reach application while the latter is an Intranet app used across several offices around the country.

Although there’s no high end design features the applications look beautiful with rich designs and visual effects like shadows, sliding windows and menus etc. – in other words they look more like desktop applications -  better even because of the built in visual effects that you currently don’t even see in Windows applications. These applications – when shown to customers and investors - are real head turners because they are functionally way beyond any HTML interface that most people are familiar with. The point is that once you see applications like this that provide richer user interface layers that can be implemented using non-HTML based UI logic, it’s hard not to look at this and go: “I want to build apps like that!”

This goes way beyond Flash and Flex or WPF or WPF/E, but just comes back to a basic concept that HTML based applications often feel like a hack when compared against the state of the art of what’s possible with the hardware and frameworks available to us today.

Certainly Flash now has an attractive platform available in Flex and Adobe is also scheduled to bring out its Apollo desktop platform that will compete head on with WPF. Microsoft will have an uphill battle in this competition, because of its lack of the cross-platform angle, but also because Microsoft currently appears to be pushing the designer aspect of WPF more than the developer aspect and in the process is keeping the hordes of Microsoft trusty developer base out of the loop. This is unfortunate because I think that the sweet spot of the market lies in the middle ground of rich client, line of business applications both on the desktop, but more importantly inside of the browser.

I can’t tell how many times over the years I’ve heard people ask me how to build a more desktop like experience inside of a browser application that provides the benefits of Web applications without the headache of HTML based limitations. There’s real demand in this space and Microsoft is at a big disadvantage because of the platform independence issues where Flash clearly has the advantage.

If Microsoft wants to be successful in the browser RIA space they have to aggressively pursue the cross-platform angle which is the only way that the technology will be taken seriously, no matter how great the functionality. A lot hinges on what Microsoft will deliver with WPF/E and whether they can hit the developer sweet spot and deliver efficient cross platform support that can compete with Flash/Flex/Apollo.

It’ll be real interesting to see how Microsoft plays out this particular challenge.