Oh god, what will I have stared with this post...

Discussion in 'Java' started by Brent Eamer, Dec 22, 2003.

  1. Brent Eamer

    Brent Eamer Guest

    I have experimented with Java's Swing architecture for a bit now and then
    switched to HTML/JSP and I find the Swing has a richer
    user interface available to me, so why is no one using it. If one were to
    learn J2EE or just Java with Swing to deliver an applications what questions
    would you ask in order to decide what to go with?

    It seems a lot of energy has gone into JFC/Swing and then a few years ago,
    boom!!! everybody is using a browser as their client.

    Also from a job/skills perspective, which is the best skill combo to

    Thanks all, can't wait to see how deep this thread gets...
    Brent Eamer, Dec 22, 2003
    1. Advertisements

  2. Brent Eamer

    VK Guest

    A good shoot for a troll, but wrong place: try the same in
    VK, Dec 23, 2003
    1. Advertisements

  3. Brent Eamer

    Ryan Stewart Guest

    I'm not sure what exactly you're trying to say. That a Swing GUI is better
    than a web page? Well yeah. Any standalone application written in a decent
    programming language is going to be much more flexible than HTML will ever
    be. Remember that the T in HTML is Text. That's what it was developed for:
    to move text from place to place. So yes more flexible and richer, but more
    widely usable? Who's going to install your application on all the computers
    it will be used on (possibly nation- or worldwide)? Who's going to train all
    the users in how to use the new interface? Why not just use a web app that
    requires no download or installation, that everyone already has a client for
    (their web browsers), that can be accessed from anywhere that's hooked up to
    the internet (in case of travel), and that has an interface that the user is
    already familiar with (everyone knows how to click a hyperlink)?
    Ryan Stewart, Dec 23, 2003
  4. Brent Eamer

    Brent Eamer Guest

    I'm not a troll, check for any posts in comp.lang.javascript
    Nice try
    Brent Eamer, Dec 23, 2003
  5. Brent Eamer

    Brent Eamer Guest

    I would tend to agree with you, but I got really frustrated trying to
    develop a small app with JSP/HTML/Javascript. Things like 'once the page is
    posted, if you have to update anything, you have to submit() again" I found
    it a pain in the ass, especially since I come from a client/server
    background. (Oracle Forms and PowerBuilder). And it seems SUN went through
    a lot to create Swing, I have the Zukowski book and man, there is a lot to

    Thanks for the reply
    Brent Eamer, Dec 23, 2003
  6. Brent Eamer

    Ryan Stewart Guest

    Depends what you're trying to build. I'm in a communications squadron in the
    Air Force. The primary purpose of most of our applications is to make
    information instantly and globally accessible. If you're trying to make
    something more along the lines of earlier client-server architecture or even
    mainframe-terminal type of stuff, where intensive processing is done on the
    server while less strenuous stuff is done on the client, or maybe the client
    does the processing and just queries data servers, then you'd be wanting a
    more or less continuous flow of data between them and you may be better off
    writing a server and a client that will communicate in a proprietary manner
    using Java or another language. Wow, long sentence. :) So, as is always the
    case with programming and computers in general, analyze your requirements
    and choose your tools.
    Ryan Stewart, Dec 23, 2003
  7. Brent Eamer

    Brent Eamer Guest

    So the statement you made:
    "better off writing a server and a client that will communicate in a
    proprietary manner"
    *could* be implemented with HTML and servlets, using MVC properly, although
    it could be a chatty application ie) combo box selections depending on other
    combo box selections, database verifications etc
    Brent Eamer, Dec 23, 2003
  8. Brent Eamer

    Sudsy Guest

    No offence intended, but perhaps you weren't using the right tools?
    I've never had problems with sophisticated multi-page forms (think
    resume collection) containing pre-populated fields. Frameworks like
    Struts make it even easier.
    I think that the trend is towards the ultimate thin client: the
    browser. It makes a lot of sense in most cases. Bandwidth demands
    and local footprint are both mercifully low.
    Sudsy, Dec 23, 2003
  9. Brent Eamer

    Brent Eamer Guest

    I have heard of Struts and other frameworks. I think theserverside.com has
    reviewed a new book "Art of Web Development" that speaks of the various
    frameworks. That is where I think I will have to go, doing it manually is
    just too difficult.
    The small app I am writing is a database driven web app so I am dealing with
    things like a combo box that gets selected, then another one gets filled
    based on the first selection. I am using Jdeveloper with OC4J. And I know
    they have struts wizards.
    Brent Eamer, Dec 23, 2003
  10. Brent Eamer

    Ryan Stewart Guest

    Certainly you could do that. You could also use C to create a simple dialog
    box with a text field. Or you could use Visual Basic or Java and save
    yourself a few hundred lines of code. Granted your example isn't that
    Ryan Stewart, Dec 23, 2003
  11. Brent, please don't top-post.
    George W. Cherry, Dec 23, 2003
  12. Brent Eamer

    Gavin Donald Guest

    I don't know much about swing as I came from a web based background
    but am interested to know why swing is better.

    I would say it is easier to put an <input> field using HTML and
    a browser than it is to build it into a swing app.

    Is a browser not a better way to send the app data to the client. How
    would you send a application to a remote user without a browser ?

    I would have thought it was quicker to write in a browser and also
    many people are familiar with the interface which has built in
    navigation, back button etc. and print facilities.

    Gavin Donald, Dec 23, 2003
  13. Brent Eamer

    Brent Eamer Guest

    Is a browser not a better way to send the app data to the client. How
    I am not really working on a production system, I was just curious, all
    things equal, architecturally speaking, what questions would you ask before
    choosing one method over another. If an organisation had an intranet, then
    this would be a cheap way to roll out the application, however HTML does not
    provide all the U.I widgets common in windows-type user interfaces..

    If the application were to be used by a a health care system, say an
    insurance claims system that the general public used then a web deployment
    is probably the only way to go.

    But if you had an internal app, you would have to weigh the benefit of a
    rich user interface (Swing) vs ease of deployment (Browser)

    So, my observation was that for complex applications, it just seemed a lot
    of work to get the same functionality out of a Web based implementation
    Brent Eamer, Dec 23, 2003
  14. Brent Eamer

    Sudsy Guest

    Brent Eamer wrote:
    I hate to use the term "paradigm" but it's most appropriate for this
    kind of discussion. You can set up all manner of powerful widgets when
    you are guaranteed local processing power. I sometimes wonder whether
    these features enhance productivity.
    The advent of the web provided a simpler, less esoteric user interface.
    You might not have combo boxes and so have to use more basic elements
    to achieve the same goal. As long as it's well designed and makes
    sense to the end-user then what's the harm?
    Designing a Java/Swing application to duplicate the "look and feel" of
    a windows app seems like such a travesty to me. I'd rather see the
    investment in work flow analysis. What do people using the system need
    to do 99% of the time?
    Don't get too hung-up on the windows paradigm when you can get the job
    done using the web paradigm. It IS possible to scroll a form: not
    everything has to be visible on the screen at once, especially if some
    fields are rarely used.
    And that's where you need the much maligned "paradigm shift". Scott
    Adams (<http://www.dilbert.com>) drew a strip which still makes me
    grin, vis "that was a paradigm shifting without a clutch".
    We have to be looking ahead, to PDAs and cell phones which have such
    little screen real-estate that the old models simply won't apply. We
    have to design for new platforms and not expect that widgets like combo
    boxes will always be available...
    Sudsy, Dec 23, 2003
  15. Don't be silly. I personally still use Swing
    extensively, while converting my sites to
    use 'HTML/JSP' as you put it.

    This ensures the apps. are accessible to
    people with a browser, but no JVM.

    If they want the Swing version of my Apps,
    it's available through WebStart.

    Give the user every option.

    [ Of course, there are things you can do
    in an applet that are impossible in HTML,
    so there is _no_ option at times.
    In that case, use Swing. ]
    Andrew Thompson, Dec 23, 2003
  16. Brent Eamer

    Brian Kildea Guest

    I have done both web pure and Java Swing, although granted it was about 3
    1/2 years ago that I last did web stuff, so my experience does not include
    the latest web technologies. With that caveat, given my choice, I'd prefer
    Swing to web any day of the week and twice on Sunday. I find it much easier
    to program, I can make the client much more "real-time" (term used very
    loosely) without having to perform an HTTP transaction. I can also leverage
    a far richer set of tools without glueing together 3 technologies with
    band-aids and duct tape. Plus I am far less prone to runtime errors. Others
    may disagree; these are just my preferences. And I know there is a web
    technology to counter my every point, but they are a collective witch's brew
    in my opinion.
    As negative as I might sound on the web, I don't hate it -- I just don't
    like developing in that environment. My personal philosophy for when to
    apply one versus the other is: Java (C++, etc.) clients for power users, web
    browser interfaces are fine for casual or infrequent users. Of course this
    works best when your application is targeted for a specific audience, such
    as a corporation. In such a case, the finance & accounting may get very rich
    tools for a payroll system, but the average employee interfaces in a much
    more limited way and can use a web browser interface. If your target
    community is the Internet, well, you may be stuck with a browser interface
    or be willing to write off a large number of people that have neither the
    bandwidth not the inclination to install Java.
    Brian Kildea, Dec 23, 2003
  17. Brent Eamer

    Brent Eamer Guest

    Excellent critique Sudsy and Brian. I was looking for someone who has been
    there and you guys have addressed that

    Brent Eamer, Dec 23, 2003
  18. Where in this thread did we 'swing'
    (yeh ok, bad pun) from what's best
    for the client, to what the developer

    I'd prefer to have a thin web client
    used by 100,000 visitors, to a Swing
    UI with advanced widgets that can
    be accessed by only 10, 10,000 or
    99,000 web surfers.

    If you don't need anything more, stick
    with the thin client, in order to best serve
    the _client_.
    Andrew Thompson, Dec 23, 2003
  19. Brent Eamer

    Sudsy Guest

    Andrew Thompson wrote:
    Thank you! Sometimes developers go overboard and create
    wonderful-looking GUIs which are so complex that users
    have to take training in order to learn how to use them!
    What's up with that?
    That's why I believe in analyzing exactly what the users
    really need in order to perform a task and providing the
    necessary functionality. Since most people are familiar
    with the web paradigm, popping-up a window for some in-
    frequently used facility just isn't a big deal. As long
    as everything is designed to be keyboard-navigable then
    your users should be happy.
    Thanks to Andrew for raising a good point!
    Sudsy, Dec 23, 2003
  20. Brent Eamer

    Brian Kildea Guest

    I understand your point, but I think the answer here is very much dependent
    on one's requirements. For example, I don't develop sofware for use by
    100,000 "visitors". My applications are used by a very small community of
    specialists, and there is on-line help, users manuals and training courses
    that are developed to accompany the application. Many in this community
    wrongly assume that every other project is just like theirs meaning that
    *everyone* is writing applications for the whole Internet user base.

    I will admit to having a preference for Swing. Some of it has to do with my
    feeling that I can develop richer, more intuitive interfaces with Swing than
    I can with what's available in a browser. That can serve my clients well --
    maybe not everyone's, but mine. I also spent endless hours 3 years ago
    trying to work around slight variations in browsers, and their Javascript
    bugs that remained unfixed for many versions. I also hated the continuous
    conversion between Javascript, HTML forms and server side "languages",
    complicated by the lack of strong typing in any of these technologies. I
    can do more than twice as much in half the time with Java and Swing and
    create a much more bug free application. Surely one can argue that that
    best serves the client -- in my case the paying client and the operators are
    not the same. I think I serve them both well in this regard.
    Brian Kildea, Dec 23, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.