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

[Brent Eamer]

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
learn/master

Thanks all, can't wait to see how deep this thread gets...

 

[VK]

A good shoot for a troll, but wrong place: try the same in
com.lang.java.advocacy

 

[Ryan Stewart]

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

 

[Brent Eamer]

I'm not a troll, check for any posts in comp.lang.javascript
Nice try

 

[Brent Eamer]

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
learn!!

Thanks for the reply

 

[Ryan Stewart]

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.

 

[Brent Eamer]

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

 

[Sudsy]

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
learn!!

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.

 

[Brent Eamer]

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.

 

[Ryan Stewart]

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

 

[George W. Cherry]

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, please don't top-post.

 

[Gavin Donald]

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.

http://www.prodia.co.uk

 

[Brent Eamer]

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

 

[Sudsy]

Brent Eamer wrote:

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

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

 

[Andrew Thompson]

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.

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

 

[Brian Kildea]

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

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.

 

[Brent Eamer]

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

Thanks..

 

[Andrew Thompson]

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

Where in this thread did we 'swing'
(yeh ok, bad pun) from what's best
for the client, to what the developer
wants?

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

 

[Sudsy]

Andrew Thompson wrote:

Where in this thread did we 'swing'
(yeh ok, bad pun) from what's best
for the client, to what the developer
wants?

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!

 

[Brian Kildea]

Where in this thread did we 'swing'
(yeh ok, bad pun) from what's best
for the client, to what the developer
wants?

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
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site

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.