Data in Motion

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Eclipse RCP vs. RCPLite vs. naked SWT ======

When should one code in Eclipse RCP? When should one choose naked SWT? And when should one choose RCPLite, the new middle-ground?

I tried to answer some of these questions in the following message I posted to the Eclipse.platform newsgroup. I thought it might help some other folks, so I'm presenting a slightly updated version of it here as well.

<code>
    Subject: Re: standalone SWT versus RCP
    From: David Orme 
    Date: Thu, 22 Jul 2004 13:33:02 -0500
    Newsgroups: eclipse.platform

    andrew mcintyre wrote:

    > Could somebody contrast the advantages/disadvantages of going down
    >the standalone SWT development path versus the RCP path? Especially
    >with draw2d involved?  I'm leaning toward the RCP path because it
    >looks simpler but what do I know, I'm a raw newbie.

    RCP

    + Provides higher-level application framework than SWT; more
    productive if you need its features and like (& can accept) its
    general design approach.

    + Can include Eclipse's update manager if you need to supply software
    updates dynamically to clients.  This alone could be RCP's killer app
    if you're a corporate developer.

    + If your application's UI has to scale to huge, epic sizes (like
    Eclipse's UI has to be able to scale), RCP helps a lot.

    - For small to medium-sized applications that aren't updated often or
    are client-side-only, RCP is large, heavyweight, and slow.  All that
    dynamic UI stuff that helps so much if your UI has to scale to large
    numbers of features can just get in the way if you have small and
    simple requirements.

    SWT (by itself)

    + Small, lightweight, performant.

    + Is low-level.  You can code almost anything in it.

    - Is low-level.  Although you can code almost anything in it, it's so
    low-level it sometimes feels like you have to code everything in it.

    There's a third option not being talked about much, and that is the
    SWTworkbench RCPLite framework.  RCPLite is intended to sit in the
    middle-ground between naked SWT and Eclipse's full-blown RCP.  Here's
    roughly how it stacks up:

    RCPLite (http://www.swtworkbench.com/devzone/rcplite/index.shtml):

    + Small, lightweight, performant.  It's designed to be as thin a layer
    as possible on top of SWT and still provide application framework
    features.

    + Imitates the best features of Eclipse's UI and programming model and
    improves on a few of them.  Most notably these include perspectives, a
    unified view/editor model, and the Action framework (for menu bar and
    tool bar management).

    + Retains Eclipse 2.1's native look & feel.

    + A much simpler programming model than Eclipse's.

    - What you gain in simplicity you lose in UI scalability.  RCPLite
    isn't designed to be able to support as many features in the
    application UI as Eclipse can (yet it's designed to support a
    reasonable-sized app; for example, one could rewrite Quicken(tm) using
    it just fine).

    - No update manager for RCPLite (yet).
</code>

~~LINKBACK~~
~~DISCUSSION:closed~~
Data in Motion

User Tools

Site Tools

Page Tools
