I've been wondering something over the last few days. With the server side space we a good amount of organization. In the datawarehouse space you have JDO, Hibernate, OJB, etc.

Web frameworks have Tapestry, Struts, and Webwork. J2EE has an admitted imperfect but semi standardized spec and collection of implementations.

Yes there are smaller projects and ones that never get off the ground just like the client side. However, as a whole I have to give server side development a much higher grade in this area. I'm curious why server side developers think this is? I know many of you code on both sides. Is it the number of developers? Is it the need is just not large enough to reach critical mass? Is it just a simple case of individuals and companies following the money?

I suppose it is.
Possible reasons could be:
- server side is more suited for better organization then client side by it's nature (for example MVC is more suited for web apps then for windowing apps; if a desktop client crashes it is not a big deal, it happens sometimes, but if a server crashes... server apps need to be more robust by their nature, they accept more load etc. so better organisation is needed to cope with the problems and the higher complexity)
- Server side is more hyped then a client side in this Internet era.

MC

<Mileta>for example MVC is more suited for web apps then for windowing</Mileta>
I dont know where you got the idea that MVC is not suited for windowing apps. MVC architecture was long used when developing windowing applications using MFC

What is the Client side ???

Struts / Web Tier / Swing / EJB Client / Web service client

What is the Server Side ???

Struts /POJO / EJB / Web services client.

Look at the Logical layers and not the physical layer.

The physical layers completely determin the logical layers.

I really don't even consider a fat client / EJB client a pure desktop client application. Applications like JDiskReport are the apps I'm thinking were the original focus of the post.

So from that, SWING applications primarily have not developed well at all. Even Eclipse has so-so SWING support, and it's come as of late in version 3 or so. IntelliJ Idea only supports panels. WSAD, JBuilder, and JDeveloper support swing, but it's all kinda "weird".

SWING, like most things in the JDK, need some enhancements and layers built up to make it easy to use.

I think that a lot of these troubles could be solved with AOP, We are building a great framework, If you slice your problems using AOP, and using AspectWerkz or AspectJ, you can to avoid so many problems.
I think is not only a Arquitecture Problem, nevertheless a problem of conecerns, organizing it, the industry could solve a great amount of then.

Best Regards

Edgar Silva

I think AOP could be very useful too.

Well I'm not sure about this. I would like to see Sun put some more effort into improving the core look and feel of Swing, and simplifying particularly adding custom widget to the toolset (one of the best aspects of QT). It is also true that historically client-side Java (particularly GUI) has lagged behind the server side, but I think this is changing. I'd not used Swing for a while, but I took the RC of J2SE 5 for a spin last week. The performance of Swing has got really pretty good, even on relatively low spec hardware. I still find building a complex GUI in it a pain, but then I also find building complex GUI with the MFC/.NET a pain also. Additions likes Jgoodies (http://www.jgoodies.com/) provide some handy, good looking components for Swing, and there are some good visual tools around (Netbeans, which I mostly use for this at the moment, but I also really like the look of SpeedJG(http://www.wsoftware.de/SpeedJG/)). Add good additions to base Java like Webstart, and the increasing presence of up-to-date JRE's even on Windows machines, and client side Java is looking pretty healthy to me. There are some great examples of really pretty Java UI&#8217;s around now &#8211; have a look at Jose (http://jose-chess.sourceforge.net/), for instance. Oh, and there are a number of alterative GUI libraries for Java, among them SWT, thinlet (http://www.thinlet.com/) , droplets http://www.droplets.com), and a number of other open source GUI frameworks.

I've been struck recently by how many of the tools I use these days have Swing based front-ends. My two IDE's of choice (IDEA and Netbeans), a lot of the big system tools (Candle Omegemon XE/DE, Tivoli Performance Monitor), lots of DB tools (Oracle DBA Studio, DB Visualizer), and SmartCVS (http://www.smartcvs.com/)- a Godsend to CSV users everywhere, to name but a few.

If you regard all those messy PHP-apps, JSP-with-all-database-code-included-in-the-JSP-Page-Webapps etc. around, you might come to a different conclusion.

Indeed there are many server-side tecnologies that may make server-side apps have a superior design, but I think there are so many messy webapps around that you cannot conclude that this is generally the case.

/Jo

However, as a whole I have to give server side development a much higher grade in this area. I'm curious why server side developers think this is?

Thin client and fat client are rival architectures. Apparently thin client proved better in the field. The decisive factor is that central administration reduces the number of application installations needed to accomplish the same work. And since the corporate LAN is where the money is, the emphasis has been on populating the intranet with high quality server applications, and the wage bill for this is immense. Webstart achieves ZAC and could tilt the balance toward fat clients. The cool thing about fat client is that the back office can be dedicated to what it does best: serving files and records -- raw content. By minimizing the load upon the server side, fat client is more scalable than thin client. And REST is a good philosophy for making fat client succeed.

Good point on the hardware side... that was definately a factor with IBM and others.

However MVC is certainly more suited to gui design than server side. Technicaly, SWING has MVC, but even struts DOES NOT. There is no model to speak of... you build that. Struts and others are VC frameworks, and they do not provide model support of any kind.

Also as I remember the definition, a fat client connected to a server. Two points here 1) fat clients are only a small subset of the SWING apps available and 2) pseudo fat clients are the future. Look at RIA applications and FLEX XML from Macromedia. Rich Internet Applications, which I see as pseudo fat clients, are going to be the future. HTML, javascript, and other technology development is coming to an end. Microsoft is stopping internet explorer development soon. So RIAs are the only new thing on the horizon in this area.

