That Other Cross-Platform Language

There are certainly cross-platform solutions other than REALbasic, the most notable of which is Java. Java may make the most sense for you in some situations, but sometimes REALbasic will make the most sense. The marketing material for REALbasic 2005 confidently asserts that Java on the desktop has failed. That's overstating things just a bit, but it is true that Java has never flourished as a language used to develop client applications. Instead, Java's strength has been at the server level, where it has found its way into many enterprise applications.

A brief history of Java will help to explain the different approach that REALbasic takes, especially with respect to user-interface elements. REALbasic and Java take two fundamentally different approaches, each with its own strengths and weaknesses.

AWT

The first way to code GUIs in Java was known as AWTsomething which reportedly took only a few weeks to create. AWT used native application controls for Java application controls, but the engineers made available only those controls that were available on both platforms. This led to there being only a small subset of available controls. This wasn't the biggest problem, however. What didn't work was that the controls behaved differently on different platforms. It was next to impossible (and believe me, I tried) to get one GUI application to work the same way on a Macintosh and a Windows machine.

Swing

Part of the underlying problem with AWT is that the controls on different operating systems often work in different ways. As a way around this, the next GUI solution for Java was Swing. The Swing library provided access to a set of custom-designed Java controls. This avoided the not-working-the-same problem, but created a new one. Java apps were different than native apps on each platform and people didn't like this. The apps themselves stood out like a sore thumb.

Incidentally, the Mozilla web browser bills itself as a cross-platform development solution. Although it's a web browser, you can also create apps with it. It suffers from the same problem with Swing, in that the developers chose to create user-interface elements specifically for Mozilla, which leads to a nonstandard-looking application.

SWT

There is a relatively recent alternative to AWT and Swing called SWT (for Standard Widget Toolset), and I must say that it is a much, much better solution than either AWT or Swing. SWT uses native controls as well, but does so in a way that avoids the problem with controls working differently on different platforms. All in all, SWT is quite good, but there is still a little sluggishness in the application, which comes less from the interface than it does from Java itself. Java applications are slow to start up and they consume a lot of memory.

Despite the obvious benefits of Java, most commercial applications are still compiled applications because the Java approach just doesn't seem to work that well with desktop applications.