[thelist] Spolsky: things you can't do really well in a web application

Ken Schaefer ken at adOpenStatic.com
Fri Jun 18 23:12:00 CDT 2004


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "Mike Migurski" <mike-evolt at teczno.com>
Subject: Re: [thelist] Spolsky: things you can't do really well in a web
application


: > So, I'm curious. Some of 'em seem, conceptually, simple. Spell checker?
: > Keyboard driven interface? I appreciate the qualifier 'well' in his
: > comment, but is this really accurate, right now today?
:
: Note that he does qualify this statement in the article by saying that
: creative use of javascript is closing this gap:
:
: These are not all big issues. Some of them will be solved very
: soon by witty Javascript developers. Two new web applications,
: Gmail and Oddpost, both email apps, do a really decent job of
: working around or completely solving some of these issues. And
: users don't seem to care about the little UI glitches and slowness
: of web interfaces. Almost all the normal people I know are
: perfectly happy with web-based email, for some reason, no matter
: how much I try to convince them that the rich client is, uh,
: richer.
: -- http://www.joelonsoftware.com/articles/APIWar.html
:
: It's a great read, if you haven't seen it - I haven't seen the URL in this
: thread, so there it is. Of interest to IE watchers wonder WTF it's going
: to support CSS or the DOM correctly, is this conjecture:
:
: So the Web user interface is about 80% there, and even without new
: web browsers we can probably get 95% there. This is Good Enough
: for most people and it's certainly good enough for developers, who
: have voted to develop almost every significant new application as
: a web application.
:
: Which means, suddenly, Microsoft's API doesn't matter so much. Web
: applications don't require Windows.
:
: It's not that Microsoft didn't notice this was happening. Of
: course they did, and when the implications became clear, they
: slammed on the brakes.  Promising new technologies like HTAs and
: DHTML were stopped in their tracks. The Internet Explorer team
: seems to have disappeared; they have been completely missing in
: action for several years. There's no way Microsoft is going to
: allow DHTML to get any better than it already is:  it's just too
: dangerous to their core business, the rich client.



I think some of this is a little wrong (and some is right). I believe
Microsoft knows exactly what's going on, and is already building their "next
generation" architecture.

There won't be a "web client", and a "rich client" - there will be just by
"the network", for want of a better term. Someone who knows a lot about
Microsoft technologies, and where Microsoft is going made this call about a
year ago, and I'm beginning to agree with it more and more:

A user is going to use an Avalon browser, type in a URL, and get a
full-blown managed application. On the host machine, the code may execute in
some kind of native mode, but it's going to be serialised somehow by .Net,
served by ASP.NET, pushed out onto the network by the native HTTP.sys kernel
mode driver, and arrive at the user's desktop as XAML, and run as a managed
app within Avalon. The .NET runtime will keep things sandboxed, in a similar
way to how a JVM works (and you use CAS to determine what the app can do),
and XAML will allow for a rich client experience, but with the app served
"over the web".

Incidently, this is why I think people who say that "HTML isn't going to
work in Longhorn" are also wrong - it'll all still be there. However,
there'll be a subset of technologies for clients that support it.

That all said - I agree that Mozilla and XUL will be some of the most
important OS technologies to develop over the next few years. It will be
interesting to see how these thing pan out :-)

Cheers
Ken



More information about the thelist mailing list