Re: HTML vs Swing for U.I application architecture
From: Scott Ellsworth (scott_at_alodar.com)
Date: 12/28/03
- Next message: JROCKS11: "natural language recognition"
- Previous message: Piotre Ugrumov: "Re: Help with the vision of jsp page and with the servlet execution"
- In reply to: Andrew Thompson: "Re: HTML vs Swing for U.I application architecture"
- Next in thread: Brent Eamer: "Re: HTML vs Swing for U.I application architecture"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 28 Dec 2003 14:36:13 -0800
In article <jWYFb.63060$aT.61772@news-server.bigpond.net.au>,
"Andrew Thompson" <andrew64@bigNOSPAMpond.com> wrote:
> "Brian Kildea" <bkildea2@san.rr.com> wrote in message
> news:pqSFb.11577$C87.6410@twister.socal.rr.com...
> >
> > "Brent Eamer" <beamer@islandtelecom.com> wrote in message
> > news:euNFb.18577$IF6.783149@ursa-nb00s0.nbnet.nb.ca...
> > > > Is a browser not a better way to send the app data to the client.
> ...
> > 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?
Ofttimes, a developer's wants are based on experience. Not always -
sometimes we just make stuff up, but if the developer has a bias, I
usually listen before rejecting it.
I, like most consultants, usually understand the technologies and
options better than my clients, or they would not be paying me
consulting fees. They virtually always understand their own needs and
problem space better than I do, or they would find a different business.
(I may be clever, but they do what they do all day, every day. Hard to
beat that much focus.) Thus, turning their requests into technology
proposals is a major part of my job, and making sure that they know the
implications is a close second. Not rocket science - I suspect every
good developer does that.
As a developer, I find that Swing is a good solution to most UI
problems, but I have used other tools as well. I use Cocoa when I can,
but that is not an option for a cross platform app. I like WebObjects
on the web, but servlets are usually lighter weight. I delivered one
web app in Perl with Mason, because they also wanted a Perl API for the
functionality. When I wanted a thick client, I have had many problems
with applets even when I controlled the environment, and relatively few
with WebStart.
Pure server side web technologies tend to be outgrown surprisingly
early, at least in my experience. When we can keep it simple enough for
a web app to be a good tool, it has a lot to reccomend it. That said,
the apps do not stay that simple in distressingly many cases. All too
often, the proof of concept works great as a web app, but they then want
a whole new feature set for the released product that pushes us into the
thick client space.
So, when I tell a client that I lean towards WebStart based Swing apps
for most tasks, it is not arbitrary. I love it when a web app can be
used as the solution, but I do not stick with it beyond its lifetime. I
consider it key to make the client aware of how much further they can go
with a thin client model, so they get to make the call. If nothing
else, Swing apps are more complicated.
> 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.
Agreed, as long as you expect 100k visitors. An app with complicated UI
requirements might not be feasible to expose to the web at large, but
might do just fine for an intranet app.
> If you don't need anything more, stick
> with the thin client, in order to best serve
> the _client_.
Agreed completely - a thin client is much easier to maintain. I have
just had too many cases of scope creep that made the thin client
unreasonable. Thus, serving the client means knowing when to move to a
thicker technology.
Scott
scott@alodar.com
Java, Cocoa, WebObjects and database consulting
- Next message: JROCKS11: "natural language recognition"
- Previous message: Piotre Ugrumov: "Re: Help with the vision of jsp page and with the servlet execution"
- In reply to: Andrew Thompson: "Re: HTML vs Swing for U.I application architecture"
- Next in thread: Brent Eamer: "Re: HTML vs Swing for U.I application architecture"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
