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
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:
- A more flexible security model
“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.
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.
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
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.
- 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"
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.
- 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
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.