SWT, Swing, or AWT - Which Is Right For You?
An anonymous reader writes "Why is there more than one Java GUI tool kit? The best answer is that one size does not fit all, nor is there a one-size-fits-all GUI tool kit to be invented soon. Each tool kit offers advantages and disadvantages that make selecting one more appropriate, given your needs and intended audience. Read descriptions of each tool kit's basic features, and the pros and cons of using each."
You don't have to go with those, there are java bindings for everything!> QT, wxWindows, even curses!.
Pick the one you like!
evil is as evil does
It should be SWT vs Swing. There's hardly a reason to use the plain AWT when there's Swing (a much more powerful library built on top of AWT).
I would rather use a web front end than use any one of the three (and I have used them). Java on the client is too cumbersome and support intensive and the majority of users do not like them. Throw a nice dhtml front end at them and they are much happier (at least in my experience).
Shouldn't the question be "Which is right for your project?"
The correct answer is, "None of the Above."
Before you invest a lot of time, effort and money crafting a GUI front-end for your application, you should really stop and consider that you may not need one.
If your app is basically a way of querying a database on a server deep in the bowels of the computer room, you should be coding the interface as a web application. Especially now that AJAX is on the scene... modern AJAX tools and a Java backend can put together some very powerful applications that don't have the same development and deployment costs that an executable on every desktop would.
AJAX isn't a cure-all, and not likely to help much if you're interacting with local datasets with lots of processing horsepower (as in an imaging program like the Gimp or a sound editing program) or constructing a platform-independant application that's mostly self-contained (like a game or a p2p client.)
It is great for things like CRM applications, scheduling tools, inventory tools and ticket-monitoring... stuff that need to read and set values in a database somewhere. It's even good for applications that were previously in the domain of the workstation and the PC, like lightweight data visualization tools and PIMs.
What's more, the development cycle of an application that only needs a copy of IE or Firefox to run will be a lot easier for you, the user/customer and the poor slobs in IT who would need to come up with a deployment plan, and =then= an upgrade plan when rev 1.2 comes out.
SoupIsGood Food
Are you new around here? ;)
Admittedly, I use Swing. I don't avoid it because of its memory requirements, but they are a source of continued concern to me. Admittedly, the issue doesn't get as much attention these days as RAM continues to become ever more inexpensive, but there is still serious room for improvement. Read my other posting here on this subject for some examples.
Swing is flexible, and can create some nice GUIs. I don't like how much coding this requires (as I've mentioned elsewhere in this thread, Sun really needs to look at how Apple has solved the GUI design issue with Interface Builder, where instead of trying to create source code that has to be compiled to generate your UI, it gets serialized at design time, and deserialized at runtime (which has the added benefit that you can modify your GUI without the need for a recompile)), and I really don't like how quickly Swing can chew up RAM. Yes, I have a gig and a quarter of RAM, but no, I'm not in a hurry to fill it up as quickly as I possibly can either. I have yet to see a single platform where Swing wasn't a memory hog.
Yaz.
Why do people keep bringing up Jake2 when talking about Java's speeds, only to say that they're running it on a machine that's faster than anything from Quake2 days? What would be really telling is how well Jake2 runs on a 300MHz Pentium 2 with a Voodoo2 or a TNT graphics card.