What I Want For WHAT

Joel Spolsky satisfyingly nails a bunch of ways to improve client-side web app development which the WHAT Working Group
should work on. All his suggestions are excellent and well worth
looking over, even if some seem to require the same “boiling the ocean”
that he doesn’t want to hear about. That said, most of his list could
probably be done with a good set of Javascript libraries, along the
lines of Dean Edwards’s IE7,
and his #2 (fast REST queries back to the server in JS) is pretty much
- well, almost – with us already, looking at combinations of things
like XMLHttpRequest and mod_pubsub.

But anyway, he ended his piece with a call for more suggestions that
he could link to. I’ve been doing a little bit of browser app
development in the last few days, and these are the things that spring
most readily to mind:

1. A more flexible security model

   The current Javascript security philosophy can be easily summarised thus: “No.” (And the IE/Win version can be summarised thus: “Well, okay, but just a little bit.” (pause)
   “Hey! Come back here!”) Back around Netscape 3.0 there was data
   tainting, and Netscape 4.0 had digital signatures. Both have fallen by
   the wayside, and it’s a right pain because I want my app to do things
   like fetch data from other parts of the web outside of the originating
   server, but it can’t. Instead I have to proxy through my own server,
   which generates horrible load and makes the app much slower. Sure,
   there are sound reasons why it shouldn’t be able to reach outside by default,
   but this is ultimately down to trust issues. If web apps are aiming to
   replace native apps then they need to get reasonably close to the
   capabilities that native apps have. The user should feel comfortable
   that a web page isn’t rifling through his hard drive without his
   permission, but when a user and an app both want the same thing and the
   browser is stopping them, it’s a bit of a pain. After a while it feels
   like the user is having to gaze longingly at the app through the solid
   glass barrier while they talk to each other over the visitor phones.

2. Less Javascript, more XML: Accessibility for everyone and everything

   Joel calls for a richer set of controls and events. Those who know a bit about Mozilla will immediately start thinking about XUL and XBL, and Microsoft’s equivalent (XAML) is also relevant here.

   Much of this stuff is already doable in Javascript, but XML languages are better for a reason fundamental to the web: They lower the barrier to processing.
   It is an order of magnitude easier to decipher what a document is
   specifying than a program: the only way for a machine to really
   understand a program is to execute it. Unlike Javascript or any other
   Turing-complete language, XML doesn’t suffer from the halting problem.

   Lowering the barrier is vital so that a wider range of
   lesser-powered web clients can understand your content, whether those
   web clients are mini-browsers running on embedded devices or ten-line
   scraping scripts. Furthermore, explicit unambiguous markup means that
   the client then has more freedom in rendering the document in the way
   it sees fit, and this freedom is vital to true web accessibility. If
   the speech browser for blind users knows that what it’s trying to
   render is not just a collection of layers with links in them but a standard menu then it can render it in a much more usable way.

3. Better documentation, please

   This sounds like a trivial one outside the concerns of WHAT, but
   it’s just as fundamental. If you really want to beat Microsoft in the
   race for developers then you have to also beat MSDN, which is probably the best developer information site in the world. On web app development alone it’s better than Netscape DevEdge and the W3C
   put together. The reason I mention those last two is because, if you’re
   developing for Mozilla, you don’t have much solid documentation apart
   from those (the pretty-good XUL Planet notwithstanding, since it’s more about extending Mozilla than developing web apps).

   The other night I was battling with setSelectionRange(), which is a method of the INPUT TYPE="TEXT"
   object. The thing is, I found out about it in a Javascript tutorial on
   some random site. Try searching for it on mozilla.org. Actually, don’t
   bother: it’s not there. This is particularly galling when you consider
   that Mozilla is the only browser that currently implements it. Those who’ve documented it appear to have done so by churning over the source, for lack of any other clues.

4. A version of the DOM that isn’t so prissy

   This is a much weaker/whinier one and I haven’t done nearly enough
   DOM work to be certain of it, but: It always seems to take way too much
   effort to do the most basic things in the DOM tree. It feels really out
   of sorts in Javascript, not having nearly the same fluidity and
   ease-of-use of the rest of the language. It’s way too Java and not
   enough Perl/Python. I want to sling it, dammit.

   Update: Ah, this is what I want, and it looks like I’ll get it. Yay!