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?
-
Ask TheServerSide: Is serverside more organized than clientside? (74 messages)
- Posted by: Scott Delap
- Posted on: September 23 2004 14:23 EDT
Threaded Messages (74)
- Possible reasons by Mileta Cekovic on September 24 2004 12:10 EDT
- Possible reasons by hthjf fgfgfg on September 24 2004 14:21 EDT
- Client Side /server side BS by The Industry Observer on September 24 2004 14:32 EDT
- Not BS by Leif Ashley on September 24 2004 02:40 EDT
- Possible reasons by Edgar Silva on September 27 2004 00:38 EDT
- Possible reasons by Mark N on September 27 2004 08:21 EDT
- I'm not so sure by Fred Bloggs on September 27 2004 08:08 EDT
- Regard the overall picture, not only the cutting-edge web-apps by Jo Siffert on September 29 2004 08:30 EDT
- Ask TheServerSide: Is serverside more organized than clientside? by Brian Miller on September 24 2004 12:17 EDT
- Points by Leif Ashley on September 24 2004 13:58 EDT
- clientside is too fidgety by Craig Pfeifer on September 24 2004 12:43 EDT
- clientside is too fidgety by Fernando Petrola on September 24 2004 17:40 EDT
- Is serverside more organized than clientside? by A P on September 24 2004 12:48 EDT
- There are many reasons ... by Joubin Houshyar on September 24 2004 13:31 EDT
- There are many reasons ... by Scott Anderson on September 25 2004 16:01 EDT
- Various reasons... by Leif Ashley on September 24 2004 13:49 EDT
- Microsoft More Expensive? by Ernesto Marquina on September 24 2004 14:20 EDT
- Microsoft More Expensive? by Udayan Patel on September 24 2004 02:40 EDT
- Various reasons... by Mark N on September 24 2004 16:18 EDT
- Various reasons... by Jens Wyke on September 24 2004 17:15 EDT
- Various reasons... by Jacob Hookom on September 25 2004 12:03 EDT
- Microsoft More Expensive? by Ernesto Marquina on September 24 2004 14:20 EDT
- Swing sucks by Yo Man on September 24 2004 14:44 EDT
- Swing doesn't suck by nikita tovsoles on September 24 2004 15:00 EDT
-
Swing rules (re: Swing sucks) by Kevin Duffey on September 26 2004 01:30 EDT
- Swing rules (re: Swing sucks) by Mark N on September 27 2004 08:10 EDT
-
Swing Sucks(Reply to every one) by Yo Man on September 27 2004 04:58 EDT
- Swing Sucks(Reply to every one) by Martin Bromley on September 27 2004 06:17 EDT
-
Swing Sucks(Reply to every one) by Mark N on September 27 2004 09:20 EDT
-
Swing Sucks(Reply to every one) by peter lin on September 27 2004 09:53 EDT
-
Swing Sucks(Reply to every one) by Mark N on September 28 2004 08:36 EDT
- Swing Sucks(Reply to every one) by Mark N on September 28 2004 09:00 EDT
- bad programmers and such by peter lin on September 28 2004 09:49 EDT
-
Swing Sucks(Reply to every one) by Mark N on September 28 2004 08:36 EDT
-
Swing Sucks(Reply to every one) by peter lin on September 27 2004 09:53 EDT
-
Swing rules (re: Swing sucks) by Kevin Duffey on September 26 2004 01:30 EDT
- Swing sucks by Giedrius Trumpickas on September 26 2004 13:04 EDT
-
Swing sucks by Vania Cilli on September 27 2004 08:23 EDT
-
Swing sucks by Mark N on September 27 2004 09:14 EDT
- Swing sucks by Brian Miller on September 27 2004 02:24 EDT
-
Swing sucks by Mark N on September 27 2004 09:14 EDT
-
Swing sucks by Vania Cilli on September 27 2004 08:23 EDT
- Swing sucks by peter lin on September 26 2004 20:33 EDT
- Swing no sucks by Mark N on September 27 2004 08:20 EDT
- Swing will suck forever, unless by Vahur Sinij?rv on September 27 2004 11:18 EDT
- Swing will suck forever, unless by Mark N on September 27 2004 12:22 EDT
- Swing doesn't suck by nikita tovsoles on September 24 2004 15:00 EDT
- Datawarehouse? Gulp! by tom tarb on September 24 2004 18:52 EDT
- Datawarehouse? Gulp! by Adnaan Sikandar on September 27 2004 01:25 EDT
- Is serverside more organized than clientside? by Dominic Cioccarelli on September 24 2004 22:53 EDT
- lack of penetration, lack of standards by Hugh Madden on September 25 2004 03:07 EDT
-
lack of penetration, lack of standards by Mark N on September 27 2004 08:00 EDT
-
Swing GUI builders by Martin Bromley on September 27 2004 10:05 EDT
- Swing GUI builders by Mark N on September 27 2004 10:21 EDT
-
Swing GUI builders by Martin Bromley on September 27 2004 10:05 EDT
-
lack of penetration, lack of standards by Mark N on September 27 2004 08:00 EDT
- lack of penetration, lack of standards by Hugh Madden on September 25 2004 03:07 EDT
- Server side development is just easier than client stuff ;-) by J??rgen Zeller on September 27 2004 02:44 EDT
- Singing the praises of Java on the desktop by Martin Bromley on September 27 2004 06:30 EDT
- GUI development is not for wimps. by Aris Bartee on September 27 2004 08:29 EDT
- GUI development is not for wimps. by Vania Cilli on September 27 2004 08:55 EDT
-
GUI development is not for wimps. by Mark N on September 27 2004 09:17 EDT
- If you're an OO guy, Swing is a piece of cake. However. by Kevin Citron on September 27 2004 12:05 EDT
-
Re: GUI development is not for wimps. by Amin Mansuri on September 27 2004 10:54 EDT
- Re: GUI development is not for wimps. by Mark N on September 28 2004 08:38 EDT
-
GUI development is not for wimps. by Mark N on September 27 2004 09:17 EDT
- GUI development is not for wimps. by Brian Miller on September 27 2004 14:09 EDT
-
GUI development is not for wimps. by Mark N on September 27 2004 02:37 EDT
-
GUI development is not for wimps. by Burak Bayramli on September 28 2004 04:46 EDT
- GUI development is not for wimps. by Mark N on September 28 2004 08:50 EDT
-
GUI development is not for wimps. by Burak Bayramli on September 28 2004 04:46 EDT
-
GUI development is not for wimps. by Aris Bartee on September 28 2004 11:23 EDT
-
GUI Debate by Jen B on September 28 2004 01:26 EDT
-
GUI Debate by Brian Miller on September 28 2004 01:48 EDT
- Neither is easier by Jen B on September 28 2004 02:13 EDT
- GUI Debate by J??rgen Zeller on October 10 2004 05:26 EDT
-
GUI Debate by Brian Miller on September 28 2004 01:48 EDT
- GUI development is not for wimps. by Brian Miller on September 28 2004 01:44 EDT
-
GUI Debate by Jen B on September 28 2004 01:26 EDT
-
GUI development is not for wimps. by Mark N on September 27 2004 02:37 EDT
- GUI development is not for wimps. by Vania Cilli on September 27 2004 08:55 EDT
- Too many brances by Burak Bayramli on September 27 2004 09:43 EDT
- Too many brances by Fred Bloggs on September 27 2004 09:57 EDT
- Too many brances by Mark N on September 27 2004 10:01 EDT
- Too many brances by Brian Miller on September 27 2004 14:28 EDT
- Ask TheServerSide: Is serverside more organized than clientside? by Mark N on September 27 2004 10:18 EDT
- Sun gave up on desktop by Vic Cekvenich on September 29 2004 15:57 EDT
- Swing is not for desktop apps by V K on September 29 2004 17:29 EDT
- Java Desktop Anyone? by Aejaz Sheriff on October 20 2004 03:34 EDT
- New horizon always on the horizon by Gokhan Toplar on November 15 2006 10:41 EST
-
Possible reasons[ Go to top ]
- Posted by: Mileta Cekovic
- Posted on: September 24 2004 12:10 EDT
- in response to Scott Delap
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 -
Possible reasons[ Go to top ]
- Posted by: hthjf fgfgfg
- Posted on: September 24 2004 14:21 EDT
- in response to Mileta Cekovic
<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 -
Client Side /server side BS[ Go to top ]
- Posted by: The Industry Observer
- Posted on: September 24 2004 14:32 EDT
- in response to Mileta Cekovic
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. -
Not BS[ Go to top ]
- Posted by: Leif Ashley
- Posted on: September 24 2004 14:40 EDT
- in response to The Industry Observer
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. -
Possible reasons[ Go to top ]
- Posted by: Edgar Silva
- Posted on: September 27 2004 00:38 EDT
- in response to Mileta Cekovic
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 -
Possible reasons[ Go to top ]
- Posted by: Mark N
- Posted on: September 27 2004 08:21 EDT
- in response to Edgar Silva
I think AOP could be very useful too. -
I'm not so sure[ Go to top ]
- Posted by: Fred Bloggs
- Posted on: September 27 2004 08:08 EDT
- in response to Mileta Cekovic
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’s around now – 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. -
Regard the overall picture, not only the cutting-edge web-apps[ Go to top ]
- Posted by: Jo Siffert
- Posted on: September 29 2004 08:30 EDT
- in response to Mileta Cekovic
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 -
Ask TheServerSide: Is serverside more organized than clientside?[ Go to top ]
- Posted by: Brian Miller
- Posted on: September 24 2004 12:17 EDT
- in response to Scott Delap
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. -
Points[ Go to top ]
- Posted by: Leif Ashley
- Posted on: September 24 2004 13:58 EDT
- in response to Brian Miller
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... :) -
clientside is too fidgety[ Go to top ]
- Posted by: Craig Pfeifer
- Posted on: September 24 2004 12:43 EDT
- in response to Scott Delap
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? -
clientside is too fidgety[ Go to top ]
- Posted by: Fernando Petrola
- Posted on: September 24 2004 17:40 EDT
- in response to Craig Pfeifer
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 -
Is serverside more organized than clientside?[ Go to top ]
- Posted by: A P
- Posted on: September 24 2004 12:48 EDT
- in response to Scott Delap
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. -
There are many reasons ...[ Go to top ]
- Posted by: Joubin Houshyar
- Posted on: September 24 2004 13:31 EDT
- in response to Scott Delap
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**. -
There are many reasons ...[ Go to top ]
- Posted by: Scott Anderson
- Posted on: September 25 2004 16:01 EDT
- in response to Joubin Houshyar
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. -
Various reasons...[ Go to top ]
- Posted by: Leif Ashley
- Posted on: September 24 2004 13:49 EDT
- in response to Scott Delap
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’t pop back up if you don’t put the processing logic in a thread of its own.
So all these items have contributed to developers using SWING “only when required”. 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… well, more like a buck fifty. :) -
Microsoft More Expensive?[ Go to top ]
- Posted by: Ernesto Marquina
- Posted on: September 24 2004 14:20 EDT
- in response to Leif Ashley
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. -
Microsoft More Expensive?[ Go to top ]
- Posted by: Udayan Patel
- Posted on: September 24 2004 14:40 EDT
- in response to Ernesto Marquina
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. -
Various reasons...[ Go to top ]
- Posted by: Mark N
- Posted on: September 24 2004 16:18 EDT
- in response to Leif Ashley
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. -
Various reasons...[ Go to top ]
- Posted by: Jens Wyke
- Posted on: September 24 2004 17:15 EDT
- in response to Leif Ashley
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? -
Various reasons...[ Go to top ]
- Posted by: Jacob Hookom
- Posted on: September 25 2004 00:03 EDT
- in response to Jens Wyke
Check out JavaServerFaces, it's near an exact replica of ASP.NETFirst, 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? -
Swing sucks[ Go to top ]
- Posted by: Yo Man
- Posted on: September 24 2004 14:44 EDT
- in response to Scott Delap
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). -
Swing doesn't suck[ Go to top ]
- Posted by: nikita tovsoles
- Posted on: September 24 2004 15:00 EDT
- in response to Yo Man
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.
-
Swing rules (re: Swing sucks)[ Go to top ]
- Posted by: Kevin Duffey
- Posted on: September 26 2004 01:30 EDT
- in response to nikita tovsoles
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. -
Swing rules (re: Swing sucks)[ Go to top ]
- Posted by: Mark N
- Posted on: September 27 2004 08:10 EDT
- in response to Kevin Duffey
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) -
Swing Sucks(Reply to every one)[ Go to top ]
- Posted by: Yo Man
- Posted on: September 27 2004 16:58 EDT
- in response to Kevin Duffey
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. -
Swing Sucks(Reply to every one)[ Go to top ]
- Posted by: Martin Bromley
- Posted on: September 27 2004 18:17 EDT
- in response to Yo Man
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. -
Swing Sucks(Reply to every one)[ Go to top ]
- Posted by: Mark N
- Posted on: September 27 2004 21:20 EDT
- in response to Yo Man
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) -
Swing Sucks(Reply to every one)[ Go to top ]
- Posted by: peter lin
- Posted on: September 27 2004 21:53 EDT
- in response to Mark N
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. -
Swing Sucks(Reply to every one)[ Go to top ]
- Posted by: Mark N
- Posted on: September 28 2004 08:36 EDT
- in response to peter lin
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. -
Swing Sucks(Reply to every one)[ Go to top ]
- Posted by: Mark N
- Posted on: September 28 2004 09:00 EDT
- in response to Mark N
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.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. -
bad programmers and such[ Go to top ]
- Posted by: peter lin
- Posted on: September 28 2004 09:49 EDT
- in response to Mark N
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. -
Swing sucks[ Go to top ]
- Posted by: Giedrius Trumpickas
- Posted on: September 26 2004 13:04 EDT
- in response to Yo Man
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 -
Swing sucks[ Go to top ]
- Posted by: Vania Cilli
- Posted on: September 27 2004 08:23 EDT
- in response to Giedrius Trumpickas
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). -
Swing sucks[ Go to top ]
- Posted by: Mark N
- Posted on: September 27 2004 09:14 EDT
- in response to Vania Cilli
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. -
Swing sucks[ Go to top ]
- Posted by: Brian Miller
- Posted on: September 27 2004 14:24 EDT
- in response to Mark N
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. -
Swing sucks[ Go to top ]
- Posted by: peter lin
- Posted on: September 26 2004 20:33 EDT
- in response to Yo Man
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 no sucks[ Go to top ]
- Posted by: Mark N
- Posted on: September 27 2004 08:20 EDT
- in response to peter lin
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. :) -
Swing will suck forever, unless[ Go to top ]
- Posted by: Vahur Sinij?rv
- Posted on: September 27 2004 11:18 EDT
- in response to Yo Man
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. -
Swing will suck forever, unless[ Go to top ]
- Posted by: Mark N
- Posted on: September 27 2004 12:22 EDT
- in response to Vahur Sinij?rv
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. -
Datawarehouse? Gulp![ Go to top ]
- Posted by: tom tarb
- Posted on: September 24 2004 18:52 EDT
- in response to Scott Delap
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"?? -
Datawarehouse? Gulp![ Go to top ]
- Posted by: Adnaan Sikandar
- Posted on: September 27 2004 01:25 EDT
- in response to tom tarb
I am suprised that none of the previous posters commented on it. Datawarehousing and Java are simply not related as all. -
Is serverside more organized than clientside?[ Go to top ]
- Posted by: Dominic Cioccarelli
- Posted on: September 24 2004 22:53 EDT
- in response to Scott Delap
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?
-
lack of penetration, lack of standards[ Go to top ]
- Posted by: Hugh Madden
- Posted on: September 25 2004 03:07 EDT
- in response to Dominic Cioccarelli
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. -
lack of penetration, lack of standards[ Go to top ]
- Posted by: Mark N
- Posted on: September 27 2004 08:00 EDT
- in response to Hugh Madden
<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. -
Swing GUI builders[ Go to top ]
- Posted by: Martin Bromley
- Posted on: September 27 2004 10:05 EDT
- in response to Mark N
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. -
Swing GUI builders[ Go to top ]
- Posted by: Mark N
- Posted on: September 27 2004 10:21 EDT
- in response to Martin Bromley
See?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.
I sometimes them as a starting point. Then refactor and go on with or with out it. -
Server side development is just easier than client stuff ;-)[ Go to top ]
- Posted by: J??rgen Zeller
- Posted on: September 27 2004 02:44 EDT
- in response to Scott Delap
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 -
Singing the praises of Java on the desktop[ Go to top ]
- Posted by: Martin Bromley
- Posted on: September 27 2004 06:30 EDT
- in response to Scott Delap
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 -
GUI development is not for wimps.[ Go to top ]
- Posted by: Aris Bartee
- Posted on: September 27 2004 08:29 EDT
- in response to Scott Delap
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. -
GUI development is not for wimps.[ Go to top ]
- Posted by: Vania Cilli
- Posted on: September 27 2004 08:55 EDT
- in response to Aris Bartee
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. -
GUI development is not for wimps.[ Go to top ]
- Posted by: Mark N
- Posted on: September 27 2004 09:17 EDT
- in response to Vania Cilli
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 is a piece of cake. However.[ Go to top ]
- Posted by: Kevin Citron
- Posted on: September 27 2004 12:05 EDT
- in response to Mark N
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. -
Re: GUI development is not for wimps.[ Go to top ]
- Posted by: Amin Mansuri
- Posted on: September 27 2004 22:54 EDT
- in response to Vania Cilli
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.. ::( -
Re: GUI development is not for wimps.[ Go to top ]
- Posted by: Mark N
- Posted on: September 28 2004 08:38 EDT
- in response to Amin Mansuri
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. -
GUI development is not for wimps.[ Go to top ]
- Posted by: Brian Miller
- Posted on: September 27 2004 14:09 EDT
- in response to Aris Bartee
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? -
GUI development is not for wimps.[ Go to top ]
- Posted by: Mark N
- Posted on: September 27 2004 14:37 EDT
- in response to Brian Miller
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. :) -
GUI development is not for wimps.[ Go to top ]
- Posted by: Burak Bayramli
- Posted on: September 28 2004 04:46 EDT
- in response to Mark N
Easier? No. :) They are hard, but in a way programmers like it! :) This probably doesn't make much sense.. Let me try agan.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. :)
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. -
GUI development is not for wimps.[ Go to top ]
- Posted by: Mark N
- Posted on: September 28 2004 08:50 EDT
- in response to Burak Bayramli
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. -
GUI development is not for wimps.[ Go to top ]
- Posted by: Aris Bartee
- Posted on: September 28 2004 11:23 EDT
- in response to Brian Miller
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.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?
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/ -
GUI Debate[ Go to top ]
- Posted by: Jen B
- Posted on: September 28 2004 13:26 EDT
- in response to Aris Bartee
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 -
GUI Debate[ Go to top ]
- Posted by: Brian Miller
- Posted on: September 28 2004 13:48 EDT
- in response to Jen B
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? -
Neither is easier[ Go to top ]
- Posted by: Jen B
- Posted on: September 28 2004 14:13 EDT
- in response to Brian Miller
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 -
GUI Debate[ Go to top ]
- Posted by: J??rgen Zeller
- Posted on: October 10 2004 05:26 EDT
- in response to Brian Miller
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.There's also a lot of subjectivity on the client side, server side is "cleaner" to work with.
Doesn't this imply that server development is easier than client development?
Clearer about what is right, what is wrong. -
GUI development is not for wimps.[ Go to top ]
- Posted by: Brian Miller
- Posted on: September 28 2004 13:44 EDT
- in response to Aris Bartee
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? -
Too many brances[ Go to top ]
- Posted by: Burak Bayramli
- Posted on: September 27 2004 09:43 EDT
- in response to Scott Delap
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. -
Too many brances[ Go to top ]
- Posted by: Fred Bloggs
- Posted on: September 27 2004 09:57 EDT
- in response to Burak Bayramli
Interesting. There’s a very good (and rather amusing) book on UI design you might enjoy – "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’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 -
Too many brances[ Go to top ]
- Posted by: Mark N
- Posted on: September 27 2004 10:01 EDT
- in response to Burak Bayramli
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. -
Too many brances[ Go to top ]
- Posted by: Brian Miller
- Posted on: September 27 2004 14:28 EDT
- in response to Burak Bayramli
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? -
Ask TheServerSide: Is serverside more organized than clientside?[ Go to top ]
- Posted by: Mark N
- Posted on: September 27 2004 10:18 EDT
- in response to Scott Delap
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? -
Sun gave up on desktop[ Go to top ]
- Posted by: Vic Cekvenich
- Posted on: September 29 2004 15:57 EDT
- in response to Scott Delap
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 is not for desktop apps[ Go to top ]
- Posted by: V K
- Posted on: September 29 2004 17:29 EDT
- in response to Scott Delap
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. -
Java Desktop Anyone?[ Go to top ]
- Posted by: Aejaz Sheriff
- Posted on: October 20 2004 03:34 EDT
- in response to Scott Delap
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 -
New horizon always on the horizon[ Go to top ]
- Posted by: Gokhan Toplar
- Posted on: November 15 2006 10:41 EST
- in response to Scott Delap
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 :)