shiny simian scripts

We know them as Greasemonkey Scripts, but in Aaron Boodman's recent blog post, he says the new name may be "Content Scripts". Kinda boring. How about Slick Gorilla Scripts? Shiny Simian Scripts? Ach, "Content Scripts" sound pretty good I guess.

Aaron's post is chock full of meaty information; looks really good from 50K feet. Nice to see multiple files will be supported, including .css and resources like images.

I still use Greasemonkey for a few scripts I've written, but found the environment a bit limiting to get into it too deeply. Debugging was difficult, installation/deployment a bit unwieldy. And of course the endless issues having to do with writing screen scrapers, reacting to changes in your target's pages. I tried writing a few scripts for the Moz-based browser on my N800, which supports a flavor of GreaseMonkey via an system-installable update, but that was really painful. I hope we see a simpler workflow for developing these extensions, eventually.

The reason I'm so interested in this stuff is that I think user-scriptability provides a big paradigm shift. Much like writing editor macros for emacs or XEDIT or similar, it transforms an already powerful and useful tool into an extendable one. If you combine this sort of extensibility with the ability to publish/deploy and install these extensions easily, you have an actual platform on your hands.

It's easy to imagine, for instance, the sort of "content scripting" you could do, might subsume the whole "mashup" scenario; kind of flip it on it's head. Instead of having to host an environment to pull and push content from other environments, you can do it right from the primary content site.

Eventually this drives us to the point where the web applications we use are actually installed (ok, cached) on our machines, as extensions, and just push and pull data via HTTP/XMPP/whatever to data/service servers as needed. Of course, we've had a good 15 years of being able to do this, in theory, and are still stuck with icky, unusuable web sites that trap our data behind inscrutable wads of HTML. But things seem to be changing for the better here, over time; REST and all.

Something like Giles Bowkett's Hacker Newspaper could just be an extension, instead of having to be a 'site' with a 'server'. Who wants to deal with that junk?

Beyond all the content scripting stuff, Aaron also mentioned: "There is a team in Chromium working on an out-of-process version of the web inspector." This is great news. WebKit's Web Inspector is quite useful, but as an "in browser" debugger, it is also clearly totally unsuited for debugging on small devices. You know, like all those devices that are using WebKit? An external debugger is required for such situations. Something like Drosera. Both modes of debugging are nice to have - in browser and external; I want them both.

All GREAT stuff. Of course all of this is for Chrome, and not for WebKit. Which makes you start to wonder how we can get all this stuff into WebKit so all the WebKit consumers will have access. Either that, or start considering Chromium to be a platform to consume instead of WebKit. If these Chrome extensions heavily depend on things not already in WebKit, like V8, the multi-process model, etc, there would be even more reason to consider Chromium as the lower level platform rather than just WebKit.

ordered javascript properties

So all this time, I believed what I had read regarding the ordering of properties when enumerating JavaScript objects with the for...in statement, with this being a typical description:

A for...in loop iterates over the properties of an object in an arbitrary order.

That's from the Mozilla Developer Center JavaScript reference.

Turns out that's not quite true. See John Resig's blog post "JavaScript in Chrome", and scroll down to the section "for loop order". In particular, John writes: "All modern implementations of ECMAScript iterate through object properties in the order in which they were defined. Because of this the Chrome team has deemed this to be a bug and will be fixing it." Follow the links to the bugs John points out in his blog post for more discussion.

I couldn't resist trying this out myself, so created a little test case, here. WebKit Nightlies and FireFox 3.0 behave the same for all the cases, but Opera 9.23 acts a little differently in one of the cases.

John makes a couple of points I can't agree with, in his comments in the Chromium bug that he referenced.

• The specification does not define how an implementation should handle it - therefore an implementation should conform with other implementations.

  What? How does not having an explicit definition in the spec imply that all implementations should conform with each other?

• The argument that they're doing it to "keep the engine fast and lean" is bogus. There are two other, faster, ECMAScript engines out there: SquirrelFish and TraceMonkey and they both implement the looping indentically.

  John is referencing a previous comment which claimed that V8 did not respect the 'definition order' because doing so could impact memory usage and/or peformance. But the rationale John makes is that since there are two faster engines which DO implement the 'definition order', the memory/performance rationale is bogus. Which makes no sense of course. I would imagine the typical implementation of 'definition order' would trade space over speed, so you could make the property access "fast enough" by spending some additional space to maintain the order as well as the presumably speedy hash access. Complete guess on my part. But to me, it's hard to imagine that implementing 'definition order' isn't going to cost you SOMEWHERE, over not implementing it. I'm cheap, I don't like to pay for things I don't need.

So not only was I surprised by the property ordering, I'm kind of sad because it means JavaScript has some built-in waste for a feature few objects will probably ever need. Kind of like Java's monitors in every object. Ah well.

A few folks pointed out to me that upcoming EcmaScript standards would likely standardize on this ordering behavior. While it's difficult (for me anyway) to track down EcmaScript standard stuff, I did find this set of drafts which seemed ... recent ... and looking at the "23 Feb 2009" version, you can see phrases like "An ECMAScript object is an unordered collection of properties" (page 14) have been changed to "An ECMAScript object is a collection of properties". Hardly a ringing endorsement of defined property ordering, but a step in that direction, no doubt.

So, I guess change is coming. Next question, how can we make use of this?

One thought is with JSON. Typically with JSON you think of object definitions with key/value properties, all defined "at once". Meaning things like "streaming" JSON objects don't really make sense. Only now, maybe it kinda does. Or you could do something like add a property to an object first, called something like "__type__" which would provide some shape information, which a serializer could make use of, because it would see that before other properties.

That's nice. And is fairly logical. But the memory/performance impact will probably always bug me.