This post originated from an RSS feed registered with Java Buzz
by Scott Delap.
Original Post: Client vs. Server Framework Summary
Feed Title: ClientJava.com
Feed URL: http://www.clientjava.com/archives/wireless_mobile.rdf
Feed Description: Client/Desktop Related Java Development
I've spent the morning researching for a conference call I'm on today. As part of that process I've aggregated the comments on the Client vs. Server framework debate I started a few weeks back. I've tried to take none of the posts out of context and have linked back to their original sources. I also do not mean to post my responses here as a method of getting the last work. There were many interesting viewpoints presented. I thank everyone that participated.
---Summary:---
TSS - Mileta Cekovic Crashes are no big deal on the client.
The server side is more hyped in this internet age.
Response:
There is a touch of truth to crashes aren't a big deal. I remember using a copy of VAJ that went down at least once every two hours. If a server is down, beepers go off and all hell breaks loose. Normally, a client application crashing pisses people off and loses the last hour of work.
The server is greatly more hyped in the internet age.
TSS - A P 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.
Response:
Outside of promoting the language does desktop Java add to the bottom line?
TSS - Leif Ashley 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.
Response:
Swing does need enhancements but does it need builders and wizards? I've never used an IDE wizard to create EJB's. I would be most of my fellow developers also fall into this category
TSS - 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. 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.
Response:
At the end of the day ROI is going to be a major deciding factor. VB has at least a perceived edge in terms of developement ease and time. However, part of the question is what are you comparing. UI's are everything from reports, to data entry, to fuller Microsoft Office type applications. I'm not going be foolish and say using SWT or Struts for everything. I will agree that your technology should fit your need.
TSS - Hugh Madden 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.
Resonse:
I looked through all the JSR's last week and the number concerning desktop application development is very low. Is this an anomaly or tied to interest level?
TSS - J
1e00
ürgen Zeller On the server side, your design is about 90% right when you consider
- use cases are stateless, or most of the state is provided by the client/database
- a clear seperation between use case code and data access code
- a clean data acess code, either with ORM or DAO
- not to much mixture between technical and business code
- propper optimistic/pessimistic locking, esp. for long running transactions ("business transactions")
- adiquate batch processing
- 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.
Response:
I don't know if there is a 90% list on either side. It would be nice. However, the frameworks available make getting to that 90% level easier with server development. Office apps are the usability standard considering most offices live and die by them. However, being a standard doesn't necessarily make you correct. A usable application is a usable application. There will odds are always be questions like "Word doesn't act like that". However, I'm guessing this will be forgot if the application performs well over time.
TSS - Mark Nuttall 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.
TSS - Brian Miller 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.
Response:
There is a double standard I will agree. The web does not have this problem because there is "no standard". Swing is stuck having to be all things to all people. SWT has to be one thing to many people. Similar yet different problems.
JL - Chris Rijk Part of the problem is simply displacing other products / developers. On the server side, the market was pretty new, so was much easier to get into and make money. It's also inherantly much easier to develop server apps that work nicely on all systems than client.
JL - Daniel Michalik 1. Market. What kind of client application You would like to see written in Java? Office suites? CAD? HMI? Multimedia Apps? System tools? For all this problem domains exist zilions of good applications and no reasonable investor will put his money to create new product from scratch just because Java is cool.
2. Demand. There is no demand for applications written in particular language. Where are Python or Ruby desktop applications? Nobody cares.
3. Fear, Uncertainty, Doubtness. If everybody says "Java on client is dead", what we can expect?
4. Lack of application design skills. There are well proved design patterns for server applications, many books, articles, great tools. No Desktop design guidelines. Complex desktop application is difficult to design.
5. Absence of higher level application libraries on top of Swing.
On the other hand there are still good news. Java prooved as good client side platform for specific problem domains:
- popular Java IDEs are complex desktop applications,
- enterprise applications,
- specialized applications (NASA, healthcare, ...)
- games - may be Sun efforts bring some fruits?
Although Java is general purpose language we have to admit, that it cannot be everything for everybody. Especially on desktop.
Response:
As I mentioned earlier I don't think Java is 100% right on the client all of the time. However, here we also tap into the issue of perception. Swing and Java in general still has years of bad PR on the client to fight through. There are two battle lines. First there are developers. Then there is management. Developers have to be convinced the speed and ease of development issues are being address. Management needs to be sure of ROI and deployment issues.
--Closing:--
In the end my debate over client vs. server frameworks did not really stay on 100% focus. However, commentary on other subtleties was generated. I would at least feel comfortable saying the following. As expected, frameworks follow developer interest and money. As a result rich clients are still catching up in this area.
Previous Topic
