Over a million developers have joined DZone.
Platinum Partner

Making the Right Choice For Your User Interface

· Java Zone

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.

Among developers, the decision of what user interface technology to use is always a biased one. I, as an Eclipse enthusiast, will almost always go for an Eclipse RCP based application. I'll say that it's faster to develop, I know the technology quite well and as it's my "expert area" it's where I'm more comfortable. 

Of course there are applications where just SWT or Swing would be a better choice, but I'm still more inclined towards Eclipse RCP. It's a flawed decision model though, and I'm sure most of you see yourselves biased in your technology decisions. 

Right now I'm working on an RCP based Twitter application. It's fun, and one of the things I'm trying to do is to push RCP and make the applications interface look more advanced. The best way to describe what I want the UI to be, can be summed up in three words: more like Flash*

How many of you have found yourselves in this situation? Writing a user interface, getting the functionality pretty much ok, but not being able to go that last 5% because of the choice you made at the beginning? Would it have been better if I chose Flash/Flex/AIR?

Bruce Eckel outlines the importance of choosing the right client side technology brilliantly in his latest article, Know Your Materials. As the article is geared towards web UI's, it really focusses in on the traditional HTML/CSS/JavaScript formula, and the three RIA contenders - JavaFX, SilverLight and Flash/Flex. The trick here is that you really need to consider what's cross platform. In summary, Flash/Flex solutions win out as most people already have Flash installed. JavaFX has the Java install going against it, while SilverLight is focussed on working on MS browsers right now.

The most interesting part of this article for me, was the quote from a developer who typically built their web applications on Struts, JSF and Spring MVC, who has now moved to Flex for the UI development: 

As for the technology stack, we're using the new Spring-Flex thingy to expose our spring POJO's as Flex destinations, and the Swiz framework helps us do a clean(er) job in Flex.

...productivity has been great so far and our burn-down is telling us we're pretty much on track.

So I hope this turns out to be a success and that we can do some more projects where we can use Flex as the front-end.

It's an interesting turnaround for these guys. These days we need rapid application development, but even more importantly, what we ship first needs to please the customer. It's refreshing to see developers stepping out of their comfort-zone, and using a technology that they might not have used before. Of course, these decisions can't be taken lightly - a certain amount of analysis may be required before you go messing around with your company's technology stack. 

There's a few points to take away from this, and Bruce's article. The usual question comes up - which RIA technology is best, and will JavaFX ever be able to compete with Flash/Flex. To that, we'll have to wait and see, but I do believe that JavaFX can slowly start to make some ground in the RIA space. 

Secondly, if you're honest how biased are you in your technology decisions, and have you found yourself wishing that you had made a different decision? If you were to write a web application right now, would you stick to the usual Java framework choices or would you consider Flex on the UI (or maybe even JavaFX)?  

*By the way, TweetHub is an experiment in RCP and other Eclipse technologies, so a biased decision is the right way to go here. Especially as it's not a commercial product. 

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}