Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

Beyond HTML: Rich Internet Applications


:P
On this page:

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.

Posted in WPF  Silverlight  

The Voices of Reason


 

Speednet
April 15, 2007

# re: Beyond HTML: Rich Internet Applications

Terrific article Rick! Thank you for the enlightenment. This is one technology (WPE/XAML) that I just haven't been able to take the time to sit down and learn, so I appreciate the Cliff's Notes version here (with analysis). How does anyone find time to learn all this stuff?

anonymous
April 15, 2007

# re: Beyond HTML: Rich Internet Applications

I did not see a single mention of SVG (scalable vector graphics). SVG is a W3C recommendation to handle graphics and has been around for years and years. The only problem with it is that MS, a W3C member refuses to play nice and include SVG support in its browser. Too bad, it could have been the contender using XML in a cross platform independent solution.

Stacy
April 15, 2007

# re: Beyond HTML: Rich Internet Applications

Fantastic Rick! Thanks for putting all this stuff in one place with great analysis and comparisons. Saved me years of work! You da man!

Brett
April 15, 2007

# re: Beyond HTML: Rich Internet Applications

At our company, we're seriously discussing migration of a rather large ASP.NET 2.0 Intranet application to Flex. I don't want to, but its mostly because I'm bigoted against anything Flash. There are two major parts to the discussion. Movement to a centralized, service based architecture that is independent of the front-end, and a Flex/Flash UI, because its pretty. Its tough to argue about the ned to rearchitect the non-Presentation code that is in the ASP.NET application to make it front end agnostic. Which then makes it easier to argue that after that, rewriting the front end in Flash isn't as big a deal as it first sounds. Part of my reluctance to the move is the ignorance of upper management, and I do not know how to counter it. They believe that its "real easy to build a Flash interface. Its all just web services that the client can call." They don't think the Flex developer needs the same skill set an ASP.NET programmer needs. Perhaps they're right, I really don't know. I do know that I have yet to see Flex app demos that exhibit functionality like we're going to need. Like integration with Windows authentication, and functionality similar to Forms Authentication. Personalization, on any level. I've yet to find a complex Flex demo of something like a complex Intranet application. What I've seen are quick demos of simple web pages, so if any one has any examples (good or bad), please identify them. Theres a perception that big ASP.NET applications are difficult and time consuming to implement (mainly, because people ARE); theres a perception that things like Rails or Flex/Flash offer an easy (yet unproven) alternative. Do they?

ajaxus
April 15, 2007

# re: Beyond HTML: Rich Internet Applications

@anonymous

I would like to say that SVG is way out of the picture. There are several factors that are seriously on the way to provide multiplatform solution:
- Adobe officially anounced that will stop supporting that format
- Creating SVG application isnt piece of cake and sometimes supporting these is also trouble
- There isnt native browsers support, you will need to install viewers to play SVG

Rick Strahl
April 15, 2007

# re: Beyond HTML: Rich Internet Applications

Todd, I hear you. I'm in the middle of 'enlightening myself' with .NET 3.0 and especially WPF and it's not an over the weekend type of affair <s>. I love what I see in WPF but the lack of general purpose tool support and lack of out of the box controls for many common things really makes it hard to even think about putting it into a production scenario even for internal stuff at the moment.

Brett - great comments. I've seen your exact scenario play out at several companies that I've worked with, although they quickly wisen up to the fact that development with Adobe tools is no picnic either. There are no silver bullets. Flash applications (and if Microsoft gets their act together WPF browser apps) are really distributed applications so dealing with authentication and security are big issues to deal with and without a native service architecture that's not trivial to implement (although possible). That's why I mentioned above that I think its crucial that Microsoft consider making WCF available in WPF because it's one thing that can provide that infrastructure using a common tool. But that of course is going to cause problems for the cross platform functionality.

There are no easy solutions, but I have some hope that this technology will be getting wider traction in the future because the potential here IMHO is much better than the hack and complexity in the wrong place that is AJAX.

anonymous
April 15, 2007

# re: Beyond HTML: Rich Internet Applications


Adobe is dropping support for their SVG add in that allows IE to render SVG. MS should have had native support in their leading browser especially since they are part of the W3C. It is pathetic at best that this is still not there. It has to be aoubt the money trail why Adobe is dropping their SVG addon for IE and why MS decided not to provide native support.

Somehow Opera and FireFox have native support for SVG why is it soo hard for MS?

I have created a lot of SVG content and do not find it very difficult and do find it to be incredibly powerful.

Steve
April 16, 2007

# re: Beyond HTML: Rich Internet Applications

It looks like MS released it's codename of WPF/E this morning. "Silverlight". http://www.physorg.com/news95944421.html

Thanks for the overview.

Luke
April 16, 2007

# re: Beyond HTML: Rich Internet Applications

Rick, thanks for the great overview. I am in the process of deciphering WPF myself. Following are some links for those interested; any help in establishing a nice knowledge base about WPF would be appreciated. http://luke.breuer.com/webmark/?cmd=wpf

"if a developer doesn’t need remote Web access that functionality isn’t loaded"
I find that statement deliciously ironic. :-) I guess you could mean static loading and not dynamic loading, or a clunky XmlHttpRequest loader.

