Slashdot Mirror


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."

8 of 323 comments (clear)

  1. Is none of the above an option? by killjoe · · Score: 4, Insightful

    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
  2. Why is AWT even an option? by dood · · Score: 3, Insightful

    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).

  3. None of them are very good by Anonymous Coward · · Score: 1, Insightful

    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).

  4. Right for *YOU*? by devjj · · Score: 2, Insightful

    Shouldn't the question be "Which is right for your project?"

  5. AJAX by SoupIsGood+Food · · Score: 2, Insightful

    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

    1. Re:AJAX by CrazyLegs · · Score: 2, Insightful
      I'll agree with you to a point. What you're talking about is, really, the old fat vs thin client approach. Fat clients (a la Swing, SWT, whatever) makes loads of sense if:
      • you're in control of your clients/endpoints (i.e. sys mgmt not an issue)
      • you have skinny network connectivity
      • you have sophisticated and/or performance-sensitive GUI
      A thin client approach makes sense if:
      • you are NOT in control of your endpoints
      • you have adequate connectivity
      • you have simple GUI and linear dialogue flows
      • sub-second performance is not a primary requirement
      I've worked (too many) years in both environments and seen them done right and done wrong. For what it's worth, the bank at which I work has it's teller-line app (rich GUI, sub-second performance, etc.) developed in Java (ported from C++) and using Swing. It works just great, but required great design.
      --

      CrazyLegs

      "Pork!!" said the Fish, and we all laughed.

  6. Re:Huh? by Yaztromo · · Score: 2, Insightful
    I have never heard of anyone who did not use Swing because of its memory usage.

    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.

  7. Re:Huh? by kalirion · · Score: 2, Insightful

    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.