Thursday, May 15, 2008

RIA == Platform Play

The shortness of the collective memory of the development world depresses me sometimes. Joel Spolsky has a great blog post from 2004 entitled How Microsoft Lost the API War. In it, he describes the real Microsoft crown jewel that lead to their domination of the personal computer: the Win32 API. If you were writing software in the mid-90's, you were writing it to the Win32 API. You might be using Visual BASIC, Delphi, PowerBuilder, Visual Objects (all 2 of it's users), FoxPro, dBASE for Windows (all 4 of it's users), etc. But you were writing desktop applications that ran on Windows. Then, Netscape came along and showed everyone that you could write software to open standards. Even though Microsoft eventually trampled Netscape, the damage was done: now you could write software that ran in browsers. Of course, Java had the whole "write once, run anywhere" mantra going, but building desktop applications in Java sucked then and it sucks now. Only a few companies have ever done it well (like JetBrains). Netscape's enduring legacy was that writing to standards (like HTML, CSS, eventually DHTML and JavaScript) was, while painful, possible. You can create rich applications where no one knows or cares in which language it's written.

Fast forward to today's development world. We're used to the pain required to write good web applications. We've got Ajax frameworks to smooth over the painful parts of JavaScript, people actually understand CSS, and you can build compelling applications on the web. Not an office suite, mind you, but pretty functional applications.

Which brings us around to the current hotness, Rich Internet Applications (RIA). Ever wonder why Adobe and Microsoft are slugging it out for that space? And Sun is running along behind with JavaFX saying "Wait, we want to fight too!". It's the new platform play. We've dealt with the pain of writing good looking web applications so long that when someone comes along and shows pretty pixels, we swoon. Yes, you can create beautiful applications using Silverlight and Flex. And Sun showed some awesome demos of JavaFX at JavaOne. But, if you write an application in one of those tools, you've bought a platform. You are no longer in a standards space. You can't take a Silverlight application and port it to Flex without a rewrite. Same goes with JavaFX. Whoever wins the RIA war has the new dominant web platform, just like Win32 back in the day. Sounds like a good reason for big companies to pour resources into the effort.

Of course, as my friend Mike Nygard pointed out during several expert panels, you pretty much buy into a platform play every time you start writing software. Yes, JEE is a standard across many application servers, but how many people are really careful to isolate the seductive goodies that come with your application server from the real JEE stuff? My guess is not many. So, you've kind of implicitly bought into a platform anyway. That's doubly true for .NET: yes, Mono exists, but more of a proof of concept than anything else.

Maybe this is OK. But I remember the reason to avoid single vendor platforms. One of the compelling reasons to move to Java when the JEE specs came out was the possibility of moving to another vendor, even with some strenuous effort. I can't tell you have many consulting clients I encountered in the mid-90's who had bought into a particular platform (say, Microsoft Transaction Server or ColdFusion) and were very productive with it...until they hit a real bug in the platform itself. I consulted at one company who had an 18 month project written to a proprietary platform when they encountered a show-stopping bug. They contacted the vendor who said "Yeah, that's a known bug. We're going to get a fix out for that in the next release, which should be in about 12 months". Even though it took them a long time, they scrapped what they written and started over, in Java. And you can bet they were careful about isolating the application server stuff from the specification.

Building to a single platform isn't necessarily a bad thing, as long as you go in with your eyes open. It's a trade-off: perhaps the pretty dancing pixels in Silverlight are worth the chance that you'll find something it doesn't support and end up with an application that doesn't quite do what your users want. But, beware of Dietlzer's Law: users want what they want, and are grumpy if you tell them "no". And, if you go with one of the RIA platforms, get ready to marginalize everyone without a PC. Some of these platforms have some support on mobile devices (and surely more to com, in a massive wave), but it's not going to be as good as plain old HTML for a long time.

If you are going to choose an RIA platform, please use it appropriately. Don't build forms in it: HTML is plenty good for data entry forms. I saw a demo recently of a text box that rippled when you touched it with a mouse or typed in it. Please. RIA is extraordinarily good for displaying information that is well nigh impossible in HTML and JavaScript. Use it for those kinds of visualizations. Most of the RIA platforms now don't support web metaphors like bookmarks, or addressable URL's. There's no reason to completely discard the parts of HTML that work well for which it is designed. Use HTML for general interactions, and use RIA for sophisticated visualizations. And know going in that you've bought a platform that you're going to have to live with for a long time.

A slightly different version of this rant, more Silverlight focused, appears here. I was at a party at a friends house that had lots of .NET folks there, during the Microsoft MVP Summit. I was getting some impending dead-line work done and Eric was recording a series of podcasts, the tone of which can be summed up by "Silverlight will cure cancer, solve world hunger, and paint your kitchen for you". After he was done, I was quietly fuming and asked him if he wanted a contrarian view. That's what's on the podcast. You've been warned!


javacup said...

Hello Neal,
Nice article. But the decision to develop parts of the application with an RIA frame and some parts in HTML is kind of tricky. I agree with your view that HTML works for the most part. As we start out to use HTML/JavaScript/AJAX everything is fine till we need a tree control or the ability to produce graphs dynamically etc. My question is what is a good approach to decide to go RIA?

salient1 said...

Great post, Neal. You do a great job pointing out the issues with these frameworks. However, I think there's some confusion with people thinking AJAX is RIA like Flex is. Arguably they can both be considered RIA but it's frameworks like Flex that introduces the biggest problems.

Personally, I find all that flash crap offensive. I refuse to go to pages that require it. It's almost always used to an inappropriate level and the current inertia it has building behind it is mind-boggling. Flex and Silverlight are proprietary, require huge data downloads, require plugins, and have their own set of bugs that can vary from OS to OS even when using the same effing browser across both OS'.

Unknown said...

Neal, as someone who spends a lot of time in the Silverlight world (for better or worse)...I can say that it certainly doesn't cure cancer or stop war. I think its fair to say that the RIA space is interesting for web application development (e.g. PhotoShop Express Online), but for most developers RIA should be a way to extend the DOM to create compelling extensions to the HTML model...not replace it. At least that's my opinion.

As for open versus closed, I think its fair to say that opening up of XAML and C# (as well as supporting other languages, some of whom you actually like; Ruby and Python come to mind) seems to make Silverlight play well in the open space. Look at the Moonlight implementation of Silverlight and it seems to me that Silverlight is not Win32 revisited. I'd like to see the same thing happen to Flex and Flash (multi-language support).

At the end of the day, I like the power that Silverlight gives me to create UI's and the language, browser and OS that its living it shouldn't matter.

Unknown said...

It doesn't matter what developers think of RIA. It will fail for a completely different reason:


That is, RIA in the form of a plugin based rich client framework like Flex, Silverlight and JavaFX.

Why? Because they're a pain to use. They're all implemented very differently, they often have a focus on form over functionality and they break a number of web paradigms while they're at it.

Copy/paste? Gone.
Increase/Decrease font size? Gone.
Forward/Back? Sometimes.
Bookmarking? Sometimes.
Save as HTML/Text. Gone.
View source? Gone. Multi-Agent support? Gone.
Multi-format support(XML/HTML)? Gone.
Mashup/Frames/iframes? Gone.

And worst of all....


They're damn slow. A lot of them have problems with state management too... accidentally navigate away from the page and BOOM! All state lost.

Come on people. This stuff is garbage.

Zoho managed to convincingly recreate every piece of desktop office software. I think that's a pretty good case for "pretty much anything we need can be done on the web..."

I agree with other comments here. Improve XHTML, CSS and JavaScript (see what Echo2 did to JS!). Make them more consistent and let's run with it.


javacup said...

Do you have the same opinion on GWT too? I haven't used it in any projects yet but some of demos at Java One were compelling. Check this online demo

The guys involved in developing this product seem pretty happy with their current platform stack in which GWT is a main piece.

Zach said...

The web is a platform too. It happens to be great for ubiquity and lousy for applications. I'm not trying to diminish the world wide web -- it would be difficult to overstate its importance to humankind -- but it was designed with a book metaphor, not an application metaphor. We web application developers get so used to bending over backwards to make things work that we forget that applications in a browser are the hack of all hacks.

There will be a Next Big Thing and I am not in a position to predict what it is, but I predict it will combine the ubiquity of the browser with a real application programming model like Win32 or (dare I dream?) Cocoa.

Unknown said...


While I am personally not a fan of the development model of GWT, or component based web frameworks (from a developer perspective), I don't consider GWT in the same camp as Flex, Silverlight and JavaFX.

As a user, I love most of my Google apps. They require no plugins, and support all of the usual web paradigms that I'm used to.

As a developer, I prefer something like ZK or Echo. But mostly I prefer action based frameworks for web development like ActionPack, Stripes or even Struts (not that they have to be mutually exclusive).

For me, anything that requires a plugin that yields an embedded object inside of my HTML page (even if it's the whole page), is destined to fail.

Flash is fine for things like YouTube and interactive graphs. But not for the user interface as a whole.

Long live a better XHTML, CSS and JavaScript...


Adam Haskell said...

Quick note Neal. While ColdFusion is still a closed platform. BlueDragon (an alternate CFML runtime engine) is now open source so even ColdFusion can be an open platform now.

Onur Gümüş said...

"Mono exists, but more of a proof of concept than anything else."

Based on what fact ?

So Mono is a POC, that's why all Gnome distros embed Mono and not Java. Mono is a POC that's why applications like Beagle and Tomboy come out of box with gnome.

Stephan.Schmidt said...

"Yes, JEE is a standard across many application servers, but how many people are really careful to isolate the seductive goodies that come with your application server from the real JEE stuff? My guess is not many. So, you've kind of implicitly bought into a platform anyway."

I often hear this argument, but it's a fallacy. It contains the assumption that the plattform is binary, yes or no. When in fact there is a difference between code that is 100% depening on a plattform or 5%. Migrating code which depends 5% (encapsulated) on BEA to a new plattform is easier than migrating code which depends 100% on a plattform.