Rich Unger's Blog

Two Rich Client Platforms Are Better Than One

In certain circles, raising the NetBeans vs. Eclipse question is much like discussing the relative merits of vi and emacs. They both pretty much do the same thing (though there are people on both sides who vehemently deny this). They both do a pretty good job. And, there are folks on both sides who think the other product is architected completely wrong.

So how do you wade through the propaganda and choose the platform that's right for your application? The two most important considerations are GUI toolkit and available modules.

Every comparison of NetBeans and Eclipse inevitably raises an SWT vs. Swing debate. Eclipse uses SWT, which is a toolkit that uses native widgets in the underlying platform. NetBeans uses Swing, which emulates its widget set using Java2D graphics. Propagandists on both sides will try to convince you theirs is "faster". This is like debating the relative merits of two cars at a stock car race. Driver skill plays a much bigger role. (In case you missed the metaphor, you are the driver.) For example, if you do any heavy lifting in your toolkit's event loop, your application is going to "feel" slow, no matter which toolkit you're using. Don't believe me? Download the bare platform (without all the Java IDE modules) for both NetBeans and Eclipse and play around with them. They're both pretty snappy.

Another common flamefest is the holy grail of "looking more native". It's a worthy goal to want to make your application look and feel like every other program on your target platform. The trouble is, it's difficult to find any two native apps that look the same! I've never seen a windows application with the same curvy tabs that Eclipse uses in its tabbed panes. Likewise, the tabs in NetBeans that, in some ways, act like title bars, are unique to NetBeans. Not that either of these are bad design decisions. "Looking native" can be taken to an unhealthy extreme. NetBeans and Eclipse both do quite a good job of rendering widgets that look like the basic widgets of the host OS. No naive user would look at either one and say, "Hey, that's not native!"

The ways in which the toolkit should factor into your decision are:

• Do you have prior experience with either toolkit?
• Do you have off-the-shelf components you want to embed in your GUI, that are already written in one of the toolkits?
• Does the finished product look the way you want it to, on the platforms you wish to deploy?

The second consideration in choosing your application framework is the catalog of available modules. Do you need an xml editor? NetBeans comes with two (text and tree based). Will your app integrate an RSS reader? Eclipse has one of those. Don't get caught up in the "which is faster?" or "which looks more native?" religious wars. Pick the framework that's going to do more of your work for you.

Now, this was written about six months ago, and some of my information is out of date. I think Eclipse has, or will soon have, xml modules in the base distribution. NetBeans has an RSS reader, of sorts.

I still stand by my criteria. I've since stopped likening the debate to VI vs. Emacs. Gnome vs. KDE is a more apt comparison. They drive each other forward. On a technical level, Eclipse is the best thing ever to happen to NetBeans. The rate of improvement is higher than it's ever been. In glancing at the Eclipse roadmap, I see they're targeting NetBeans features as well (such as better integration with external build tools like Ant).

The tools market is pretty darned big. There's room for both platforms. There's room for improvement in both platforms. Competition is making it happen.

Comments

• What about spring-rcp?

  Posted by: wireframe on March 23, 2005 at 12:19 PM

• Last year I attended the "No Fluff Just Stuff" symposium in Michigan, and IDEs was a topic of discussion amongst presenters and attendees. David Geary stopped by the table some of us attendees were eating at & having a discussion about what IDEs we use. He plopped down to enjoy lunch & gleefully announced, "I use emacs!"

  Indeed he did use emacs on his Mac for Java development; I had seen him use it during his Java Server Faces presentations. Efficiently he did use his emacs for development presentation purposes. I didn't know how to take his statement about this. Was he reluctant to learn anything new, and that was why he used emacs? That would be silly considering he helped author Java Server Faces. Was it because everyone at the presentation was given a Mac and his favorite IDE wasn't supported on Mac?

  Ted Neward hit upon the same subject during a round table discussion and answered my question. The synopsis of what he said was "It doesn't matter what IDE you use, so long as you know your IDE very well." He went on to give an example of a guy who used a particular text editor for Java Development, and with several keystrokes, would have the framework for an entire EJB setup.

  Ted made a good point. You can hang a picture on a wall using a level or a laser level. Either way you're looking for the end result...the picture on the wall, level. If one tool is just as fast as the other in the hands of those who know how to use it, does it make a difference what tool one uses? Is it counter-productive to force all developers to one particular IDE of whom some have never used?

  How ironic the project I work on now, two people use different versions of Eclipse 3.1, one WSAD, several IDEA, and a few others their favorite text editors. But we all get our jobs done.

  Posted by: phlogistic on March 23, 2005 at 12:42 PM

• I'm talking about j2se rich client frameworks here. Spring is a framework for building j2ee apps.

  I'm also not really getting into IDE choices here, either, though both eclipse and netbeans have IDE aspects to them. I'm talking about using their underlying frameworks as the foundation for other client-side java applications.

  The point on IDE-agnosticism is well-taken, however. Right now, I'm on a project team that develops a toolset as netbeans modules, and different team members use different tools (gvim, netbeans IDE, eclipse IDE, etc) to do it.

  Posted by: richunger on March 23, 2005 at 01:42 PM

• Spring RCP is a j2se rich client framework - Unfortunately wireframe had the link pointing to the regular Spring framework URL.
  Here's a better URL:
  spring-rcp
  It really is shaping up to be a nice platform for rich client apps

  Posted by: snurfer on March 23, 2005 at 03:23 PM

• Looks interesting. They seem quite a bit less mature than eclipse rcp or netbeans platform. They've got their work cut out for them getting feature parity. But, perhaps, if they're particluarly nimble about reusing the stuff available in apache commons and elsewhere, combined with the freedom that comes with not needing to maintain backward compatability with a years-old codebase...
  I'll certainly keep my eye on it.

  Posted by: richunger on March 23, 2005 at 04:19 PM

• You are right,"A hockey game needs two teams.".

  Posted by: isaacxu on April 09, 2005 at 12:38 PM

This work is licensed under a Creative Commons License.