Tuesday, February 19, 2008

Java, C# and the Case of Inferior Look

Building application is a lot of work and dealing with low level issue of OS API makes it worse. Relatively high-level language like Java and C# (I haven't seen GUI-based on language like Ruby application widely used yet) could help to enhance productivity on this.

However, despite the already long evolution, those languages has not yet fully capable to give competitive result in terms of user interface. Java-based GUI is still looking inferior compare to natively written application. Even in Windows , where it seems to have the best integration, it still feel odd here and there. It's quite unfortunate since it's relatively good/easy language to build application on.

Then along the way come .Net (C#). This one is a little bit better, at least if what you are trying to do is developing things for Windows. It has the easiness of Java but quite native feeling of the interface. For quick application programming with fancy interfaces it provide what mostly needed to get the job done. It is still has some holes here and there, but fortunately for this one, the interoperability to native code is quite excellent with lots of third party component to fill in the gap.

All is not lost in Java side though since there's SWT to the rescue. I think people seriously looking to develop application in Java but still want to be competitive in the user interface department should put this into their toolbox. It still has some issues though, but it has good approach which lately Java has start to adopt in recent releases, i.e: more native widget rendering.

There's a tradeoff in doing abstraction and generalization as we see in the case of programming in VM-based language. It create some gap in areas outside the intersection and generalization that is being taken. But the recent effort has getting closer to close/bridge those gap.

There's another path someone could take to avoid having "inferior" look to his app but still a little more productive than having to access OS API directly. It's the bottom up way : C++ Wrappers. Instead starting with easiness/abstraction and move down to take care of nativeness details, you could start with having nativeness first and work on having easiness/abstraction. There are lots of various C++ wrappers out there that could help with this e.g: QT.

Take your pick then, it's the world full of options and you don't have to always use something suboptimal, given by the standard lib, for the look if you don't want to. That being said, I still enjoy JEdit, Freemind and JUDE despite their look feels out of place a little bit. So, I guess the substance is still the king although the look could really help too.

No comments: