I've been trying to avoid regular expressions in dojo.query. It's a difficult tradeoff since regexes are very space efficient vs. lots of
indexOf operations. A little digging on the point turned up a fascinating article on why regexes in most languages are slower than they need to be.
Now if only there were some explanation of why regular expression string replacement, not just matching, is brutally slow across the board.
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.
Jennifer and I were lucky enough to be able to visit Hong Kong for the last week and change, and I've gotta say that it's one of the best places I've visited. On the way there, the camera we brought broke, and so while we picked up another one, all the pictures we took are on Jennifer's Flickr stream.
We had a great time and Jennifer's talk was very well received. Getting around Hong Kong is surprisingly simple given how tortured the street layouts are. The service at hotels there is like nothing else, and the city is breath-taking in scale. We had some of the best thai, cantonese, and dim sum we've ever tasted, thanks in large part to a little guide book we picked up in a book shop in Kawloon. Also, if you get to Hong Kong and you need your daily dose of dorkyness, check out the Science Museum. Their 4-story-tall Rube Goldberg device is something you don't easily forget.
If you were trying to get ahold of me in the last couple of weeks, I'll try my best to get back to you soon.
So there's a new MSIE web developer toolbar out-and-about. Like the last version, there's a lot of good stuff in there. It's not Firebug, but nothing else is. Anyway, it does lots of stuff you want, in particular, it replicates the fast-path for cache clearing that the Mozilla Web Developer Toolbar (that the MSIE one is a clone of) provides and goes it one better by promoting it to a top-level button.
And then it gives you a confirmation dialog. I shit you not.
Removing one click: good.
Leaving another (useless and impossible to disable) click in the web-dev fast path for a non-destructive operation (it's just a cache after all): stupid.
As things ramp up for the Comet Developer Day and the Dojo Developer Day(s), there's been a ton of activity in Dojo-land. Here's a selected sample:
- SitePen begins to offer Dojo Training to the public! Signup here. Since we employ a huge percentage of the committer base and fund significant new development on the toolkit you'll know you're getting it "from the horse's mouth".
- Shane O'Sullivan of IBM has made a first public release of his GUI Dojo build tool.
- The second part in the SitePen performance blog series is up (part 1).
- Dojo 0.4.1 blew past the 100K download mark (now at ~180K) and continues its march to becoming the most successful Dojo release ever
- And not to tease too much, but there's stuff coming down the pike that I'm tremendously excited about. More news on that after 3D2.