This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.

×

This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.

×

Why Web Apps are Faster to Develop than Desktop Apps

This is a really simple observation, but with profound implications. I don't know why I didn't recognise it before. (Maybe I did, but now it's clear enough to write about.)

Introduction

There are organisations that still think a Desktop App is better than a Web App for providing internal line of business applications. In some cases there could be a technical rationale, for example integration with special hardware, but for most business applications, either could be made to work. The question is, which is more efficient to build, test, deploy, support and maintain? I believe all 5 of these stages in the application's lifecycle are more efficient for a web app compared to a desktop app.

Here are my definitions: Desktop App A compiled application that provides a UI which runs natively on the host operating system. No special device support or hardware integration is needed. Swing and WPF are typical examples.

Web App A browser based application that uses HTML, CSS and JavaScript. (Note: I'm excluding Flash, ActiveScript, Applets and GWT from this discussion, but I think these fall somewhere in between.)

A simple use case

Earlier today I was investigating a problem in a Desktop app. The user said: "This menu is disabled, but it should be enabled...". In a web app the investigation would go something like this: 1. Open the Web Developer tools in the user's browser, Ctrl-Shift I, and I'm ready to start debugging.

For a desktop app, it would go something like this: 1. Get hold of the source code for the version of the Desktop running on the users machine. 2. Lets assume it's simple to find the build number of the Desktop and I can checkout the source for that build. 3. But I'm sat with a user and they don't have access to the source code or any development tools. I'll go back to my machine, where I do have all the tools, and do the investigation there. 4. At my machine, I want to run the same version of the Desktop app that the user was running so I can re-create the problem. Let's assume it was straight forward to Run the same version. (The binaries were readily available, compiled with debug symbols and the source code was tagged with the build number so I can easily checkout the source.) 5. Let's assume I wasn't in the middle of some other work on a different branch. 6. Let's assume I can recreate the problem, hooray, now I'm ready to start debugging.

For the desktop app, each assumption could introduce delay, and even if none of them does, it's still more time consuming than pressing Ctrl+Shift I. In reality, each assumption will add some overhead, even if it's only a minute or two. This illustrates a key difference between web apps and desktop apps; the Web Developer tools are built into the browser allowing almost anyone to investigate issues directly.

This direct access to source at runtime made a big difference to the adoption of web apps right from the very being of web development. For example, in the early days of web app development there was huge amount of re-use. If you saw something cool on a web site that you wanted on your site it was easy to look at how it was implemented, and create something just like it. The equivalent is much harder (nearly impossible) to do in desktop apps.

This access to source at runtime in the browser cuts across all the phases of a project; build, test, deploy, support and maintain. Of course there are other differences between web apps and desktop apps that are more specific to each phase, and I'll cover those in subsequent posts.