Eugueny Kontsevoy writes in Web vs Desktop Nonsense:
Can we see past the browser? Can we accept that browser is just a runtime library that most people do not need to download to consume your application?
…
Come on, the “anywhere” part should not come at expense of losing 90% of other features.
…
Yes, future belongs to web applications, but I am not so sure that browser, with [its] weak runtime and close to non-existent programmable graphics, should remain a necessary vehicle for it.
The more I think about the subject, the more I believe that HTTP is a truly successful distributed system because it doesn’t try to solve what most distributed systems tried to solve. It doesn’t try to blur the distinction between local and remote resources; everything is a document accessible through a URI. (At least, that’s true if you’re a RESTafarian, which you should be.)
The question Eugeney raises is important. We already know how to build decent — even good — native applications. Is the zero-footprint installation (minus several hundred kilobytes, if not a few megabytes of JavaScript, or a few tens of megabytes of Flash, Air, Silverlight, Moonlight, or Java) so compelling that everything has to get crammed into the web browser model?
In my mind, that’s a mistake as big as pretending that accessing a distributed component is exactly the same as accessing a local component.
Agree completely, I use web mail because it's a great service, not because the application is so great. Google Calendars likewise, ubiquitous availabbility itself is the killer feature and not the application per se.
Photo management is a great case in point. I use iPhoto to manage all my home photos and videos, but also upload some of them to Flickr. The only advantage Flickr gives me is access via the web. There's just no way Flickr is going to have anywhere near the features, usability and responsiveness of iPhoto or Picasa in the next 5 years, and by then the desktop photo managers will have moved on even more.
Online services are a great adjunct to desktop apps. I'd like to see more network services that have slick desktop applications that link back into web services that degrade gracefully to a web app front-end if you don't have the desktop app available. Apple seem to be going this way with their iLife suite and .Mac service.
I don't completely follow. If everything is a document accessible through a URI, isn't that a blurring of local and remote resources? I.e., http://1.2.3.4/a/b/c/resource, how can one tell if this is a local or remote resource?
Unless "resource" implies an active component, like an object or function chunk or something. But isn't the distinction between a document and an active component a matter of interpretation (one person's JavaScript is another's text file)?
I guess I'm still not getting the philosophical part of the argument. Then again, I prefer using Web-based apps, so that may be the reason...
You're missing something.
The magic is in the combination of HTTP _and_ HTML. I've yet to see a single GUI toolkit that came even close to the ease of use you get by writing HTML, because a huge amount of the overhead is handled by the browser.
*FINALLY*, somebody said it! ;-) :D
@Shalon Wood,
I think it is you that is missing the point. For example, how many *desktop* applications out there consume Atom/RSS feeds *over HTTP*? In this example there isn't any need for UI markup (something HTML was never designed for, btw... It's a document markup language, not a UI markup language, though it has been hacked to within an inch of it's life to become both)
There needs to be a clean separation between what an HTTP application actually means. HTTP is all about accessing resources in a stateless manner. *That* is the point. Designing your applications in such a way as to make them functional using a stateless protocol is the key to building great web-enabled applications.
By concentrating an the essential functionality of what the web was always meant to be, HTTP provides a dependable protocol upon which any framework can be built. No matter how complicated the requirements, HTTP just does it.
I think the initial post has something more deep to say than the obvious. What I understood was, if the browser model is going to be the dominant as now (AJAX, rich web applications etc) or programming and applications will move to another model (networked applications)