W3C home > Mailing lists > Public > public-webapps-cdf-discuss@w3.org > June 2004

Spolsky's requests for Web Applications

From: Dean Jackson <dean@w3.org>
Date: Fri, 18 Jun 2004 15:00:13 +1000
To: public-webapps-cdf-discuss@w3.org
Message-ID: <20040618050013.GC840@grorg.org>

This is a response to two excellent articles by Joel Spolsky
(particularly the second one).

http://www.joelonsoftware.com/articles/APIWar.html
http://www.joelonsoftware.com/items/2004/06/17.html

Joel raises some points that are very relevant to W3C work in the area
of Web Applications. Here I go through some of his wishes and
wish-nots, giving my personal opinion (by no means an official
position of W3C). It's an email, not an article, so it is probably an
unstructured ramble. One day I'll start a weblog and write proper :)

The good news is that it seems we have many of the big players
ready to go in this area. Joel may get some of his wishes
sooner than he thinks (let's hope!).

Let's start with the wishes.

> 1. Improved inline editing (step one: make contentEditable work in
>   Gecko just like it does in IE 5.5+)

This is an interesting suggestion that I haven't heard raised within
any W3C Group for a number of years. How many people would like it?
How many people use it in IE?

> 2. Javascript features to do fast REST queries back to the server, so
>    I can implement things like a lush spell checker with the
>    dictionary on the server. It should be possible to have a 300,000
>    employee directory on the server and create a web app that has a
>    list box where you can type the first few letters of an employee's
>   name and see a filtered list as fast as you can type on the screen.

Joel++. At the moment people either use post/getURL or the IE
XMLHTTPRequest object (which seems to have XML in its name for no
reason other than coolness :). None are "standard".

This is an important topic within W3C. Firstly, there is the DOM3 Load
and Save features but I think they don't really address what Joel is
asking for. More interesting is the work from the SVG Group who are
standardising much of the old "window" object. SVG 1.2 has both an
URLRequest interface and a raw socket interface [1] which would
address Joel's needs. Why sockets? Because developers don't want to
proxt stuff through HTTP (like IRC) and it has shown itself to be
popular in technologies like FlashComm.

[Aside: You'll see that we're trying to move to event-based
programming within the new APIs. We've found, and received lots of
feedback, that it is the right model for Web Applications. You may
also think that the current APIs are broken, which is also true.]

It's worth mentioning that the SVG group has received a lot of flak
internally and externally for creating such APIs, on the basis they do
not belong in an interactive graphics specification. We know!  The
problem is that we get lots of people (like Joel) asking for the
features and there isn't any place (as yet) within the W3C to make it
happen.  The SVG Group had no choice but to start the work
themselves. They have every intention of opening the work to another
group and ensuring that they work on all formats, all platforms in all
implementations.  What is there is SVG is a *Work in Progress* - it is
not a final perfect API.

I suggest that the people interested send in their comments (to this
list for example). Let's work together as a community to come up with
something and avoid a number of competing proposals.

Before we move on, Joel requested REST like APIs.  I assume other
people will want SOAP. Both are interesting and useful.  What do
people think?


> 3. A rich set of standard controls for application development that
>   provide better ways to upload files, better ways to drag and drop
>   with the desktop, etc

Again, the SVG Group are adding as much of this as possible, based on
developer requests. It's really hard to do it in a secure and
interoperable way.  Upload file is OK, we've started on that [2]. Drag
and drop and clipboard access is something that applications need but
requires some form of security model. The alternative would be to
leave it up the user agent, which is probably the approach the W3C
will take until we get more input.


> 4. Compiled or compressed JavaScript, so that web applications can use
>    really large amounts of JavaScript with decent performance

My suggestion for compression is to just use gzip and have the
user-agent decompress it (or do it at the HTTP level).

For compilation, that's something that is up to the implementation
(unless Joel means delivering compiled Javascript to the client, in
which case I'd prefer to use another language like Java, or even one
of the .NET choices).  This should cue Jim Ley to step in and say
something about compiling Javascript.

Having said that, I think there is a much bigger win by moving to
Ecmascript 2.0. That is, I suggest using a better language in order to
help developers write better code. (Not that there is much wrong with
Javascript...I don't want to raise that meme again!)


> 5. Better standardized windowing features. At the very least I'd like
>    modal and modeless dialogs that pop up instantly, a standard way to
>    do a menu inside a web page (with ONE consistent UI, not
>    everybody's wacky DHTML menu that are all a bit different),
>    TreeView and ListView controls, and a standard way to make a
>    toolbar/button bar

By far the most common request I ever see! Unfortunately, I see lots
of people ask for it and very few suggest answers. Or, put more
precisely, the answers I see often don't give much more than an
opinion (low on technicalities).

But, yes, I'd love to see this. Here are some of the related
questions:

- Which widget set would you pick? (eg. XUL, Swing, Cocoa, WinFX, ...)
  Does it matter? Invent your own?

- Which set of widgets is enough? Some people will want a Tree View,
  while others won't be able to live without a color picker.

- Should they be native or not? Does this matter?  (The answer I hear
  is "yes, it does matter").

- Can I extend them? Can I embed them (eg buttons in tree view)?

The other problem here is that it takes a huge amount of time to first
design something that is useful, and then a huge amount of time
implementing it (and we're talking cross platform).

As I'm one of the people who ask for the feature without suggesting a
good solution, I should not complain. Here's my gut feeling: a minimum
set of useful widgets to make it easy for simple applications, and
then an extensible architecture for other widgets. It's also important
that the new widgets people develop are able to be shipped as
components, so I can do something like "import JoelSooperButton" and
start using it.

Just before we move on to the next topic, the SVG Group have also
looked at popping up windows (not specifically dialogs). There is a 
feature in SVG 1.2 for that, but it still remains to be seen what
security problems it exposes.


> 6. The ability to get a "device context" (in a platform neutral way)
>    on an HTML control and wail on it to paint just about anything you
>    want.

Joel++. Lots of applications will need this (maps/location-based
services is a common example which is really popular on mobile
devices).

The good news is that I think there is a solution: SVG.  (I know, I
know.. I'm going to suggest SVG as an answer to everything related to
graphics, interaction and complex layout)

SVG effectively gives you a canvas to draw upon, a graphics
API that is powerful (can do everything apart from really high-end
stuff like 3D), a document model (which Web developers are comfortable
with) and an XML serialization syntax (which may or may not be
useful in this context).

Unless Joel meant what we call "immediate-mode" drawing - which is
sort of like paint and forget. In this case you don't actually add
anything to the document and you have to control when it gets painted
again (say if something overlapped with it). There are use cases for
this style of drawing, but I think the document model above will
really suit 99% of the cases.


> 7. A far richer set of events. At the very least I need to be able to
>    use the entire keyboard. Combined with #6 I should be able to
>    develop any custom control I want that is 100% client side.

Joel++ for full keyboard access.

As for the custom controls, this is what I was talking about
in #6 with SVG. If you don't need the complete power of the graphics
engine then you should be able to use HTML/CSS to build controls.

The CSS Group and the SVG Group are trying hard to make this happen
with XBL. Many of the examples that Ian Hickson has suggested for XBL
seem to come from potential applications such as gmail, where he
doesn't really need SVG - he'll just use HTML/CSS.

I hope that XBL will expose a more rich development environment also.
If I'm developing a map application, I want to program with Road objects,
not Polygons or Images. XBL should allow this.


> 8. Media integration, so I can play sounds or stream music in standard
>    ways without relying on <objects>

Joel++. 

Broken record from me - use the W3C specification: SMIL. Or, use
the <video> and <audio> elements from SMIL that were added to
SVG (and would be equally useful in HTML).

There needs to be APIs to these objects as well, so that I can play
sounds of demand (say for a game).


> 9. Graceful degradation for legacy browsers (IE. It's time to make
>    Microsoft play catchup again. Fire and Motion Baby.)

OK, here's the hard bit :)

I fully support Joel's point about not breaking existing content.
I also am supportive of the general backwards-compatible approach,
but mostly the way that Joel puts it here: graceful degradation.
Why? Because I can't see any way to address all the important needs
he raised and have them work in IE. Sure, you could have a lot
of fun with IE extensions, but it would be a hack, and difficult
to deploy to every platform.

Let's make sure we don't break existing content.
Let's try to make as much new content work on old browsers
as possible, but make it easy for people to understand 
what "features" they are missing and what the benefits are.
That way they can make an informed choice whether to upgrade or not.
And yes, let's not make their browser explode when they visit
an application that uses SVG.

Or have I missed the point? It's completely possible.

My feeling is that the Web Applications of today are doing pretty
ok. Look at Amazon. As Edd Dumbill says, Amazon show that it is
possible to write a Web Application that works great on any platform.

IMO, it's the Web Applications of tomorrow that need the help. I think
these are the ones Joel talks about -- Web Applications that feel
like real applications. He lists a few (fast drawing, updating without
server roundtrip, realtime spell checker).

I really hope we can make it to that point without going through
the "reinvent"-everything stage that he convincingly argues is
difficult to pull off. However, there are some big steps to
take, so it might be hard to avoid the issue completely.

One last thing. I hear lots of people argue that the desktop browser
is now a few years behind the mobile browsers. They say all the
innovation is happening on mobile, and that they can upgrade entire
platforms in about a year. They say that there are many more active
developers creating browsers on mobile than there are on the desktop
(anyone want to guess what proportion?). They say that the mobile
market is completely switched on to Web Applications and see their
phone interfaces *be* Web Applications.  This is all worth
considering. Maybe someday the desktop browser will catch up.


Let's move on to Joel's non-wish list.


> 1. Proprietary tools like Macromedia's or Java Applets that embed
>    clever widgets in rectangles in a browser. I want this stuff
>    integrated with DHTML and CSS, deeply in the fabric of the web

Obviously the W3C has a vested interest in this :)

This is why we held a workshop. One topic was how to integrate
all these technologies, and it looks like we will soon get
very serious in this area with strong vendor buy-in.

> 2. Things that don't have any chance of degrading gracefully on legacy
>    browsers. You have to be able to construct an interface that gets
>    better if you install Firefox, but still works on IE, without too
>    much testing on the part of the developer.

I think I've addressed this above, and again, I like "degrading gracefully".
(I just think it is really really hard).

I'll ask another question: do you think people would really move
to Firefox in this case? My extremely limited understanding of
business and market forces suggests that technology that is slightly
better doesn't really have the same chance of success that a true
revolutionary technology does. 

> 3. Boil the ocean schemes that require 400,000,000 users to install
>    some thingamajig before you get anything useful. Such schemes will
>    not go anywhere.

Yeah, accepted. I've been on SVG for years now with this problem,
even though it has been distributed to 100s of millions of users.
My take is that you have to give users a compelling reason to 
move.

On the SVG side, the compelling reason has become mobile. We're seeing
all the major phone vendors (Nokia, SonyEricsson, Siemens, Sharp, etc)
produce handset that support SVG, and Vodafone announcing they
will use SVG for applications in Vodafone Live. People don't need to
take any action other than get a new phone (which they seem to be
doing quite often at the moment). Desktop isn't as simple though.

Anyway, I've rambled on way too long. Everyone feel free
to tell me why I'm wrong (I'll listen I promise).

Dean


[1] http://www.w3.org/TR/SVG12/#network-data
[2] http://www.w3.org/TR/SVG12/#fileupload
Received on Friday, 18 June 2004 00:57:57 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 25 March 2005 11:17:30 GMT