JSP vs Swing

It depends on the kind of application you are trying to get.

Swing is used for desktop applications. For example, if you wanted to write a word processor in Java, you would probably write it with swing.

JSP is used for producing HTML and XML documents, usual for display in a web browser. The page you are looking at was probably built with a JSP.

The only way you could make your whole site in swing would be to have your whole site be a giant applet, written in Swing, extending JApplet. While it is really cool that Java can do that, your users will appreciate the faster performance you can deliver with a JSP/HTML solution.

ShagVT at 2007-6-29 10:38:38 >

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

rreyelts at 2007-6-29 10:38:38 >

oxbow_lakes wrote:

> You are forgetting JavaScript.

No I'm not. I've written my fair share of DHTML.

1) JavaScript is interpreted - and hence very slow. Try doing anything resembling complicated and you'll see what I mean.

2) When you download JavaScript, you'll be wasting lots of bandwith, because it is very verbose. (Which you also suffer from when using HTML and CSS).

3) You'll end up supporting browsers that make you download the same JavaScript for every single page - instead of being able to download it once and reference it with href's.

I've worked with plenty of sites whose pages are greater than 60K in size due to the JavaScript, CSS, and what not (not including any images). Try to tell me that that will perform anywhere near an application. Bah!

> True - but lets face it half the point of Java applets

> is that you don't have to bother the server for

> everything and can put business-logic on the client

> where appropriate.

I agree that applications don't suffer from the "I have to hit the server for every little stupid reason" syndrome. I disagree that the point of using an application is to embed business logic. But unlike HTML, Java is flexible and you can do whatever best suits your needs, including putting business logic on the client if you so desire.

> I know. But the table itself is much easier in

> JSP-HTML than in Swing where you are messing around

> with Data models etc. Especially to programmers who

> are much more likely to be familiar with HTML than MVC

> and Swing to start with.

If people don't understand MVC, they should learn it. It's the simplest and most used pattern in software engineering. I realize the industry is full of mediocre programmers, but MVC is about as simple as it gets. If people can't get that, they belong in a different industry.

> Is there an echo in here? ;^) We seem to be agreeing

> at length.

At least on some points - [smile].

> You mean do a "context.lookup("MyEJB")" in the applet

> itself? That would be pretty cool.

Yep. Try it out for yourself. Just make sure that your firewall policy is set to allow anything on port 80.

> You have to choose the right solution to your problem.

I absolutely agree. HTML is the right solution to the question - How do I display static documents online?

> Plus you don't put off half of

> your users who would rather chew off their own feet

> than wait for 5 minutes while the Java plug-in

> downloads.

Java Web Start is 5.3M in size, (including the JRE). On a typical broadband connection, that's a one-time 30 second download. On a corporate network, it's about a 3 second install.

Sun is also working on other ways to make the JRE available. I believe the current JRE is already being shipped with AOL CDs (wow - that means I get shipped a JRE at least once a week), and I hear that Sun is working with OEMs to get the JRE installed on new PCs.

> I have also designed Swing and browser based GUIs. But

> for a newbie who needs to do something simple,

> suggesting that he go away and mess around with

> client-server communication (RMI, Sockets, whatever),

> get to grips with Swing, understand plug-ins blah blah

> blah would be a bit like using a sledgehammer to crack

> a nut. If he needs the fancy stuff, then use Swing. If

> not, don't. I stand by my post.

A newbie doesn't have to know any of the technical details of RMI, sockets, whatever. It's the same code you'd write in your servlets and JSPs.

There's nothing to know about the plugin. You run your HTML through a little program written by Sun and voila!, everybody will automatically be set to use the plugin.

A newbie does have to come to grips with Swing, but hey, he also has to come to grips with at least 3 different incompatible versions of CSS, HTML, and JavaScript (W3C, IE, and Netscape), along with Servlets and JSPs.

I stand by my post, too. [smile].

God bless,

-Toby Reyelts

rreyelts at 2007-6-29 10:38:38 >