More 2 cents... :)

I'm more of a serverside guy for exactly the reasons stated in the article: it's more organized and I have more control.

I've done very little client side development, fat and thin, and found it positively painful. Web apps are the worst. You have to assemble your UI with a jumble of nastiness: JSP, JSTL, JSF, tag libraries, CSS, HTML, Javascript. You have to test in multiple browsers and insert all sorts of little quirks where the behavior is different between them. Its also easier to mix concerns together on the client side than on the serverside (IMHO).

I feel like the tools for developing client side apps aren't as mature as they are on the server side. Perhaps because client is more open-ended and it's difficult to build components that are reusable across projects throughout the industry?

This is one of the goals of WebOnSwing Application Framework.
All the power and simplicity of Swing can be used to develope web applications! Not only for web enabling Swing desktop applications, also you can make applications with html templates for proffesional designs, handling page state as .NET viewstate, use a powerful validation engine, etc.
The whole aproach is similar to .NET but decoupled. As Swing has a very abstract architecture for UI, a Swing application can be deploy in any environment, such as web, desktop, flash, pdf, or any other UI.
It's simple, WebOnSwing adds a new layer that wrapps Swing applications and handles the interations of html, http, and every web task. So you develope your application exactly the same way a desktop one, and then, in other layer you may handle web specific behavior, if it's required.
And you dont have to decide what technology is better for your project, you create your application and you could make your decision later, or even change the deployed environment when it became obsolete or your bussiness required another one.

WebOnSwing is an open source project licensed under LGPL.
http://webonswing.sf.net

I think one reason for there being less client side tools of a certain quality is that the big companies (like Sun, IBM, etc) don't have such an interest in the client side. Sun and IBM like to sell hardware and services off the back of Java. In terms of getting a return on investment, they are going to work on server side tools before client side. It's not that they ignore the client side, just that it isn't a top priority.

I think this means that this means we tend to have smaller companies working in the client side (than the server side), and no clear leaders driving the direction that client Java should take. When you also factor in the range of OS' and their own non-Java frameworks, there's plenty of reason why client side java hasn't taken off.

scope: Server systems are far more constrained, both in terms of function and structure. (This allows for better idealization (e.g. patterns, frameworks, etc.)

rigor: Server application systems require (at least theoretically) a greater degree of rigor given the definitive business function (aka the bottom line).

failures: Of both Sun and Java community to (respectively) educate and use Glasgow -- a fine "client side" framework that is unknown to 99% of the community as far as I can tell. (Please compare this with System.ComponentModel {ISite, IContainer, IComponent} in .NET!)

failures: of both Sun and Java communities to build on the Compoent Model to deliver Tools -- tools allow for the less experienced programmer (such as the poster here in this thread who believes 'MVC unsuited for client side work') who do not have the necessary experience to recognized and use available technologies and techniques on the Server side.

(Since all the whiz kids like to play with the sexy tools, and for 80% of Java's lifetime that has been Server technology -- and so, the less exprienced developers (who only know of "MVC" because of Struts) do not have access to pedagogical resources on how to organize and clarify their client side work.)

The component model of Java has 3 distinct layers -- 2 of which are inherently neutral about the deployment context. (Only J2EE is specifically server centric.)

1 - Java Beans
2 - Contextual Java Beans
3 - Enterprise Java Beans

Sadly, it was precisely #2 (Glasgow) that was necessary for building robust (context neutral) frameworks addressing the whole stack on Java.

But it is not too late.

p.s. MVC was invented/discovered in the course of designing SmallTalk's **GUI**.

I share this perspective.

The BeanContext API (java.beans.beancontext) is a great vehicle for modeling a Swing UI from an XML descriptor. Forget XMLEncoder/XMLDecoder being able to persist the state of a real Swing application. Implement JComponents as bean context proxies and serialize to XML only the bean context hierarchy. This tree structure, each bean context has a parent bean context, consists of the bean contexts' properties and the state of the descriptors of bean context services, which "plug into" the bean contexts. Add support for web services and stir.

First, I wouldn't claim any of the web technologies as "good". Struts, Tapestry, and Webwork are interesting in design, but the page design technology is really half baked. The DOTNET side is flat out a better architecture, and it could certainly be designed and implemented in Java.

Anyway... the answer is unquestionably "yes". I had my first hard core taste of SWING on my current project. It's quite absurd how much work it is to get a "form" built and working. I even have to go to the net and find out how to intercept the escape key for a JFrame so the popups dialogs would close on escape key presses.

Crap like this should be built in to SWING, and it should be easier to find/use. Other items like standard JTree usage, convenience methods, XML based client config management, a better/cleaner layout management system, and various other items need to be in SWING as well IMHO. Also client wide button/component spacing and client wide frame/panel settings need to in there as well. I mean, even the buttons won&#8217;t pop back up if you don&#8217;t put the processing logic in a thread of its own.

So all these items have contributed to developers using SWING &#8220;only when required&#8221;. At the other end, server and enterprise server licensing is expensive on Microsoft tech in comparison to J2EE. Development tools and platforms for server design are, for the most part, as good as .NET. .NET wins in some areas and looses in others, but the cost for many is a huge decision maker.

Along with this, the typical cost of a server solution implementation is much higher than client development, and the return for a developer is pretty much immediate. Businesses are more likely to purchase niche solutions and tools than end users. Businesses purchase/build more server apps than client apps. Developing end user applications, which is where SWING thrives, it costly and expensive to market.

Just my 2 cents&#8230; well, more like a buck fifty. :)

At the other end, server and enterprise server licensing is expensive on Microsoft tech in comparison to J2EE

Are you sure?, IBM WebSphere, or any other J2EE App Server are quite expensive. OTOH, The .NET "App Server" counterpart is free, when you buy your Windows Server, .NET comes on board, and if you are using a previous Windows version (like 2000), you can always download it for free.

Professional nessaging support doesn't come up free in the J2EE world either, stuff like MQSeries or Sun's Message Queue Server doesn't come up cheap. MS counterpart, MSMQ comes already installed on the Windows platform, if we talk about other enterprise software like MS DBMS, Integration Server, etc are also less expensive.

Cheers.

Yeah right, Like Microsoft like Sun, if you buy solaris, it comes with lots of stuff and they are planning to add more stuff like sun app server etc.

First, I wouldn't claim any of the web technologies as "good". Struts, Tapestry, and Webwork are interesting in design, but the page design technology is really half baked. The DOTNET side is flat out a better architecture, and it could certainly be designed and implemented in Java.

WebForms are page based too. Check out Echo for a better architecture.

First, I wouldn't claim any of the web technologies as "good". Struts, Tapestry, and Webwork are interesting in design, but the page design technology is really half baked. The DOTNET side is flat out a better architecture, and it could certainly be designed and implemented in Java.

I am certainly no DOTNET expert, so I wonder which features of DOTNET architecture do you have in mind when making this statement?

First, I wouldn't claim any of the web technologies as "good". Struts, Tapestry, and Webwork are interesting in design, but the page design technology is really half baked. The DOTNET side is flat out a better architecture, and it could certainly be designed and implemented in Java.

I am certainly no DOTNET expert, so I wonder which features of DOTNET architecture do you have in mind when making this statement?

Check out JavaServerFaces, it's near an exact replica of ASP.NET

I have done some swing work,3 years back. When running, it used to take 60MB of space, same functionality VB application used to take around 10MB.
MVC architecture swing uses is very good but with regards to speed and memory it really sucks.

Over past few years considerable advances have been made in running-speed of non-GUI applications.But nothing has changed in swing performance.

May be Sun should think about SWT one more time. Eclipse occupies just 25MB and is very responsive and widgets look better than swing.

We can compare XWindows and MSWindows(windowing arch) here. Former is architecturally superior but mostly slow.(I dont want to start religious war here)
I feel windows is more responsive than kde or gnome(Subjective feeling though).

i;ve been developing swing apps for about 5 years now - starting with JDK 1.2. I'd have to say that swing in jdk 1.4 performs really well, on both linux and windows. of course, performance really depends on how the application code is written.

btw, i'm curious exactly what do you mean by "60mb of space"? is it swap file size?

I have done some swing work,3 years back. When running, it used to take 60MB of space, same functionality VB application used to take around 10MB. MVC architecture swing uses is very good but with regards to speed and memory it really sucks.

For the poster that says Swing hasn't changed much, maybe you should try it for more than, oh, say 3 minutes before making such a blanket statement. 60MB? You must have been doing something VERY VERY bad, which based on the way you are stating things, I would guess is correct. See, it's just like developers like this to make crap claims with little experience. What's worse, a few comments like this cause other less capable developers to think along the same lines.

If people would depend less on hear-say and more on actual experience and research, Swing would be used a lot more than it is today. There is no doubt about it, Swing is not VB, it's not super easy, but it is very capable and since JDK 1.2 has matured immensely. There are indeed some things that should be standard affair in Swing by now, I agree. But even so, I have yet to be able to work around them either by doing code myself and doing a little googling and finding a solution. Swing has been around more than long enough such that tons of solutions abound for just about anything you can come up with.

It's really sad how much Swing is bad mouthed by those that try a couple things and give up before digging a little further. These are the types of developers I am all too happy see move away from Java. They lack the ability true professional developers practive every day, learning and becoming better from learning. Instead they want a quick solution and if they can not build something in an hour, they are confused, upset and off they go to tell the world how bad Java Swing is.

Part of my goal with my open source projects is to provide the community with powerful, professional tools to build Swing apps better and faster. While not yet done, I am hoping sooner than later my plugin engine and pluggable application framework with various extra components will soon be available and used by many more. You can bookmark www.platonos.org, in a few weeks time the new site will be up and the projects will be accessible.

I agree. Well said.

There is no doubt about it, Swing is not VB, it's not super easy,

And I, for one, am glad it is not VB. VB is ok if you were (past tense cause it is for new stuff. Or at least should be.) doing simple apps. I did VB for years before doing Java. It is much easier to code complex apps in Java than VB because of OO and that Java IDEs are made with OO in mind. Unfortunately VS.Net continues to make the life of an OO developer difficult but definitely much better than VB6.

(Yes I know classic VB had OO concepts and that is where I form many of my OO ideas and thus lost much of my hair trying to do it in VB)

Great to hear from lot of Good Programmers.That 60MB application has image manipulation code and displays lot of other data that it reads from a server.We desparately tried to reduce the memory it occupies by doing following.
- Firstly by reading every Java performance book available on the market(that time) and implementing techniques outlined.
- Zooming and keeping only part of the image that is visbile on the screen.
- Lazy loading of data and Tabs(in tabbed pane)
- Removing unused or not-visible JPanels.
- Even garbage collecting classes(NOT objects)

Each line of code is reviewed by whole team(many times,since as I said we are screwed).

For quality of work that is done.
- Created exact look a like of MSOutlook like shell.
   (*with jumping of buttons
    *images and lables in side pane
    *even the scroll bar with out scroll and only buttons...)
- Excel style data sheet.(like first column does not move if you scroll to side ..)
- Popup Calendar that disappears when you click else where(sounds simple but try that)

May not be as geeky as hacking javaVM, but certainly I can say this is not student-programmer type coding.
I do LOVE java. I think At the same time we should not try to cover up disadvantages it has.

Even now Iam running an application that connects to MQSeries and shows the messages on the queue.It is occupying 20MB(Not even connected to queue).It has total of 15 buttons(including toolbar buttons) and may be 10-15 menu items and empty JTable. It is not written by me, it is from a big company. So no chance of student coding.

Did you manage to reduce the memory occupied by the app at all (with the measures you list)?

BTW JCalendar project on sourceforge has a nice popup calendar.

I've also found that Swing apps tend to use a fair amount of memory, although it's never been necessary for me to go to the lengths you did to try to reduce it. I'm guessing it's partly because each app has it's own JVM so all the core classes get loaded each time the app is opened. I think that the Apple JRE does something with memory sharing between JVMs, and possibly Sun's 1.5 does something about it too?

Apologies to all for getting away from the original thread.

Sounds like it was quite a large app and complex. It is reasonable that it takes up quite a bit of memory.

BTW, just because an app comes from a large company doesn't mean it isn't coded student style. I've seen plenty of bad coding come from large companies. For instance the example code that use to come with MQ Series. Hmmmm. :) (Really, it did and really it was BAD)

Sounds like it was quite a large app and complex. It is reasonable that it takes up quite a bit of memory.BTW, just because an app comes from a large company doesn't mean it isn't coded student style. I've seen plenty of bad coding come from large companies. For instance the example code that use to come with MQ Series. Hmmmm. :) (Really, it did and really it was BAD)

ROTFLMAO. first off, MQSeries rock and I know several people who swear by it. the bad examples are probably because it is written by newbie programmers. senior guys have better things to do. I'm sure most senior developers have done that once or twice.

Sounds like it was quite a large app and complex. It is reasonable that it takes up quite a bit of memory.BTW, just because an app comes from a large company doesn't mean it isn't coded student style. I've seen plenty of bad coding come from large companies. For instance the example code that use to come with MQ Series. Hmmmm. :) (Really, it did and really it was BAD)

ROTFLMAO. first off, MQSeries rock and I know several people who swear by it. the bad examples are probably because it is written by newbie programmers. senior guys have better things to do. I'm sure most senior developers have done that once or twice.

Oh, I love MQSeries. The point was - big company != good code.

Sounds like it was quite a large app and complex. It is reasonable that it takes up quite a bit of memory.BTW, just because an app comes from a large company doesn't mean it isn't coded student style. I've seen plenty of bad coding come from large companies. For instance the example code that use to come with MQ Series. Hmmmm. :) (Really, it did and really it was BAD)

ROTFLMAO. first off, MQSeries rock and I know several people who swear by it. the bad examples are probably because it is written by newbie programmers. senior guys have better things to do. I'm sure most senior developers have done that once or twice.

Oh, I love MQSeries. The point was - big company != good code.

Oh, and unfortunately way too many people use these examples as "how-to-do-it". Even at large companies. :)

Oh, I love MQSeries. The point was - big company != good code.

yeah, I got that :) I don't think anyone using MQSeries would misinterpret the comment. especially not a bank using MQSeries to handle thousands of message per second 24/7.

back on the topic of which side is more organized. I'm not sure I buy the argument myself, since I've met good programmers who can write well structured code regardless of whether it's client or server side. I've also met really bad programmers who can't get it right regardless of what they are writing.

May be Sun should think about SWT one more time. Eclipse occupies just 25MB and is very responsive and widgets look better than swing.

STW widgets look better? You can make swing widgets look like eclipse. Take a look:
JGoodies
or even take a look at Hibernate IDE HibernateIDE

JGoodies provides a really slick L&F but still its not native. If I skin my XP machine, the SWT widgets (if not skinned like in eclipse 3.0) will be undistinguishable from native widgets while JGoodies will keep its hard-coded (and desktop-wise alien) look.
Swing has always played catch-up, concerning L&F, with the various OS (excluding MacOSX where Apple has done a magnificent job in provinding the AquaL&F for Java).

JGoodies provides a really slick L&F but still its not native. If I skin my XP machine, the SWT widgets (if not skinned like in eclipse 3.0) will be undistinguishable from native widgets while JGoodies will keep its hard-coded (and desktop-wise alien) look.Swing has always played catch-up, concerning L&F, with the various OS (excluding MacOSX where Apple has done a magnificent job in provinding the AquaL&F for Java).

Funny how many native apps actually try to be different and that is ok (i.e. Windows Media Player).

Also, this same "problem" (they don't look native) seems to be OK for Web Apps.

Funny how many native apps actually try to be different and that is ok (i.e. Windows Media Player).

Recently someone in a TheServerSide thread claimed that Microsoft Office owes its dominance to its custom widgets and avoidance of MFC's public widgets. So I agree with you that Swing is being unfairly bashed by a double standard. Sure, our paying beta customers find problems with our fat client, but they've never complained about Swing. And our developers haven't suggested an easier widget library for rapidly cutting production code.

I have done some swing work,3 years back. When running, it used to take 60MB of space, same functionality VB application used to take around 10MB. MVC architecture swing uses is very good but with regards to speed and memory it really sucks.Over past few years considerable advances have been made in running-speed of non-GUI applications.But nothing has changed in swing performance.May be Sun should think about SWT one more time. Eclipse occupies just 25MB and is very responsive and widgets look better than swing.We can compare XWindows and MSWindows(windowing arch) here. Former is architecturally superior but mostly slow.(I dont want to start religious war here)I feel windows is more responsive than kde or gnome(Subjective feeling though).

I'm curious, is that 60MB including loading data? For comparison, I started JMeter2.0 and it takes 30-32Mb of RAM without opening a test plan. The total memory used is largely depedent on how much data you're loading. JMeter is pretty heavy by itself, but unless you're counting data, it really shouldn't take 60Mb. This is running on Jdk1.4.2.

If your example includes loading data, then I would say that it is a design issue. Loading lots of data un-necessarily is going to create memory issues regardless of the GUI toolkit you use. Personally, I like SWT, but when used carefully, Swing can be quite fast. Swing is no longer slow, but it does need lots of RAM. Even for an app like JMeter, which has a ton of threads simulating load and updating the data model, Swing redraws the GUI just fine.

Swing can be quite fast. Swing is no longer slow, but it does need lots of RAM. Even for an app like JMeter, which has a ton of threads simulating load and updating the data model, Swing redraws the GUI just fine.

On my last project, I we started to develop a swing version of our web app (it became difficult to maintain/develop and the network had, uh, issues, etc.). Oddly, for much more usability and the same business functionality it used slightly more RAM than IE did when viewing the web app. But we were able to cut down on alot of code because it was very easy to make reusable pieces. Even more interesting. The basis for the code was a conversion of an Echo demo app. Took me less than an hour including doing the Web Start stuff. :)

Unless they fix those student-grade programming errors which have been around as long as I can remember Swing. For example font rendering is still broken after all these years, circle drawing is broken ... What the hell is wrong with these people ? Can't they see those ugly fonts ? No one can take seriously a GUI app, which has this kind of rendering errors.
Programming in Swing is actually quite easy, when you get used to it and GUI tools actually make you less productive. The framework is quite good in my opinion, but please Sun, do something about the fonts and make a modern Look&Feel. Nice try with renewed Metal L&F in 1.5, but I think it looks almost as bad as the old one.

Unless they fix those student-grade programming errors ...

And yet you probably are using a Windows PC. That everyone seems to be able to deal with.

You call JDO, Hibernate, etc. datawarehousing middleware? Hmmm - what's next? Given the "Enterprise app" is already abused, I guess, configuration files will be called "Storage solutions"??

I am suprised that none of the previous posters commented on it. Datawarehousing and Java are simply not related as all.

I don't think that it is a matter of the server side being more organised, but merely because there is more scope for Java developers in this arena. The fact is that Microsoft have a stronghold on the desktop and therefore of client side development tools. Java developers, realising this, have ceded this territory to VB drones and moved on to areas where they can actually apply interesting technology. In most enterprise environments, it is difficult to convince management that a client-server side application should be developed in Swing, although writing a thin client interface using Struts is o.k.

In summing up, I'd say that server side Java technologies are more mature purely because the server side is a much more fertile domain for Java technology.

I've been wondering something over the last few days. With the server side space we a good amount of organization. In the datawarehouse space you have JDO, Hibernate, OJB, etc. Web frameworks have Tapestry, Struts, and Webwork. J2EE has an admitted imperfect but semi standardized spec and collection of implementations. Yes there are smaller projects and ones that never get off the ground just like the client side. However, as a whole I have to give server side development a much higher grade in this area. I'm curious why server side developers think this is? I know many of you code on both sides. Is it the number of developers? Is it the need is just not large enough to reach critical mass? Is it just a simple case of individuals and companies following the money?

I don't think that it is a matter of the server side being more organised, but merely because there is more scope for Java developers in this arena. The fact is that Microsoft have a stronghold on the desktop and therefore of client side development tools.

I couldn't agree more. Part of the main issue holding SWING back from the desktop is the lack of standards in the _tooling_ space. I've seen projects die out because the rapid wysiwyg tool has been outdated by a newer, great IDE that doesn't support the old development sources.

It doesn't matter how quick you are with vi, swing by hand cannot compete with GUI builder ide's.

The lack of choice in the m$ space means it is not a problem. Java developers, however expect choice, both in their runtime platforms and development platforms. J2EE has reached a pretty good point for flexibility in platforms, but SWING development has a long way to go before it supports flexibility in development platforms.

