Infrequently Noted

I finally blogged the work I've been doing on dojo.query. As you can guess, it's a CSS query engine for Dojo, and as you can probably also guess, it's fast. Or at least as fast as you can make a system that needs to hoist itself by its own petard thanks to the network latency of sending the darned thing down the wire every time. As web developers continue to expect ever more out of their tools, it's becoming clear to me that the dynamics of the "Ajax platform" are a deck that's heavily stacked against novices to the advantage of experts. For a long time we've been trying with Dojo to help tilt that balance back in favor of those who haven't co-evolved their skills to suit the peccadilloes and vagaries of the web. But I don't know that we (or anyone else) is really succeeding at it. The "Other Language to JavaScript" compiler crowd is building a very leaky abstraction that is going to take years to get right. Meanwhile, folks trying to do "something interesting" tend to look at the current state of play in pure-browser apps and run headlong into the arms of Macrodobe or Microsoft. Flex is a surprisingly easy sell for organizations that don't have the health of the web in mind.

Ajax is getting us "old apps ++", but even with Comet in the stew, too much complexity is still laid at the feet of end developers. Complexity == cost. Cost == opportunity. Is it any wonder that the most interesting startups today are either retreads of old concepts or simple integration of new data paths into the old ones?

So long as it's still this hard for everyone to build web apps that don't contain nasty surprises, the web's formidable advantage in openness will always be at risk of being dominated by other factors. As the Linux world has painfully discovered, being open isn't a guarantee of value to everyone you wish to entice. It's an opening gambit in convincing people of top-to-bottom value and not even a strong one.

I'm starting to focus more and more on the "sharp edges" of the web development experience because I find that web developers discount mental overhead and workflow impediments without much thought to the real costs. Jot's design hit a chord with me precisely because it rounded off some of those sharp edges: the hours of database and web server setup. It's those kinds of assumed costs that keep tripping us up. They're fine for organizations that want to be experts or think they can get competitive advantage out of it, but how is it good for everyone else?

One of the big goals with dojo.query wasn't only to be relatively fast compared to the other query engines that you can chose from, but it's to help even out the performance peaks and valleys. It's still possible to write poorly performing queries with dojo.query, but for the most part you're going to have to do more typing to get a slow query than a fast one. It may not be the kind of thing that webdevs will notice, per sae, but rounding off the sharp edges is an exercise in usability: things are only useable when they do what you expect them to. A system that hurts you more than you expect isn't useable.

I'm not sure that I have a point with all of this other than to hope that others will either point out a great big hole in my logic or, like me, start to work on rounding off those edges. If I'm right, the web needs us to question our sacred cows and continually sunk costs. Openness might not have strong value on an individual basis, but in the aggregate it's important for everyone.