Here at NuRelm, we build, integrate, celebrate, research, and, sometimes, gently caress web-based software. Every once in a while, we build a piece of “desktop” software, but it’s rare. But why? To answer that, let’s start by figuring out what those terms even mean, then looking at where each development model fits.
What is Desktop and Web-Based Software?
It’s common to use the term “desktop software” to refer to a self-contained system that can be independently deployed on a specific type of hardware. For example, when you download an installation tool that runs on your machine to install something like Microsoft Word, it’s considered desktop software.
In contrast, “web-based” software systems are delivered through a user’s web browser, while they actually run on remote hardware that is maintained by the tool’s owners. Examples of such tools include Google Docs (a web-based word processor) or Salesforce.com (a web-based customer relationship management tool).
What’s the Difference?
These are both valid choices for many types of software, but they are very different in a number of ways, some of which are contrasted below:
|Connectivity Requirements||Does not require an internet connection.||Requires an internet connection.|
|Protection of Algorithms||Impossible to protect proprietary algorithms from reverse engineering.||Usually impossible to reverse engineering (without hacking provider’s servers)|
|Scalability||Dependent on client hardware.||Scalability controlled by software provider’s hosting infrastructure.|
|Installation Skill / Maintenance||Requires customer installation and maintenance.||Requires no customer installation or maintenance.|
|Hardware Requirements||Written for specific target operating system / hardware platforms. Heavy computational load will require powerful customer hardware and dedicated compute time.||No customer hardware requirements beyond a modern web browser, since computations are performed on software provider’s hosting infrastructure.|
|Data Collection||Collection of user data could be performed, but requires an extra upload step.||Customer data is uploaded for processing anyway, and storage could be automatic.|
|Deployment||Must be installed and maintained on every workstation where it is used.||No installation is required beyond logging into an account.|
|User Data Model||Difficult to enforce a user data model where certain users have certain privileges, or where administrative users can easily view user usage patterns.||Easy and natural to enforce a user data model where certain users have certain privileges, or where administrative users can easily view user usage patterns.|
|Licensing||A variety of techniques exist for managing desktop software licenses, from license servers to maintaining a list of license keys that must be used at each workstation.||Licenses are simply stored as part of a user’s account, and require no maintenance on a customer’s part.|
|Cost||Desktop applications must be developed for every target platform. For example, developing for both PC and Mac platforms would involve nearly double the development costs of either platform alone.||Similar or less expensive than developing a desktop application for any one target platform.|
|Video Response||Desktop or “native” software provides the best case video response time, although some browser-based technologies provide reasonable performance.||Web-based applications typically cannot compete with desktop software for video-based work.|
When to Use Desktop vs Web-Based
Desktop applications shine for video-intensive work. Video games and graphic editing tools are usually prime candidates for desktop development, although there are many exceptions in both areas.
Another consideration might be to think about desktop development when a quick link between “backend” and “frontend” is required. But this might be an outdated distinction, since web-based tools such as QuickBooks Online and Salesforce.com have proven that accounting and customer relationship management tools are not only candidates for web-based apps, but that they can be at least as good as their desktop counterparts.
Desktop applications are also good choices when a user’s connectivity cannot be assured. Although web-based applications can synchronize with servers periodically to make up for brief connectivity outages, a data-intensive application will be frustrating, at best, when connectivity is spotty or nonexistent.
When to Use Web-Based vs Desktop
The vast majority of applications will lend themselves well to web-based development. When the situations described above do not apply, web-based development has a lot of advantages:
- Control. Try running a calculation-intensive application on random client machines and you will appreciate the beauty of control. Controlling where your application’s parts run gives you the ability to tailor each component’s hardware to it’s function. CPU-intensive components get cloud servers with lots of CPU, databases get high-IO servers optimized for the work, and so on. The only piece of your web-based application that has a chance of running on a vintage 10-yr old computer is the web browser that will deliver it.
- Security. There are a lot of aspects of security that web-based applications will help you optimize. One aspect is that of easily enforcing licensing and user restrictions, because web-based software allows you to centrally manage those things. Another is that of protecting your secret sauce, since it is impossible to reverse engineer any of your code that’s running remotely (without actually hacking the remote server).
- Flexibility. Web-based software multiplies your development options. From the language and operating system you develop on, to the services your code draws from, web-based development offers a vast range of options that desktop development, by its nature, cannot.
- Sharing. The internet has, shall we say, caught on. Much of it’s lure is based on sharing data in ways that individual computers cannot.
- Deployment. Finally, we come to the boring-seeming word “deployment” (yawn). Deployment covers getting your software and any updates to your clients, and web-based development makes this vastly easier. Imagine the example of a critical software update that you have to get to 10,000 installed users. Getting updates to these users in a desktop environment is tricky, to say the least, while doing so in a web-based tool is simply a matter of updating your central software environment.
We like web-based software a lot, and recommend it for most development situations. But don’t take our word for it, consider the elements above and any others that are important to you before your next development project, and figure out what makes the most sense. If you’re not building a fast-paced video game, my guess is that it’ll be web-based!