Registered: Jan, 2002
Re: Hybridizing Java
Posted: Feb 2, 2007 12:24 PM
> Being the same "standard" is not the same as being the
> same language.
> > I have wondered myself how hard it would be to do a GWT
> > type thing for Flex. Done best it would re-use the
> > API instead of coming up with another GUI API (like
> > Write Swing -> custom compile -> output Flex. Could be
> > e interesting.
Personally, at the end of the day, I think we need to consider what solution would make our clients the happiest whether we toil for an employer or work as a consultant. If providing that solution means learning a new language, I'm happy to do that any time, but the benefits have to be there.
For a client/GUI environment, my experience is that most clients want something that:
1. Can be implemented quickly.
2. Provides no hurdles for a user to start using it
3. Provides some "wow" factor, i.e., looks pretty good and modern.
4. Is fast.
To these could be added another requirement, one Bruce mentioned in his blog:
5. Can be used both inside a browser and in desktop apps.
From my experience at least, if Swing is to provide (3), it has a hard time providing (1) and (2). I'm pretty sure that this situation will change, but that's just my experience with it now. In other words, using the defaults and relying mainly on JDK-based classes, and some IDE support, it's possible to build a Swing app quickly, and one that performs well.
But it won't look very nice (e..g, most everyone now uses LCD screens, and Swing in JDK 6 looks great on LCDs - but most people have some pre-JDK 6 JRE installed, and that means they'd now have to install JRE 6, which goes against desires #2). To use some of the fancy drawing, etc. capabilities in Swing, you need to know a lot about providing custom painting for your components, but I think that requires a skill set not available to many enterprise developers who just want to put a nice GUI on front of a business app. And to make your app perform well, you really need to understand how to use the event handling thread and ensure that you only update component state from that thread, and perform all other work in other worker threads. Yes, that can be done but, again, it's something you need to keep in mind, need to test and debug - again, that goes against desire #1.
To be fair, Swing is no longer just the JDK-provided classes - SwingLabs and some other projects (JGoodies, for instance) are important parts of Swing that solve some of these problems.
And once you overcome the JRE install issue, Swing definitely works very well both inside the browser and on the desktop.
It could well be that Flex (or any GUI toolkit) has the same issues.