The original java beans specifications were very insightful, but unfortunately just did not cover this space. When (never?) you can take a netbeans application and continue the drag and drop development across eclipse, jbuilder, and intellij, swing development may start to gain some cred.

<When (never?) you can take a netbeans application and continue the drag and drop development across eclipse, jbuilder, and intellij, swing development may start to gain some cred.

I doubt that will ever happen. I agree that it would be nice. But I don't think it is important. Many exeperienced Swing developers might start out using GUI Builders but eventually begin hand coding it. I did the same. Why? Cause GUI builders are not as effiecent as a human. Mucho duplicated code. Doesn't matter the language.

Many exeperienced Swing developers might start out using GUI Builders but eventually begin hand coding it. I did the same. Why? Cause GUI builders are not as effiecent as a human. Mucho duplicated code. Doesn't matter the language.

I'm not a fan of GUI builders for Swing. I reckon that if they're proving to be a significant time-saver, it's probably an indication that making / using some simple reusable components or a lightweight framework would save more time and make the UI more consistent and maintainable.

Many exeperienced Swing developers might start out using GUI Builders but eventually begin hand coding it. I did the same. Why? Cause GUI builders are not as effiecent as a human. Mucho duplicated code. Doesn't matter the language.

I'm not a fan of GUI builders for Swing. I reckon that if they're proving to be a significant time-saver, it's probably an indication that making / using some simple reusable components or a lightweight framework would save more time and make the UI more consistent and maintainable.

See?

I sometimes them as a starting point. Then refactor and go on with or with out it.

Hi,

i've done client stuff in Win32/MFC/Objective-C/Swing/VB.NET and server side stuff mostly in Java.

The answer to "Is serverside more organized than clientside?" is quite simple:
because server development is easier than client side development, it can be more organized.

On the server side, your design is about 90% right when you consider
o use cases are stateless, or most of the state is provided by the client/database
o a clear seperation between use case code and data access code
o a clean data acess code, either with ORM or DAO
o not to much mixture between technical and business code
o propper optimistic/pessimistic locking, esp. for long running transactions ("business transactions")
o adiquate batch processing
o loose coupling with neighbor systems

For client side code, there is no such list "90%" list.
There is not one good book about client design (in terms of code, there are some very good ones about usability).

Another reason why a lot of developers shy away from the client side is that they are always compared to Excel/Outlook/..., whereas a corporate server side developer usally does not compete with Amazon or eBay.

For some strange reason, server side development still has more prestige than client side stuff, so more senior developers are working on the server side, which also is bad for organizing the client development.

Bye,

Jürgen

I've done a lot of client-side programming using Swing. Swing has a fairly steep learning curve, but it's very flexible in terms of what you can do with it. Practically anything in Swing can be customized: I think that this is only possible because of the relatively complex, but well designed, architecture of the Swing packages. I'd choose the flexibility of Swing over the simplicity of VB any day.

Re: performance concerns relating to Swing, I find it hard to see how these can be justified. I purposely program Swing UI on an 800 MHz computer with not much RAM, just to make sure that performance is likely to be OK on most desktop computers. I've not had any problems with Swing performance on a computer with this pretty low spec.

The benefits of Java on the desktop are significant: it should run without modification on Windows / Mac / Linux. Surely this is more important on the desktop than the server? Deploy with Java Web Start and you can have one-click installation and easily-configured automatic updates.

I don't think that anyone with a good grasp of Java and OOP should have significant problems picking up Swing, and using it to make GUIs that perform well and look good. But maybe it's these requirements (good grasp of Java and OOP) that are the problem, or arguably the lack of good tools for Swing development. There are plenty of IDEs around to help mediocre developers stumble through in the glamorous world of 'J2EE development', somehow making functional code, yet without really knowing Java, OOP or the J2EE APIs properly. I seriously doubt that such a programmer could use existing tools to make a desktop app that didn't have sh*t written all over it.

I'm convinced that Java on the desktop is a great thing. However, for it to become as popular as Java on the server-side would require more people to appreciate the benefits, and less people to believe the myths (poor performance). Better tools / frameworks could help to lower the barrier to entry, but for this there'd probably need to be a greater demand for Java on the desktop: a chicken and egg situation, perhaps...

Cheers
Martin

The reason why the serverside seems more organized is that it gets more RESPECT that the clientside.

It amazing me the total lack of understand of what SWING happens to be. It is not the JAVA equivalent of VB development. It is the equivalent of using the Windows C API. Every one that complains about SWING compares it to a light GUI developemnt *language*. No one has the kohones to compare it to using the X API, the Windows C API, or even Motif.

