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!