Geertjan is a DZone Zone Leader and has posted 453 posts at DZone. You can read more from them at their website. View Full User Profile

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

02.18.2010
| 20604 views |
  • submit to reddit
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.

Published at DZone with permission of its author, Geertjan Wielenga.

Comments

Lieven Doclo replied on Thu, 2010/02/18 - 3:23am

Geertjan, as always, you hit the nail right on the head. Thanks for giving me some extra ammunition next time someone goes for the "it has to be a web application no matter what"-excuse. Nice read.

Jose Maria Arranz replied on Thu, 2010/02/18 - 4:11am

When we think about "desktop" and "web" we are thinking in GUI technologies and it is wrong, HTML, JavaScript and Java CAN be the technologies being used in desktop.

I think web and desktop are converging because web paradigm is evolving more and more towards Single Page Interface, the typical paradigm in desktop, and I'm sure that with some work we can build applications working online in web (client/server) and offline in desktop, both based on web technologies and Java, reusing 99% of code and avoiding application servers (servlet containers) and server ports (desktop version).

We have pure Java embeddedable databases and desktop browsers can be embedded in our desktop applications.  We just need to port our pure web frameworks, intensive on AJAX, to run in this kind of desktop-web based environment. In spite of we can embed desktop browsers I must recognize we need a good pure Java browser, Lobo/Cobra is in this path but I'm not sure if this project is supported enough (too much work), I think they need some funding and more community support.

Of course this kind of hybrid application may be not valid for some use cases seen before in Geertjan's article where pure Swing or NetBeans platform are definitively the best options.

I've written about this in javaHispano.org in Spanish (rough translation), if someone is interested I can submit this article to JavaLobby.

 

Jan Kotek replied on Thu, 2010/02/18 - 9:11am

Ironically I found server resources very limited. 1 GB RAM & 20 GB of disk space per user? On server nearly impossible, on desktop trivial.

JeffS replied on Thu, 2010/02/18 - 12:43pm

I think regular desktop apps will always have a place.  In many cases, equivelant web apps are pretty good, but often fall short. 

 Stuff like Swing and the NetBeans Platform are always nice to have, for the their rich interactive UI, and for their local processing, data storage, and access to local resources (file system).  

Bernd Ruehlicke replied on Thu, 2010/02/18 - 1:19pm

Related articel on theregsiter today (in particular last section on second page)

http://www.theregister.co.uk/2010/02/18/javafx_under_oracle/

 

christiaan_se replied on Fri, 2010/02/19 - 3:55am

Nice article. We had similar motives when we decided that our application should be a desktop application.

I think another important aspect (next to extensive user interaction and performance) is that a web application involves much more software components and different languages to achieve the same goal. Increase in components leads to increased complexity, which means higher development budget and higher quality risk. For me this means you need a good reasons to move to a webbased application (unlike many managers think).

Also, what exact advantages does a webbased application bring and can't these be "added" to a desktop application using other technologies. For our application this meant we used remote desktop technologies. This enables us to have our application deployed through the web while users experience it as their local desktop application (really!) with good performance. Of course, if you need to serve anyone on any computer this is no solution, but for commercial applications used in specific business with a user base between 1 - 1000 this is very nice solution. Another advantage is that you have completely seperated the functionality from it's deployment model so you don't have to think about webbased security when developing the application.

Milos Silhanek replied on Fri, 2010/02/19 - 2:52pm

 We have to choose technologies we will use for our application. Some of requirements: Users work in intranet, GUI is so complex and interactive, fast data typing on the keyboard only, GUI settings and reactions depends on entered data, caching of code lists on workstation in memory or localy, several opened panels of different modules, tasks on background, dynamic menu according to permissions etc. (I can't remember now). 

Some reports, statistical queries and outdoor (internet) use cases can be made as a web application. Rich client app can work with web pages too.  

I choose NetBeans Platform rich client application - modular, simple distribution, offers all I need. So admit need of java and application installation.
Milos

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.