Rick Strahl
April 16, 2007

# re: Beyond HTML: Rich Internet Applications

Luke maybe that wasn't the best example <s> - I suppose I'd always use HTTP functionality on the client, but being a graphics centric platform I could see many applications not requiring dynamically loaded content or getting by with pure Uri based loading. I was referring to a more full featured built in Http client (even if it's just passthrough for XHR).

I hear you on 'deciphering' WPF. It's going to take quite some time to assimilate all that functionality built in - which is why I lament that Microsoft didn't spend a little more time providing more out of box content and especially for focus on line of business scenarios which is likely to be the starting point for most people. The fancy stuff comes later <g>...

Silverlight - what were they thinking? Talk about a cheesy ass name...

Steven Black
April 16, 2007

# re: Beyond HTML: Rich Internet Applications

Awesome article, Rick! One of the best I've read in a long time.

Five dollars says Google will ultimately be dominant in this space within 5 years. It's just a hunch.

Heck, if we're talking widely distributed rich apps, Google is already dominant. And they are doing this with nothing but Javascript.

If Google teams up with Adobe, formally or informally, well then it's all over for Microsoft in this space.

It's been said that God create heaven and earth in seven days primarily because he didn't have an installed base to deal with. Microsoft's installed base in this space is arguably bigger than Google/Adobe, but can you picture it in a worse mess? Hard to imagine it being worse. And what you describe is a worsening of it.

Feeling cynical today, as you can probably tell :-)

Rick Strahl
April 16, 2007

# re: Beyond HTML: Rich Internet Applications

Steve - you cynical? Naahhh get out of here <g>...

Well AJAX isn't out of the running. Even with RIA gaining some momentum, HTML based UIs with AJAX vastly outnumber anything else. But the problem with AJAX in the mainstream is that it's still very complex and flakey and I don't see that improving. The architecture of AJAX and HTML with this much complexity layered on top of it is sshakey. And the effort that goes into the frameworks to work around browser incompatibilities is immense and severely error prone. It's no accident that these days half the sites you visit have JavaScript errors on them.

The only way I can see this getting any better if HTML standards (or a related 'application' standard) will finally move on and start including a richer control model e rm on the client. I don't see that happening but anything is possible I suppose if there's enough pressure.

I'm not sure I see how Microsoft's installed base with Windows would hurt anything. The real key is that whoever builds the dominant RIA platform will have to work on all platforms. I'm sure Microsoft is perfectly capable of creating the cross platform capabilities - the question is whether they'd commit to it. After all it would undermine the value of Windows...

DaVinci
April 17, 2007

# re: Beyond HTML: Rich Internet Applications

What about Smart Client technology? Can it be used for RIA? What do you think of Smart Client and business apps?
I'd appreciate your thoughts on this.

Alex Feldstein
April 17, 2007

# re: Beyond HTML: Rich Internet Applications

Excellent article Rick! Even though I attended to some WPF and WPF/E ('xcuse me, "Silverlight") presentations while at MS recently, your article puts it all in perspective. Great way to get some kind of Cliff notes. Well done!

Andrew
April 17, 2007

# re: Beyond HTML: Rich Internet Applications

Great article, Rick - but what about Adobe's Apollo platform? Wouldn't you consider that a rich internet app development platform?

I don't like Flash either but it would seem that this would/could become a major issue for the full-blown success of WPF/e - among other things.

It seems to me that the development world is actually more like it was in the DOS days when everyone was hedging their bets on which would win : Windows, OS/2 or something else - except now we're dealing with the web instead.

CJ
April 17, 2007

# re: Beyond HTML: Rich Internet Applications

Another great read Rick. I have to admit that the last two big projects that I was on both were vb6 -> asp.net/ajax conversions and BOTH got halfway through development and were re-architected for clickonce and wpf because ajax still doesn't allow you to throw 30 infragistics web combos on a page. Some presentation layers just don't work well with html and probably never will granted time and a hardware refresh might change that.

When there's a preexisting expectation of the thick client experience, even ajax doesn't cut it. I'd like to see more of this clear separation of layers. The asp.net code behind model doesn't give you the ability to cut with clean lines where ui starts and the last layer stopped. throwing cab and things like ioc into the picture just complicate things. I'm all for the service model. I think Flash is there but they never got it right for the developer. It wasn't until flex builder that they released something with intellisense. Flex is nice but it just adds more overhead and is an abstraction for people who aren't core coders.

Even with wpf, a jump right into the c# and start coding. I'll probably never jump into xaml as the core language. It's handy but i still like to code the UI.

Alex Feldstein
April 17, 2007

# Alex Feldstein: Great article: Beyond HTML: Rich Internet Applications


Zubair.NET!
April 18, 2007

# Zubair.NET!: Microsoft Silverlight (previously WPF/E)


The midnight coder
April 18, 2007

# The midnight coder: Everyone's talking about RIAs now...



July 07, 2007

# 本周ASP.NET英文技术文章推荐[04/15 - 04/21] - Dflying Chen @ cnblogs - 博客园


West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024