When it comes to GUI's, developers get real lazy, because it's so hard :(
This is illustrated by the ratio of Open Source Java server apps, libraries and framworks to the number of Open Source java web applications. (i.e. Tomcat, Struts and WebWorks are not web apps. OpenCMS is a web app). And we all know SWING is hard that DHTML.

It's all about respect. Respect gets the money. Respect get the time.

Comparing Swing to the Windows SDK it seems to me a bit excessive. I think its more like the MFC: you can do whatever you want with it but it take quite an effort.

Comparing Swing to the Windows SDK it seems to me a bit excessive. I think its more like the MFC: you can do whatever you want with it but it take quite an effort.

Even MFC is a stretch. Swing development doesn't take that much effort, once you've gone through the learning phase. And that depends mostly on ones ability and motivation.

If you're an OO guy, Swing will come quite naturally to you. I didn't experience any learning curve at all. The problem I have with Swing is that it doesn't take advantage of any of the widgets from the native windowing system. Because of this, Swing will always be seen as a performance problematic GUI.I have written several very complex Swing desktop apps. One of them being a "point of sale" desktop. Lots of image buttons, IO,JMS bound stuff happening in the background. I must say that at least on a Linux platform, performance and memory were not a problem.

Yeah, except MFC had tools that gave you immediate gratification.. you could quickly build the basis of an app. It also had the advantage of separating all the mundane UI configuration into a resource file.. so your code wasn't all full of yucky layout stuff. Much better for beginners.. I can still develop guis faster using Visual C++ than w/ Java, and I've practically forgotten all my MFC.. ::(

Yeah, except MFC had tools that gave you immediate gratification.. you could quickly build the basis of an app. It also had the advantage of separating all the mundane UI configuration into a resource file.. so your code wasn't all full of yucky layout stuff. Much better for beginners.. I can still develop guis faster using Visual C++ than w/ Java, and I've practically forgotten all my MFC.. ::(

Hmmm. Maybe you just need to spend a little more time with Java. For me, Java was about as easy as VB, but definitly more rewarding in terms of flexibility.

When it comes to GUI's, developers get real lazy, because it's so hard :(

Are you suggesting that the reason why server applications have higher quality is because they're easier to develop? Exactly how is it that fat GUI development less feasible?

Are you suggesting that the reason why server applications have higher quality is because they're easier to develop?

Funny to hear (read) "server app" and "quality" and "easier to develop" all in the same sentence. :)

Are you suggesting that the reason why server applications have higher quality is because they're easier to develop?

Funny to hear (read) "server app" and "quality" and "easier to develop" all in the same sentence. :)

Easier? No. :) They are hard, but in a way programmers like it! :) This probably doesn't make much sense.. Let me try agan.

First, data-processing-wise and algorithmically, a server side MODULE does more than the client app. And this is natural, client side's job is to display stuff. But, just because of the nature of this, you have a module that has little input, lots of processing and some output, and once you tested this module, you have accomplished a lot. We can't say the same testability bang-for-a-buck ratio for client side apps. So... ok... For server side and within a module, we can be fairly complex, on client side branching btw various modules makes testing very hell. You can't script, you can't automate.. As a result, you will have more quality on the server side than on the client side.

Easier? No. :) They are hard, but in a way programmers like it! :) This probably doesn't make much sense.. Let me try agan. First, data-processing-wise and algorithmically, a server side MODULE does more than the client app. And this is natural, client side's job is to display stuff. But, just because of the nature of this, you have a module that has little input, lots of processing and some output, and once you tested this module, you have accomplished a lot. We can't say the same testability bang-for-a-buck ratio for client side apps. So... ok... For server side and within a module, we can be fairly complex, on client side branching btw various modules makes testing very hell. You can't script, you can't automate.. As a result, you will have more quality on the server side than on the client side.

Ohh. What you really are talking about is GUI vs "Domain" development. I think, even though the title is Server vs Client, the topic for this thread is Client UI (Swing/SWT/..) vs Server UI(Struts/JSF/...). And we are getting crossed up. Maybe the assumption was bad on my part. Especially since Hibernate and JDO (etc) are not serverside exclusive technologies.

