Web Applications vs. Desktop Applications

Case Study: Web App Generates More Revenue than Desktop App

I read an interesting post the other day about desktop applications vs. web applications: Desktop Apps Vs. Web Apps

Note – this is a very old article (written in 2009, I believe), but the point is still there.

This article talks about sales.  In particular, a website app generated a lot more revenue in terms of percentage of people making a purchase and reduced advertising costs.


The web certainly has changed the way many deliver software.

Consider Microsoft spending a lot of its time delivering services in the cloud (Office 365 and Microsoft Azure).  Google and Facebook, two massive software companies, both deploy most if not all of their software through web servers.  Big software companies deliver many things in the cloud.

What aspects of automation can be found in deploying software through the web?

Easier to Install

This reminds me of why I use Jenkins as a front-end to running scripts.  When others don’t have to install any new software (that even includes something as trivial as downloading a Docker image, for instance), it removes one more obstacle to using my tool.

Rather than having to install or download some form of software, the user can navigate to a webpage.  I can’t imagine hardly any user’s computers these days not having a browser.  Which means that user will not have to install something new to use your tool.  It’s already on their device through using the browser.


Better still, multiple people can potentially use that tool at the same time depending on how it is designed.

Easier installation means many things depending on the application.  For some, it means other people within your organization may use your tool more.  For others, it may mean you earn more revenue as it’s one less reason end users have to not purchase your product.

Better Feedback

Another interesting use of web applications is seeing how users interact with your software.

What functions do they use most often?  More often than not, you’ll probably see 80 or 90% of use cases falling within 10 or 20% of the functionality of your program.


If you manually asked each user what features they use most often, more than likely they will not know.  They may even give wrong answers (not intentionally… just from lack of knowledge).

With a web interface, you can track which buttons are clicked and what parts of the software gets used most frequently.  (…as long as this information is in the privacy agreement.  Remember all those messages you get from browsers sometimes to “Send feedback to make this product better”?)

This feedback is invaluable to make your product better.  You can focus on the parts that are used most and perhaps drop other things that aren’t used at all.

You can even do some advanced things such as give different interfaces based on the user.

User X has done lots of advanced features, so let’s give them more options to configure this tool.

User Y hasn’t done very many things, so give them a more basic interface so he won’t get confused.

This type of feedback and response to that feedback is almost impossible with a desktop application.

Quicker Deployment

Deploying software is much, much quicker with a web application than a desktop application.Quick

You simply have to update the servers hosting the website in order to update the code.

Contrast that to trying to contact hundreds, thousands, or more users to tell them a new version is available.  They then have to go through the install process again (or an update process… and some of you may see how aggravating it is to get automatic updates without your permission – cough cough – Windows 10 – cough cough).

You can even make this completely automatic.

Suppose you have a really good suite of unit tests, component level tests, and system tests that are all automated.  If all those tests pass, you are pretty confident the software will work to specifications.

If that’s the case, a build server could run all these tests each time a change is committed.  Once all the tests have passed, the build server could deploy that new code to each server.

Automatic deployments!  How awesome is that?

Again, you definitely cannot get that with a desktop application.

Potentially Great Reusability through Well-Defined APIs

I’m a really big fan of REST APIs.  Don’t get me wrong – they can be done very, very badly.  However, they give any web application a semi-defined way of providing an API to their software through GET, PUT, POST, DELETE, and potentially other HTTP requests.


It’s true that each web interface will have many different functions for their REST API.  However, I can use many different tools to control it, such as Python, CURL, and many other languages.

Contrast this to a desktop application.  You may have an API into it, or you may not.  The way to get access to it is probably going to different quite a bit from application to application.  And you may not be able to use very many programming languages to use that API.  Who knows.

This gives web applications a great way to be reused by several other applications.

A great example of this is with the test software we use where I currently work.  We use a Jenkins build server to kick off tests through REST API.  This allows us to see the status of testing hardware each morning we come in rather than having to manually kick it off (and wait for 10-30 minutes) after we get in.  At the conclusion of the test, an email is sent out to everybody.

When we originally designed that test software, we did not anticipate that use case.  However, since it has a well-defined REST API based, we were easily able to reuse the software with another application.


Web applications play a big part in today’s software development, and for good reason.  It’s easier to install, deploy, get feedback, and reuse… just for starters!

If you are debating whether to develop a desktop application or web application for your next tool and have options to choose either, consider these benefits of web development.  You may make your software flexible enough to install, deploy, and reuse in more ways than you ever would have dreamed during initial development.

One comment:

Leave a Reply

Your email address will not be published. Required fields are marked *