Two Rich Client Platforms Are Better Than One
As I move my Java blog over from blogger.com, I figured I'd start things out with something I wrote as a sidebar for my DDJ article last month. The main article was about building applications on top of the NetBeans platform (not about the IDE). DDJ decided not to publish it along with the main article, so here it is:
NetBeans vs. Eclipse as a Rich Client Platform
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.