JSP vs Swing

Question

can we achieve all the functionality by programming in Swing,than what we get by JSP.
moreover can we develop a website in Swing?

Answer 1

oxbow_lakes wrote:
Lets be clear about this - Swing is infinitely more
capable GUI-wise than HTML/JavaScript (which is what a
JSP can give you). Right on! [smile]
Responsiveness can indeed be better
in some cases, because you don't have to go to the
server every time (ie. you can embed business-logic in
the application).Urr... responsiveness in a Swing gui should never be any slower than a thin client... typically, it should be orders of magnitude faster. There are many obvious reasons why this is true.
Also, there is no need to embed business logic in the Swing application. Instead, you just make requests back to your app server for business logic processing.
The problems you have, however, with Swing are
many-fold.
1. Most browsers will NOT, by default, support Swing
(or Java1.2). Most browsers, of course, being IE5.
Hence you need plug-in technology. Which can be a bit
of pain as therefore you have to worry about
client-browser requirements.This is what Java Web Start is all about. (I think you mention that later). It's a great solution.
2. Distributing applets over the web can give rise to
versioning problems on the client-side. If your applet
takes a long time to load you want it to be stored on
the client's machine. However if you make a change to
the business logic, you need to distribute this change
out to clients.Again, this is solved by Java Web Start. It caches your application, and also ensures that you have the latest version each time you run it. On top of that, it lets developers create incremental updates to their applications.
3. Swing is much more complicated than HTML so making
things like dynamic, interactive tables will take more
time than in simple HTML/JavaScript where it is easy.I disagree. Handling a mouse click is almost exactly as simple as handling a mouse click with JavaScript. (I might even argue, simpler). Swing differs in that there is so much more power available to you.
4. If in processing the page you need to communicate
with the server then this is simple using JSP - the
page is being executed on the server already. No
problem. Using Swing, however, you will need to use
maybe RMI or raw Socket communication to a server
process. The former is more finicky and the latter
requires cleverer code on the server-side to listen to
unpack the incoming streams (all of which is invisible
to you when using JSP). Add firewalls to the equation
and you might find that client-server communication is
well-nigh impossible. Or just beyond your area of
expertise.Communication is not a hard problem to solve. For example, you can write EJB client code from your application just like you would from a servlet (or JSP). Application servers like Weblogic multiplex RMI and HTTP on the same port.
People also use the same controller pattern for Swing apps that they do for JSPs - where the controller logic is stored in servlets. This means that the Swing app makes requests to servlets for business logic processing. This has the two effects of preserving MVC architecture in the system and also effectively 'tunneling' requests through any firewall that allows HTTP. With Java's built in networking support, that's a piece of cake.
The answer is... if you are absolutely needing very
fancy graphical stuff that must be interactive, then
Swing will probably be better - it will be more
responsive and flexible. Otherwise, stick to JSP and
avoid the headaches.I disagree again. When will people realize that the browser was never designed for this task and is woefully inadequate!? [argghh]
I've written Swing-based and browser-based interfaces. Most of my headaches don't come from those mentioned above. Rather, my headaches come from trying to design interactive, intuitive, and fast interfaces using tools never intended for such a feat. Incompatibilities between browsers (implementations of the HTML spec, JavaScript, CSS, DOM) just add more fuel to the fire.
God bless,
-Toby Reyelts