OSNews has an interesting interview with Steve Northover, the principal architect behind SWT. He’s an old Smalltalk veteran from OTI, which got acquired by IBM in the 90s.
I think the interviewer brings out some good points:
1. SWT is successful because it uses native widgets, it is small, and it is fast
Eclipse is the main beneficiary of this success. I wonder if SWT were available, if early failed Java ventures like a Java-based Netscape (Javagator) and Corel’s Java-based WordPerfect Suite would have succeeded if they had used SWT.
2. “Many people want to build applications that are indistinguishable from native ones.”
I’d take this one step further: Users want to use applications that are indistinguishable from native ones. They would rather not deal with something that looks or feels different. Their lives are already complicated enough. So its not that developers like one way or the other. I’d probably say that programmers would tend towards having one emulated look and feel across all platforms because it is more uniform for the programmer. But user experience trumps programmer desires.
3. “The native versus emulated debate has been going on for at least 15 years. Before Java, we built a portable native widget set for Smalltalk. Sometimes history repeats itself.”
I’ve been on both sides of this debate throughout my career: I started out with native widgets in Delphi since that’s pretty much the only widgets available on Windows back in the mid 90s, then went to emulated with VisualWorks Smalltalk and Java Swing, with an interlude of native with Java AWT, including Applets.
I think it is this AWT experience, which was bad, that causes Gosling and others to recoil in horror from SWT. In retrospect, I wonder what the experience of the AWT implementors was, if they had ever made widget toolkits before. [Wikipedia on AWT: “One of the reasonable causes of this mediocrity is said to be that AWT was conceptualized and implemented in only one month.”] It is clear that Steve and his team has done it before and is doing it even better this time, while doing it in open source.
Now I’m back to native with SWT and Cocoa. Of course, web app interfaces like with Rails are the wildcard here, but since they all occur inside the browser, the user has different expectations than with a desktop app.
4. “What is JFace and how does that fit in with SWT?”
This is a constant source of confusion for those first learning how to program for Eclipse. It would be good if we could somehow merge the APIs of JFace and SWT for those who definitely want to program at a higher level. SWT is separated out so that it can be used at lower levels by folks who either just like to do that or want to use it embedded in other contexts rather than in an RCP app or Eclipse-based tool.
Until then, my only advice is to avoid looking at SWT first and JFace second. Instead, try to find a JFace API to suit your needs and use SWT APIs only when you need to (which is still quite frequent.) For example, you could build a tree that does what JFace TreeViewer does for you with just an SWT Tree and adding additional custom built APIs. But don’t do that, instead use a JFace TreeViewer. Doing so will also lead you towards a good Model View Presenter solution, with the SWT Tree being the View and the TreeViewer being the Presenter.
I blogged more about JFace and SWT in Eclipse JFace tip: How to add column headers to a TableViewer.