Over a million developers have joined DZone.

"Why is your desktop app not a web app?"

DZone 's Guide to

"Why is your desktop app not a web app?"

· Java Zone ·
Free Resource
While it may seem that everyone and everything is running on the web and mobile phone, what's the place for desktop applications? Is there one? How big is it? My hypothesis has been that the place of the desktop is simply becoming more clearly defined, rather than becoming less important. I then asked a number of technical leads of large desktop projects why they weren't creating web applications instead of desktop applications. Their answers can be read below.

Jean-Claude Dauphin, UNESCO, creating J-ISIS, a bibliographic storage/retrieval system:

It's mainly related to UNESCO's initiative to help reinforce the capacities of developing countries. One of the requirements was that J-ISIS should be usable by small libraries and document centers in developing countries that don't have Internet access, or the necessary IT infrastructure and knowledge for installing a Web server. They need an easy to install application that provides a rich user interface. J-ISIS uses the client/server pattern and is a desktop application that acts as a database server as well as a rich client application. J-ISIS is a rich client application written to communicate with a specifically designed database server that is accessible as a stand-alone application and over some local network. It can be used on a single host machine, over a small local network, without Internet access or a Web server installed. Desktop applications written in Java on top of the NetBeans Platform make it possible to easily create rich user interfaces for client server applications.

In fact, we want the J-ISIS application to be usable as a rich desktop application as well as a Web application. Today, a number of technologies are vying to add interactivity to Web applications, technologies such as Ajax are becoming more mature and JavaScript libraries such as jQuery, YUI, GWT, Dojo, etc. provide GUI widgets that would allow to develop better interactivity for Web applications. Around the J-ISIS desktop application that includes a database server, we are now developing a Web application that uses the Struts 2 framework, Sitemesh, Ajax and jQuery. The first prototype is quite promising and we want to go further in this direction. So, please note that for our specific purpose, the J-ISIS desktop application and Web application are complementary.

Tonny Kohar, Kiyut, creating graphic applications, such as vector drawing programs and photo filters:

Some applications require heavy interactive UI which, at the current stage, web applications are not cut out for. So, sooner or later, we will start to see hybrid applications, which combine the best of desktop (highly interactive UI) with the best of web applications (data storage/consolidation, web service).

Dale Thoma, Saab Systems Grintek, creating applications for the South African National Defence Force:

Our target deployment is defence platforms such as frigates, submarines, infantry vehicles and command centers. We operate in a limited tactical bandwidth environment, therefore we are unable to make use of static infrastructure such as cable, ADSL or GSM.

Our software is built with specific messaging capabilities where every bit counts. Desktop application development for us still has the edge for high-end complex systems due to its flexible nature and the maturity of application frameworks like the NetBeans Platform.

Tim Dudgeon, InformaticsMatters, creating Instant JChem, a chemical structure manager:

  1. Rich functionality. Generating rich user interfaces is a great deal easier with client side programming (e.g., Swing) than in a web browser. Even though web tools have improved greatly over recent years (DHTML, AJAX etc), they are still less functional, and take much more programming to achieve. The gap is definitely narrowing. When we started Instant JChem (IJC) 4 -5 years ago, the choice was obvious. If we were in the same postion today, the choice would be harder, but I still believe there is a significant difference.

  2. Client side data. A large part of our functionality deals with data that is local to the client. Typically these are large files containing data that have to be analysed. The functionality is needed on the client, so it makes much more sense for the data to also be located on the client. Server based solutions that exist for this type of thing tend to be quite ugly (file upload button to send data to server...). Also, volumes of data can be large, and it is much more efficient to be close to the data than to need a round trip to the server each time you need something.

  3. Zero install. Web applications are often favoured as being "zero install on the client". But they are of course not "zero install on the server". Security concerns often preclude our customers wanting to put data on public servers, as they require the data to stay within the firewall. A NetBeans Platform application gives you a simple way to achieve all the functionality you want. If each customer had to set up a server-based environment, we would lose a lot of our customer base. Our users are real users, not IT administrators, and they are often from small companies without significant IT expertise - often when we say "put this on your company web server" they say, "we don't have one", or "I don't have access to one".

That's not to say that I don't think many types of applications are best done as web-based and we are active in that area too. It's just that one shape does not fit all.

But I also see this web vs. thick client as bit of an artificial distinction. For instance, we run a JNLP based version that could be described as "purely browser based" and it makes use of services served up from web server. But not all customers are able/willing to set up this more complex environment and many prefer to stick with the tried and trusted installer.

Charlie Black, Northrop Grumman, creating Agile Client, a 3-D common operational picture workstation:

There is no such thing as one size fits all. In our product lines, we support three different platforms: desktop, browser and PDA. Each platform has its own reason for being.:

  • Desktop is normally the "power" user that needs to run in a disconnected mode of operation and needs access to all the commands.¬†

  • The browser is for casual looker that just wants to see what is happening and participates with basic commands.

  • The PDA is for the mobile user that runs on limited or no network capabilities.

If we compare this to a real world example we have Microsoft Outlook for the desktop, Microsoft Web Mail for the browser, and a Blackberry.

Though it is possible to make a web application behave as desktop application, it is not always cost effective. In relation to our desktop platform, to make our web application run in a disconnected mode of operations, we would need to deploy an application server and database locally. Even if we "discount" the application server and database to free, we still have the costs of hardware and administration to run and maintain that end-user's computer.

Jordan Ganoff, AirIT, creating internal airport operations software:

Desktop apps and web apps serve two different requirements. Rich desktop applications have the benefit of being able to process mass amounts of data locally, providing a naturally distributed platform. Some of our applications require local hardware access and thus are not suited for the web.

Urs Bill, Sohard AG, creating train monitoring information applications, among others:

We have several applications which basically monitor various software and hardware components and visualize their healthiness on a UI. Such UIs update themselves automatically and with as little delay as possible, something which is quite cumbersome to achieve, even using technologies like AJAX.

Another application processes large medical image sets and needs quite some CPU power. It just makes no sense to transfer the image data over the network to process it centrally on an image processing server. It would be a waste of computational power not to use the local CPU for the image processing. Security and confidentiality would be a much bigger issue if the medical data has to be transferred over the network.

Generally, if you have a file on your disk and you want to open that file, change it in some way, and store it again on your disk, it just does not make sense to upload the file to a web app, modify it in a browser based app (and by doing so transferring the content again and again from the server back to the browser) and finally download and save it again on your disk. Although perfectly possible, you wouldn't want to upload your payroll accounting file to some remote server just to work on it using some web based spreadsheet app, or would you?

Bernd Ruehlicke, Eriksfiord, creating oil & gas exploration software:

Whereas in the housing market the key concern is "location, location location", the key concern for applications in the oil & gas business is "performance, performance, performance"... and fast access to big and many files.

A short list of reasons:

  • The Java JVM provides the general system independence I need.
  • Java Swing provides the the flexibility I need for my GUI.
  • The NetBeans Platform provides the plumbing and flexible window system I need.
  • Easy access to you local filesystem for possible massive file size/count access.
  • Need to be in control of unified branded user interface.
  • Need to run your app when being off-line.
  • A 2-tier db connection is always better than a 3-tier or even worse 4- or 5-tier.

... try to handle a 2 gig image log or 15 gig seismic section in a web application -- fast... Good luck.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}