Wednesday, December 22, 2004

Web software hits the wall

I have been thinking a lot about web-based software versus rich-client software recently, fueled by thoughts by Adam Rifkin and visions by Marc Canter and a bunch of other stuff besides.

We are staking our company on client software, but not traditional "applications", but true network-based applications. I think that web software has hit the wall, and is becoming marginalized because of inherent limitations in what is possible.

The world wide web is a bit like cable TV: it's a downstream thing. A web site dispenses content to lots of clients, but the clients struggle interacting in an upstream capacity (like cable). If you've ever uploaded photos to a web site, you know that it's inherently a downstream activity, this web surfing thing. Uploading is like swimming upstream, salmon jumping out of the river, making little progress, struggling....

But that's not even the biggest limitation. It's not a coincidence that Napster, Kazaa, and instant messenger clients are all native applications: they simply could not work over a web-based platform. They call it peer to peer but what it really means is that the applications can use the network any way they want, rather than being forced to talk only to the server from which they were spawned, as web software must do.

Consider also that so-called "web software" wouldn't work at all without the native application called the browser. And it is not a trivial piece of software, no matter whether you look at IE, FireFox, Safari, or whatever. They are complete operating systems unto themselves, and they still do a lousy job of running application software.

That's because they're web browsers. Not application platforms. Java notwithstanding. There's no support for good UI (Laszlo notwithstanding). And they're limited in terms of what they can do on the network, for security reasons.

So we're watching blogs and wikis and social networking and web-based services grow on the web platform, with the conspicuous absence of messaging, collaboration, and file sharing, because they're basically not possible.

We think that many of these useful network paradigms can still be combined, but it requires an entirely new application that itself is kind of a platform, like the browser was before it, but which enables a richer kind of communication-based work to be done. We have that, although today it looks a bit more like instant messaging than it does a web browser. Or does it look like Kazaa? Or sort of like an email client? Hmmmm....

The chief value of web-based software is that the data stays on the web site, centralized. This is undeniably powerful. But it's quite possible to do without using a browser as your dashboard. We think that combining centralized data with an inherently powerful communications tool you get the best of both worlds.

2 comments:

rob r said...

web apps , messageing , services have hit the wall You say.

You may reconsider after looking at Jax-Rpc, SAAJ api for SOAP Attachments, and open API's like activeMQ.

These components can be combined to provide fully fault tolerant, MOM compliant, centralized services like full movie e-distribution for providers like NetFlix.

That sort of distribution as a service will happen, dispite your dismissive comments.

rob r said...

With evolving API's like: Jax-Rpc, SAAJ api for SOAP Attachments, activeMQ and with the amount of attention that SOAP is getting there will not be a "hit the wall" experience for Web apps and for Web Services even when the services require "upstreaming".

For example, these components can be combined to provide fault tolerant, async MOM oriented, centralized services like full movie e-distribution for providers like NetFlix. The payback would be no more snailmailing of your DVD's and a huge reduction in xpense at Netflix.