Sponsored Link •
|
Advertisement
|
Advertisement
|
This page contains an archived post to the Java Answers Forum made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.
Message:
I think that both solutions are reasonable, but for different kinds of user and different kinds of app. The reality is that making webpages do anything interesting is phenomenally challenging. We still have no decent tree navigation in JavaScript and HTML (with selection listeners and selection state) and really this should be part of the JavaScript library anyway. For many applications (e.g., getting airline tickets) the user does not need a powerful GUI. They may also be in an internet cafe or using someone else's computer, in short, they are a 'brief user'. If the purpose of the website is to satisfy this 'brief user', then HTML+JavaScript is the way to go (definitely). If the user uses the application all day long, however, then it makes little sense to use HTML+JavaScript, since the complexity for adding features to these fragile technologies is greater than with Java. E.g., imagine the spell checker is located on the server. There may be a 'gee whiz' factor to cramming everything under the sun into the browser, but that doesn't bring home the bacon (and only wins medals amongst the uninformed). > > > Wayne, > > > My opinion is that it is a good idea to keep the client-side > > > We have been using the servlet/ejb/jsp setup on an n-tier > > > Just my humble opinion though. > > > Regards, > > > Jody > > If this is developed as an n-teir applet and Swing classes are already on the client PC then I guess I don't see the difference?
Replies: |
Sponsored Links
|