There's "does worse than fat local client" (but better for development and hence a worse-is-better situation) and then there's can't do it at all and will always lag behind so much that it doesn't make sense to think about it.

Are you going to put up servers so that I can solve large-scale quadratic programming and machine vision problems? Are you going to ask me to run a non-linear optimization routine written in JavaScript?!

You expect me to accept circa-1994 graphics in games? You expect me to pay for that?

What kind of dreamworld are you living in?

Google Spreadsheets hemmorages, huffs and puffs if you have more than several dozen rows - it robs power users of most of their keyboard shortcuts and has no kind of extensibility at all. It uses up dozens of MB of RAM with a blank sheet. It's a real Excel killer alright. Which is amazing because Excel has only seen minor, incremental improvements in the last decade.

You're telling me quasi-3D games I played in 1994 on a machine 300x slower than the one I'm using right now constitutes approaching parity with local native code?

In several years, a language like JavaScript will run on the machines available then the way C++ runs on today's machines. But when that happens, machines with many cores will be ubiquitous, and the ridiculous lag will still be present - would you like to run your embarassingly parallel program with 1 core or 32? (1 of course, it's online! Wowzers!)

You're absolutely right, in some aspects. Some things will always be better done locally; it's ridiculous to contemplate writing a 3d game without access to a 3d API, for example. And it's silly to have a ton of cheap processing power sat under your desk pretending to be a 3270.

So I wonder if the future is going to be client-server at all? Perhaps the arrangement will be that in exchange for using the services of webapp X, you contribute your processor to act as part of the distributed processing for the backend part of that webapp. Your request might end up being processed on your machine, or it might be processed three thousand miles away whilst your machine is processing someone else's request... If peer-to-peer file transfer applications (or, you know, natural history) have taught us anything, it's the value of distributed, decentralised, cellular systems. The webapps we're seeing right now are incredibly primitive, and have barely scratched the surface of such things - but when they do, when people start talking JSON or AJAX or some other ETLA to each other's browsers rather than to centralised servers, when the only difference between a web browser and a web server is that the browser has the GUI loaded - then we'll really see the value of webapps...

...hmm. Excuse me, I may be a little busy for a while...

"does worse than fat local client"

Are you talking about the average Denny's customer? <ba bing!>

Agreed, I think the dominance of the web is inevitable.

Kind of as an experiment and part out of not wanting to reformat my diseased hard drive, I spent about 3 months last year booting from a minimal Linux and running Firefox (and a pdf viewer) as my only apps. I really didn't miss the desktop a whole lot. In the end, the only reason I run desktop apps today is to take some load off of the browser. I like Meebo more than GAIM but the really intensive javascript apps just use way too much memory in Firefox, especially when you have 12 hour Firefox sessions.

I'm looking forward to my future web-only existence... and I'll be first in line for the neuro-implant.

> the really intensive javascript apps just use way too much memory in Firefox, especially when you have 12 hour Firefox sessions

I suspect that huge improvements in the state of Javascript interpreters will really start to change the equations. If JS is Lisp in disguise, there's no reason why JS engines can't start to benefit from the decades of evolution put into Common Lisp runtimes.

Come to think of it, what if a JS engine got fast enough that the browser itself could be written in Javascript?

For now, we're getting some nice incremental improvements. Firefox 3 Alpha is worth using just for the improved JS engine.

Hey gwen...what do you mean by this: "If JS is Lisp in disguise"?

Well, look at parenscript for example. It's quite easy to translate Lisp into JS. Moreover, the first prototype of JS engine in Firefox was written in Lisp.

<<Over time, you'll see webapps take over more and more markets from the desktop, until there's nothing left.>>

Maybe. I think for this to be to be the case there needs to be a better thin client than the web-browser as currently conceived and perhaps higher level ontology (OWL?).

But I am willing to be corrected. Do you think JS-browser integration as it currently exists is powerful enough for the stuff you are talking about?

I think there needs to be a better thin client than the current web browser, but I think that client will be an evolution of current web browsers rather than a new app.

Here's how I see it playing out:

JavaScript libraries will build increasingly more full-featured UI libraries. That's happening already with JQuery and YUI and Scriptaculous and Dojo. The increasing complexity will put increasing demands on the client-side processor, so browser makers will respond with faster JS implementations and specializing JIT-compilers (like Psyco or the JVM).

Meanwhile, SVG support will grow - it's already supported natively in Opera and partially in Mozilla/Firefox, with Safari and IE support under development. Once that's widely available, it'll open up a whole bunch of new app categories - games, grapics apps, maybe even photo manipulation if JavaScript gets high-speed array operations and access to pixel buffers. When enough people start using SVG, I could easily see browser makers implementing their SVG support to take advantage of 3D hardware acceleration.

How long do you expect all of this will take? Will we see full SVG support in one year, two years, ten years?

It's here now (via plugins, development versions, etc.), the real barrier is adoption. If you can dictate your user's browsers, you can use SVG. Problem is that for something to be useful on the web, it really needs to be present without needing plugin installation on the vast majority of browsers. I see that as taking a couple of years.

Any good examples of people doing useful things with SVG that I can take a look at?

A lot are actually using the <canvas> tag instead, which is a bit more widely-supported in present browsers, though I believe it's a bit less flexible.

There's the aformentioned Doom clone (http://canvex.lazyilluminati.com/83/play.xhtml). A bunch of JavaScript charting libraries have sprung up recently - one I'm familiar with is WebFX (http://webfx.eae.net/). I did a real-time charting widget for my former employer that graphed stock prices in real time on your browser; unfortunately I can't show you that. SVG's also apparently getting popular in bioinformatics for viewing protein-folding and other biochemical interactions.

Doesn't this come back to the problem of ontology? Given the different possibilities, what makes you so sure SVG will come out on top? Can it exist w/o a standards org like W3C to promote its adoption?

The Doom clone was why I specified 'useful' in my last comment ;)