Eyes Above The Waves

I think you're not giving a description but a definition.
What if desktop applications start supporting these features ?
Take Java WebStart.
It's desktop applications, but among the four features above, it only lacks "Browser chrome".

Yes, there's a sandbox. But unfortunately, there's only a single sandbox. As a platform, it's difficult to introduce user-level sandboxes - something that Caja, LiveLabs WebSandbox, AdSafe try (with variable success) to do.

Sounds more like "The Essence of Web Browsers", although I really only take issue with "URL Addressing" and "Browser Chrome"

Hey Robert, great article! I'll link to it soon.

David: Java Webstart doesn't have "open box", either. But if something you think of as a "desktop app" supported all these features, I'd say it's a Web app too!
RichB: Yes, that is a problem we'll need to solve.
Mark: To the extent that Prism takes users away from browser UI and hides URL addressing, I think it's fair to say Prism makes a Web app more like a desktop app. That's not necessarily bad but I do think you have to weigh the pros and cons.

Re: user-level sandbox. I've been arguing for something Caja-like at the browser level for some time now, using sandboxed DIVs with server-generated random boundaries and default cookie-blocking for *any* third parties. (I'd try to find the discussion, but for some reason bugzilla is completely opaque to Google.)
"This enables tools like Greasemonkey to reach into and manipulate Web content. It enables browser features like text zoom and "find in page". It enables search engines. It allows for user style sheets and other kinds of end-user customization of the Web experience. It also creates an environment of pseudo-open-source-software, where authors can learn how other apps work, even if they can't modify or reuse that code directly."
All reasons why I'm against the information hiding and locks of any kind of secure ecmascript language. We need to secure dangerous environments, not programming languages.

Thanks for reminding me how and why I love Web applications. I wish all my desktop apps were browser-based! Every time I can't zoom text, or Ctrl-F to search, or bring up the status menu on a link, or bookmark a particular app state, I CURSE desktop applications!
In using my PC, phone, and OLPC laptop, I realize how close Firefox is to being the entire netbook/net-top/blahblah application and UI. Nearly everything you work with comes from the web, sometimes you cache or save it locally. Rarely, you create documents from scratch locally. With a little more work, Places plus download manager could be your window into local files as well, complete with tagging, folders, etc. The rest of the "desktop" can and will become increasingly irrelevant and irritating.

Rob, that's what I meant. I don't see any reason why webapps and desktop apps would not converge.
Webapps are adopting desktop features.
Desktop apps are adopting webapps features (these 4) too.
They are converging.
So, given your definition (and I like it), it's not webapps vs desktop apps. It's more webapps vs not webapps.
(e.g activex is not webapp : no sandbox, not open. Flash is not webapps : not open, no browser chrome. Java is -nearly- webapps)
(On the open-box point, the jvm is an open spec, and nothing prevents you from decompiling java bytecodes. It's not as easy as html/javascript, but we can imagine a jvm that supports automatic decompilation/text zooming/find/... The technology permits it. It's just that the product is not there yet, afaik)

Well it's a faith in technology potential, i say potential as reading Restfull webservice, i can see that still today simple standart as http PUT GET POST DELETE etc.. are not fully supported.
I love the concepts but the technology is still maturing and also this technological potential is not yet thought as user benefit.
example: how URL based makes accounting any better for an accountant ?
exiting things to develop, but still a long way to go

David, something like the JVM is never going to be open box. It's not enough to be able to read bytecodes, you need to be able to do something useful with the structure of the app. In particular, the use of markup in Web apps (even dynamically generated markup) means that there's text and graphics that can be searched, manipulated, etc. The closest you can get with Java is probably something like Swing's widget tree ... but a Greasemonkey-like script couldn't change that without breaking the app.
The Web was designed from the ground up to support user control over rendering and formatting, and that's why it's "open box" friendly. Of course people can and do write "Web apps" that bypass all that and just draw a bunch of pixels, but it's not common. (I'd say those aren't full Web apps.)

You raise an interesting question, one which I've seen posed in a number of fora over the last few years. The distinction is becoming very blurry, though there are a few elements that the desktop application developers bring up as to the differentiating factors:
1. A browser is, in many respects, a virtual machine, something that acts as an abstraction layer between the user and the underlying low level graphical, media, and system routines. The level to which this virtual machine provides access to system-level functions defines, to a great degree, how close the web browser can come to emulating desktop functionality.
2. One aspect of this is the degree to which the browserOS can "stream" the state of underlying functionality. I can, for instance, write an XPI that will poll the active services on a computer system and render that as an XML stream for additional higher level processing, and can similarly create an API that will make those services configurable in a similar manner to processes within a web page. Realistically most people don't do this without making sure that there is a fairly stringent sandbox in place, but this is not so much a technical issue as it is a social one.
3. Performance in the past has been a traditional differentiator, but with the recent advent in JavaScript trace tree compilation, I suspect this will be an ever weaker argument. If my JavaScript is running at or near C++ speeds then the principle speed issues have to do with the speed at which marshalled DOM objects can be accessed or updated. My suspicion here is that once this barrier falls, the distinctions will become meaningless.
4. Regarding Chrome - take something like Prism. I should be able soon to create stand-alone applications that utilize the web plane in order to generate GUI. The chrome involved is minimal, essentially just enough to give it an application context, but there is no question that the applications involved are still, for want of a better term "wep apps".
On the flip side, I've spent a lot of time recently evaluating JavaScript AJAX libraries, and many of them are reaching the level of very sophisticated component libraries enabling drag and drop, tree controls, layout managers and the like and more. Given the highly configurable (and stylable) characteristics of such chrome, I think they have a sizeable advantage over traditional toolkits which usually have very minimal stylistic capabilities.
My prediction is that we're perhaps five years out yet from the great desktop implosion, where standalone applications get replaced with Javascript toolkits, maybe a decade on the outside, but that a lot of this transition is taking place now at the edges. Improve the speed differential on JavaScript and you take away the biggest factor keeping web apps from replacing their desktop alternatives.

Great writeup Robert,
I think the whole area of the convergence of web and desktop applications isn't being discussed enough. Generally speaking we have already seen many desktop applications migrate into the browser environment (especially productivity apps like mail, calendar, now office, but also games).
Its a big questions, I think though that the characteristics you described are that of the 'status quo' of web-apps and not necessarily where we are heading.
My company works around the premise that we are all heading into some sort of hybrid, where applications are part offline, part online. A part of the app's logic runs on the desktop and part of it runs in the 'cloud'. This will in time merge the application platform, meaning we will end up being able to compare MFC & COM (or WPF and .NET) to HTML/CSS and JSONP. These will merge in time to a new status quo and we'll end up with a single powerful application delivery and consumption platform.
We're doing some work in this area with Bubbles http://www.bubbleshq.com/ Which lets you run web-applications as applications in a desktop environment, giving them features like desktop-drag-and-drop, system tray presence, accessibility, etc. We actually summarize it in our philosophy http://bubbleshq.com/philosophy

I think the browser chrome can unfortunately become completely messed up. Add in a google bar and whatever shortcuts toolbar a person inadvertently adds, and I've seen small screens loose a lot of browser real estate. Also easy to loose any sort of cohesiveness between the browser nav controls and the web app experience itself. Open the app in a new chromeless window, and build the nav controls yourself and the UI is finally clean. Pros and cons of course, but still worth experimenting with imo.