Olivier has offered a challenging analysis whose name explains his thesis: "Organizr is Nice, But Not a Web App". The fundamental debate is whether an in-browser Flash app that calls a RESTian web service is a "real" web app in the same sense that an HTML app is.
My initial thinking on this is:
- A management application running in Flash is actually in a slightly different class, a middleweight interface halfway between a thin-client HTML page and a rich executable client.
- Who cares?
Stewart makes a fairly compelling argument that the real-world web consists of anything that sits on top of it. I've talked about creating web apps that are valid XHTML, and interestingly the reaction from people commenting was to focus on whether an application's output was valid, with the markup of the application's actual user interface seeming almost unimportant. That's completely understandable, but it underscores the "Who cares?" point by refocusing on what comes out of the application, instead of the technical specifications of the application itself. Even if Olivier's right, it doesn't change anything.
The more interesting part to me is the layering over web services that we're seeing. DropCash is the definitive example right now, reusing existing APIs like TypeKey and PayPal to provide a useful and unique service. But the potential for building even more on top of these second-level platforms is the reason that I'm excited about DropCash.
I want enough APIs built on top of DropCash that I can build (or rather, one of the PBs can build) a wishlist gifting tool. Give the service a person's name, and it goes to their site and finds their Amazon wishlist link, maybe from their FOAF file. Using the Amazon API, you grab the person's wishlist, enumerate the items, and sort them by price, lowest to highest. Create a DropCash campaign that ends on a certain date (the giftee's birthday?) rather than at a certain dollar amount. Retrieve the images of each item on the wishlist and line them up next to the bar chart showing the campaign's progress.
Then it's all about notification. All of you who thought "DropCash needs an XML feed!" rest assured: Andre's thought of that, I'm sure. But this campaign could update donors either via subscription or email and say "We've raised enough money to buy a CD!" or "...to buy a TV!" or "...to buy a PC!". That's a useful layering of web services. Wishlist gifting app on top of Amazon on top of DropCash on top of TypeKey on top of PayPal. Nothin' but net.
Should you do it in a Rich Internet App or a thin client or a dedicated desktop app? I don't much care. If you do it right, it's easy enough to plug any of those into the service you've created. Do one reference implementation, and let the Lazyweb build the rest of the versions and improve upon what you've done. Let a thousand clients bloom. Web as OS or whatever.
Naturally, I love Organizr because it's a cool app. But I don't just want it to talk to the Flickr API. I want to layer it on top of the Atom API and see my posts in the same view that I see my images. Timeline slider that scales and shows posts within a certain range.
Then, stack Organizr on top of the Wishlist app. I want to see pictures of each of the gifts that's been given away on campaigns that were created in the last month. And then...?
My feeling about it has always been (and remains) that "the Web" refers to a very specific set of technologies: HTML and JavaScript delivered over HTTP. Delivering HTML by some other means? Great, but it's not the Web. Delivering something else over HTTP? Also great, but also not the Web.
(Yes, that means Web services are misnamed too. I fully expect to lose this battle; this fact, however, does not make me wrong.)
RESTfulness is not strictly necessary, but it is important, since it facilitates linking, which is the very essence of the philosophy underlying the Web technologies.
I agree that Flash apps seem to fall into a middle tier between desktop apps and Web apps: client-server apps in which the client-side code is only resident on the client for the duration of the user session. I guess this is the Rich Internet Application that Macromedia is always on about.
Jesse, if you're going to be that restrictive in your definition of "the Web," why include JavaScript (or, better, ECMAScript)? after all, it wasn't introduced until Netscape 2.0 which was released in, what, early '96? That's over 5 years after the web really debuted (and 7 years after Berners-Lee conceived of it). Further, a major aspect of the Web as it's existed since the browsers of the early '90s is the ability to hyperlink to URIs using protocols other than HTTP (e.g. gopher, ftp). Servers of the world, unite!
Your highly restrictive definition seems far more applicable to the term "web page" than to the Web itself...
how unique is dropcash really? there are a variety of other tools that help people fundraise online, (entango, active.com's activegiving). dropcash is probably the simplest, but you can't do anything to personalize it or make it interesting to the possible donor.
When I think of the promise of "web apps," I think of applications that can run using thin, ubiquitous technology based on open standards. A web app would be able to run in any browser with a few basic capabilities, on any platform that supports such a browser. The cool part is being able to walk into any library with Internet access and bring up all of my email, calendaring, notes, blog admin interface, word processing. I can do the same from an Internet cafe running IE and Windows 95 on 500MHz Pentiums, or a friend's house running Linux and Firefox.
Flash doesn't meet this expectation, so it's less cool. JavaScript is ubiquitous and open. Inconsistent implementations of JS have held back some of the more whizbang just-like-the-desktop web apps, and encouraged others to use platforms like Flash for this sort of thing, but there's plenty we can do with what works.