Web vs. Desktop Applications: The Neverending Debate

The author underestimates the value of APIs to provide cloud services, and over-estimate the value of client-server architecture for driving user interface.

If anything, the iPhone demonstrates the value of native software, safely run within a jail, delivered and billed immediately, connecting to broader network-based services to provide extensive functionality.

It's short-sighted to approach the future of web applications with such hubris. The web is currently a horrendous application platform, and there's clearly value in client-side state as well as rapid, safe deployment and 'cloud' state.

The future is very likely a merger of web, desktop, and api, but not necessarily using the JavaScript+HTML+CSS or Flash that web developers have come to expect. Perhaps we'll see application architectures like 280 North's Cappuccino take hold, or perhaps not.

Either way, I seriously doubt that today's web application architecture is the final evolution of the client-server model -- we've been engaged in this client/server evolutionary dance for nearly 50 years.

This is a stupid debate at this point.

For most applications the line has become darn near invisible at this point. Think about it. In the abstract, what really is the difference between a desktop app running off a database and an Adobe AIR app running off a web service? A seamless install process on the web. A couple of extra APIs on the desktop perhaps. But overall they’re exactly the same.

Moreover, the only reason for any difference at all is that the platform manufacturers haven’t caught up yet. There’s no reason, for example, that an AIR app couldn’t do everything a desktop app could (access hardware devices, run in the background, etc…). Adobe just hasn’t put it all in yet.

So at this point Desktop apps are just a specialized programming environment for those rare situations (utilities, games, hardware centric programs) where web apps don’t work. Otherwise there’s not much difference. So developers should do what they've always done, evaluate their requirements and pick the tool that is best for the job.

> First, it's not a challenging medium for me.

The guy should probably switch his intellectual efforts over to figuring out how to make his work useful rather than how to make it as complex as possible.

The web can never replace the power of desktop applications, and desktop applications can never beat the simplicity of web applications (with both in their current forms). We are currently blurring the lines between desktop and and web, but in the end it will probably resemble more of desktop applications. This is because current web applications run in the browser only because of the limitations of current web technologies. But if we could easily make web applications run like native desktop applications (with no installation necessary), we probably would.

Chrome is making that leap to blur the lines by being a web oriented OS. In the future we'll probably see more of using web technologies, and applications that run remotely coupled with easy (but more powerful) UI development on the client side that runs natively on the user's computer. So we'll have a mix between the best parts of desktop applications: control and power, and the best of web apps: easy UI development and interconnectedness.

I recently worked on a web based product that installed a server and a database on the users machine. All data was stored locally for privacy and locality of cpu resources, but could be backed up in the cloud and shared with whomever the user chose. Given this kind of setup the distinction between web and desktop applications completely disappears.

There are obvious scaling and security issues for this model in the general sense: do you want 200 servers and 200 databases on your local machine, but as a browser managed facility it makes sense to me.