When it comes to GUI's, developers get real lazy, because it's so hard :(

Are you suggesting that the reason why server applications have higher quality is because they're easier to develop? Exactly how is it that fat GUI development less feasible?

Assuming that by quality you mean better organization. Quality is only achieved because the task is understood and time can be devoted to where to the issues that count.
What counts in a GUI are aesthetics and the ability of user to understand enough of an interface to figure out the rest; along with the clues and information to confirm assumptions. These are advanced concepts. With ground up GUI development, the application developers are left to their own devices.


http://developer.gnome.org/projects/gup/hig/
http://developer.apple.com/documentation/UserExperience/UserExperience.html
http://java.sun.com/developer/techDocs/hi/

Good to see you, Aris.

It's been my experience that most developers aren't fond of client-side analysis or development. It's the "face" of the application to the users, and thus can become a real cluster to work through with them. So, I think more attention has been focused on server-side tools, simply because that's where the bulk of the interest is. There's also a lot of subjectivity on the client side, server side is "cleaner" to work with. Clearer about what is right, what is wrong. Giving you more tools to develop a user interface, technically, doesn't necessarily make it easier to develop a USABLE interface from the user's point of view. I think it's a messy area to get into, so for various reasons, it hasn't been explored as much.

Jen

There's also a lot of subjectivity on the client side, server side is "cleaner" to work with. Clearer about what is right, what is wrong.

Doesn't this imply that server development is easier than client development?

Doesn't this imply that server development is easier than client development?Heck no. :) If it does, that's not what I meant. I'd say server-side is more difficult because of the complexity involved, all of the moving parts that have to work together for the system to work. But client-side has its own set of challenges.

You don't have users going through your code and saying "You know, I don't agree with how you did that" (I hope). You DO have users going through a user interface and saying "can you move this over here, and can we make this blue, and why can't it look like this? I want it to be just like Yahoo." You might be able to automatically generate a user interface through a tool, but the users will probably want to go back and change things. It's getting into subjective human issues, and it can be a cluster.

In my experience, the developers I've worked with have preferred to work on server-side issues and stay away from the client. It just wasn't as interesting to them, they preferred to deal with the complexity of the server-side problems. So, I think there would be more tools available on the server side because that's where developers have chosen to spend more of their time and energy thus far. However, I've seen that changing in the past couple of years.

Jen

There's also a lot of subjectivity on the client side, server side is "cleaner" to work with.
Clearer about what is right, what is wrong.

Doesn't this imply that server development is easier than client development?

It depends on the definition of "easy", but i tend to think that server side development is easier than client side development, for details see my previous post.

What counts in a GUI are aesthetics and the ability of user to understand enough of an interface to figure out the rest; along with the clues and information to confirm assumptions. These are advanced concepts.

Are these "advanced concepts" on the client so much harder than server concepts, and the infeasibility of implementing the "advanced concepts" cause client applications to have less quality than server applications?

With ground up GUI development, the application developers are left to their own devices.

Which "devices" should they use? Are you suggesting that server applications have higher quality since they have better reusable frameworks?

I think the reason for better organization is that the "inputs" and "outputs" for a server side module is much easier to define. The one reason I don't like client side programming (and I know many feel the same way), there is way too many client requests (both as technology, and as requirement definition). In terms of requirements, users will go "oh, can't we have this there, and that there?". Grrr. In terms of technology, there are events, there are dialogs, threads, so on. So on client side you are handling a many headed if-statement monster. You handle all, then the user will find one path that you hadn't though of. On server side, I exercise all paths with my unit tests, they are closed, black box, all necessart for application logic and away from the hands of the user. The input are some strings, the output is another set of strings. Simple.

Interesting. There&#8217;s a very good (and rather amusing) book on UI design you might enjoy &#8211; "User Interface Design for Programmers" by Joel Spolsky. It gives a good set of principles for designing user interfaces and is one of the most helpful books I&#8217;ve read on this topic. http://www.amazon.co.uk/exec/obidos/ASIN/1893115941/qid=1096293310/ref=sr_8_xs_ap_i1_xgl/026-4086350-5216438

What?

It sounds like you just said you don't like client-side dev cause the users can actually get what they want and need in the way of user experience and funtionality. (and I agree that it does). And you don't like doing that.

I think the reason for better organization is that the "inputs" and "outputs" for a server side module is much easier to define. The one reason I don't like client side programming (and I know many feel the same way), there is way too many client requests (both as technology, and as requirement definition).

Are you suggesting that client applications are typicly more complex than server applications, and this is due to server applications having fewer custom features and fewer control flow paths?

I've said this over on the JL thread.

If we are talking about Server-side UI vs Client-Side UI dev, then I would say that is not more organized. The plethora of frameworks points to this being true. Everyone keeps trying to make server-side UI dev easier (For Web Apps - Not web sites). The closest anyone has come is Echo and WebOnSwing (and the like). If you don't believe me, download EchoStudio or WebOnSwing (etc.) and try them. And if you are worried about session replication, see Cameron. :) And they kick ASP.Net's behind (Speaking from experience with ASP.Net and Echo).

What does the client need? GUI builders for Java have been around for awhile. So you can't import from one GUI builder to another. Communication with the server? Choose your method (Web service, RMI, EJBs, POJOs over HTTP, etc). How tough is it? How easy do you want it to be?

and only sells (propratory?) servers.
That is why client side is very old.

UIis easier than server side becuase you can see the mistake right away, IMO.

.V

Swing can never be used to desktop applications. The real problem is that Sun does not believe in "playing nice with others in the field". I think the bigger problem is that Sun has no experience developing GUI applications. Microsoft knows what it takes to build GUI applications, SUN doesn't.

There are a million things that cannot be done with Swing. For example, I can't work with the windows iconbar. I can't read the windows title bars of other applications (easy to do if you use VB and windows API). I don't have a powerful HTML editor (Microsoft provides IE control which is quite powerful. Google Deskbar uses this control. The HTML editor provided by Swing pales in comparison with what the IE control can do). I cannot write a Mail Merge feature that required interfacing with Microsoft Word. SWING is so restrictive in what it can do. The File Explorer feature of swing just does not not look as good as the MS Windows counterpart.

The market for apps written in Swing will always be limited. Look at the desktop applications written by third party companies like the Google deskbar, or any of the MP3 players like iTunes/RealPlayer. These are never written in Swing. Only companies that have a significant stake in the Java market like TogetherJ or IntelliJ bother to develop applications in Java. This is because they can claim it is "fully written in Java". It is a marketing point. The only quality GUI application that was ever written in Java was Eclipse. IntelliJ is good too. The rest are just so-so.

The problem can be solved if we have a common platform wherein we have a standard and uniform Java client platform like windows. Microsoft seems to have got it right with their active desktop using Web Services for their client products like MSOffice.

Maybe, just maybe Java desktop is the key. Will it be accepted in its entirety by the market is of course debatable.

-Aejaz

There will be always a big gap between functionality and usability of apps. Since users asking for better functionality we have to deal with client side too. Now, we are talking about RIA (rich internat applications) era, like Flex2. We have to deal with this beemsy clumsy coding choices until some one comes and invents a better Quantum cpus, better ceramic disks or even better adaptable biological computers. At the end, we need more scientists, not a every day coders :)