bestkungfu weblog

Advanced JavaScript and the Web’s future

Filed in: accessibility, design, Web, Mon, Sep 13 2004 13:54 PT

I’m schooling Dan Cederholm in Week 1 of my fantasy football league. I’m up 176-86, with only Monday Night Football to go. (Dan has 3 players in tomorrow’s game against my one, but he’s gonna need Jake Delhomme to connect with Muhsin Muhammad for about 5 touchdowns if he’s gonna win.)

But this post isn’t about gloating over my team. Okay, it’s only kind of about that. It’s really about how cool the Web will be with a great, accessible application platform, and how today’s HTML+JavaScript just isn’t it.

The ESPN Fantasy Football League Manager is a really neat Web application. It does one thing I’ve wanted to have since my first Web development job: real-time updates without refresh. I sat and watched my team rack up the points for hours while I flipped back and forth on my TV. Super-cool. But how do they do it? Surely something built into JavaScript, right? Well, kinda. It’s there, in the XmlHttpRequest object. It works. But not without a whole lot of cajoling, according to the scripts I’ve been looking at.

Now, I’ve seen people hold up apps like this, or Gmail, and say that this is a sign that JavaScript is Good Enough Technology for Web applications. These people are wrong. The modern-day JavaScript application consists of ten lines of productive code surrounded by a thousand lines of error-handling and compatibility code. That’s one of the problems: maybe JavaScript development has geled to the point where developers can dive into the arcana of getting something done with it, but for now the developers of sites like Gmail and my fantasy football league are rare and valuable.

Please don’t get all wrapped around the axle because I’m picking on JavaScript. It was a fine language for what it could do a few years ago. But browser implementations, and the dependence on the hacks required to get around bugs and browser-war battle scars, make it a really poor platform for future development. I cannot subscribe to the theory that what we have in the browser right now is good enough, and we just need to pack in a little more script. No. What we need is to find what JavaScript developers have coded a million times, and make it a part of the base application platform. The side effect of that is something that can be made reasonably accessible. Today, assistive technologies have to try to divine what certain scripts are trying to do. Not fun. Not productive. It’s a broken system.

I need to talk to Mike Davidson. In addition to being my league’s commissioner, he helped develop the ESPN fantasy league system. (Plus he’s a fellow Seattleite. And his system gave me a kickass draft haul, despite the fact that I couldn’t make draft day.) I want to ask him just how much fun it was to handle all of the exceptions and limitations that the seasoned JavaScript developer has to deal with.

I’m not going to pick on him for being invalid, because, well, it’s too easy to take that cheap shot. I’m more interested in seeing if there’s some way to take the JavaScript development process, and arrive at an endpoint that is reasonably accessible. The WCAG Working Group is trying to come up with something instructive in that regard. And to that end, I published a Scripting accessibility techniques draft yesterday. It’s short, and some of it is already provably dumb, but with some work, we’ll make something usable out of it. Comments welcome.

Other folks want in on advanced scripting tricks. A host of technologies — some fairly new, like voice over IP; some old, like instant messaging, audio, and video — are reopening the minds of Web developers, and as they continue to see new applications of these technologies, they’re going to want to figure out how to play with them. It’s my view that the current plugin APIs and JavaScript just aren’t up to the task. I’m going to try pushing the envelope with my audiozine, but I know I’m going to need more stability and more features than JavaScript and the current plugin API can provide me. Which is a drag.

Luckily, there’s been some movement on both fronts lately. There are whispers of API standardization for plugins. And I noticed the WHAT working group has published a Web Applications 1.0 draft over the weekend. I’ll be taking a look at it shortly. What I’m hoping is that what comes out of that work is something that can be made accessible in some straightforward manner, or else my early retirement to a villa in the south of France could be in jeopardy. And after learning all the French I did in Montréal, that would be tragic.

2 responses to “Advanced JavaScript and the Web’s future”

  1. […] its debug-centric development, sandboxing, and insecurity, is not at all the way to go, as […]

  2. Mark Wubben says:

    You’re right. Most of the time that went into sIFR 2.0b was spent on debugging and debugging and debugging. And not just IE, also Safari and Mozilla had to be dealt with. (Opera worked along quite nicely, actually.)

    See also Kicking Some Tires and Forcing Safari To Repaint.

    The solution I think would be to create a set of really good modules, with a license which will allow all usage. Then we can have the problems out of the way.

    Writing these modules will require debugging and debugging and debugging though 😉

Powered by WordPress (RSS 2.0, Atom)