RIA vs. RCP

Question

I'm on a project where we try to build a GUI replacement for an old application. Before we really implement the functionality we've started prototyping with Eclipse RCP (Rich Client Platform) and GWT (Google widget toolkit, a Rich Internet Application). What is your experience with RIA and RCP GUIs? When does it make sense to use RIA and in which situations a rich client is more suitable? With the current possibilities of RIA, it becomes more and more difficult to draw the line.. Do you have any experiences?

---

EDIT: All your answers are really interesting. I'd like to accept all of them as they contribute to the answer of my, I admit a quite open question. So my vote up for each of them. Hope the bounty will be shared among you.

Answer 1

In my experience, RIA GUIs tend to be robust enough to communicate most information to users. There are some probably some exceptions to this but I can't think of a good one right now. RIA has the advantage of being accessible to anyone through a web browser without installing a thick client (RCP). Unless you have some special complex display that cannot be done through web technologies I'd recommend going the RIA route.

Answer 2

We developed a (pilot project) plug-in for Eclipse which was then converted to both a standalone RCP application (we didn't want to ship it as a plug-in since we didn't want Eclipse as a pre-req, so we had to add some supporting code making it slightly more complicated than just a simple move into RCP) and into a RIA application using jQuery.

Despite the best efforts of the RCP camp, the RIA version took about the same time to develop (even though it was from scratch) and it looked smoother in execution.

The clincher was that there was no install required with the RIA version since all our clients already have application servers and updates are centralized at a server, not each client.

The RCP version has long since been left behind in functionality. As far as we're concerned, Eclipse is fine as a development environment (for Java, we have no experience with the other languages) but the effort they put into splitting apart the IDE from the GUI (to make RCP possible) is not quite finished.

On the other hand, jQuery seems custom built for that sort of stuff (probably because it was custom built for that sort of stuff). Both development and running of applications are very nice.

Answer 3

What is the nature of this application. Should it be running completely on a client computer? Does it need to access locally stored data? Are you just replcaning the GUI for an existing app with the engine still being the legacy code?

Answer 4

My significant other is working on a software appliance where she has leveraged AJAX as a means for configuring the appliance. The feature set for configuration is rich and aligns very well with RIA. Likewise, having to install software locally on the web browser is extremely discouraged.

Answer 5

There's not any detail on the requirements of your application which is really key to answering the question.

The big win for using GWT is the ease of deployment relative to something like RCP. There is nothing easier for the user than pointing their web browser at a URL and nothing easier for the operations team than pushing code to the server, bouncing it and calling it a day.

As far as functionality, the big area where GWT will come up short would be richer data visualizations: charting, tree/node, network diagrams, etc. This stuff is possible with GWT and some help on the server but the limitations of DHTML start to show through, even with a powerful toolkit like GWT. On the other hand, RCP gives you the full power of Java 2D to visualize anything you want. These kinds of features may not be necessary to you but they're also the ones that make applications really interesting, more than just a mess of tab, tree and data grid controls.

I've been developing with Adobe Flex for several years now and find it to be really powerful, having more or less the same deployment advantages as something like GWT but offering the same kind of power as RCP. You might want to check that out too.

Answer 6

Rich internet applications is a good way to make robust software that act like traditional desktop software. One common problem with RIA is that many developers tend to place business logic in the client side code. Business logic and states in the client-side code is very insecure as one can manipulate the client-side code in run time. Additionally, it is a whitebox system, which allows hackers to examine the code and find weaknesses, such as input validation done only in the client side code or manipulating states. Don't be fooled by obfuscation, as it only slows down a hacker, but doesn't stop him. Billy Hoffman wrote a good book about AJAX security (called, ta-daa, "Ajax security") and I recommend it for every RIA developer.

This doesn't mean that RIA is by definition bad, you can write secure RIA if you know what you are doing (no business logic in client side code, no states, input validation [also] done on server side etc). There are a couple of frameworks which implement this securer server driven RIA, one is IT Mill toolkit (based on GWT) and ICEFaces should also be one to my knowledge.

Answer 7

An organization i worked for choose RCP because their users needed to work with the application both online and offline ( when they are on the road, etc ) . I know this is possible with google grears now but gears is not really mainstream enough for big organiazation to base it flagship product on . But if your users dont have the need to go offline you would really save the hassle of syncing user data / product updates ect between your rcp app and server, RIA would be the way to go in this case.

Answer 8

Even though GWT goes a long way, it's not giving the same flexibility and accessibility as a proper application.

Even thouhg a GWT application can do almost everything a real application can, a number of factors indicates that RCP would be the best tool.

• Repeated work
• Lots of input
• Long sessions
• Repeated tasks
• Custom widgets for editing or presentation.
• Multiple windows with different data.
• Quick keys for often used operations
• Quick responses.
• A real menu bar, coolbars.
• A proper window that it easy to find in the taskbar.
• Context menus for seldom used operations
• Limited (or known base of) number of users.
• Extensive or complex animations or real time updates.

If you think that your application needs a workbench, with several views and editors, then the choice is given.

RCP and the workbench are not that easy to work with, but you get much for free if the application would benefit from the more "free" and open working model with multiple open views/editors etc.

If the application is for more occasional tasks, then GWT is really good.

GWT is really nice, but its still a web application, and that sucks sometimes. I wouldn't want to do all my work in a web application where i can accidentally press a key and lose all my work and the session. (My keyboard even has a key next to the arrow keys that seems to be impossible to disable). Its powerful enough do do almost anything you can do in RCP but its still running inside the web browser, and that can be irritating.

Remember that you can use java Webstart to deploy RCP applications.

Answer 9

There is also the possibility of deploying an RCP with some of the benefits of an RIA. One solution being investigated for our client (for use solely by staff within their company) is the use of a Java application launched via a Java servlet.

Some benefits identified include:

• It is easily upgraded, much like an RIA (just re-deploy its JAR file, it will be picked the next time anytime browses to the page with the applet)
• It looks, feels, behaves and performs like a native application, much like an RCP (thanks to SWT)

Some detriments identified include:

• The user's computers must have a Java plugin installed.
• The application must be developed in a version of Java compatible with the users' plugins (although the client can require a minimum version to be installed on staff computers). The RetroWeaver tool can help, although I do not have very much experience with it.
• The user must keep the web browser open, otherwise the application will be terminated.