Webby thoughts, most about around interesting applications of ecmascript in relation to other open web standards. I live in Mountain View, California, and spend some of my spare time co-maintaining Greasemonkey together with Anthony Lieuallen.

2006-03-09

This morning I started out looking for bits on how to put FireBug to best use, cutting needless pain and labour out of javascript web development. It's a well crafted tool by Joe Hewitt (of Document Inspector fame), which I missed by a few moments last time I browsed Firefox extensions.

To the naked eye, FireBug is first and foremost as visually tidy and to the point as typical Mac appliances, neatly concealing the power it packs, rather than packing its interface with featuritis. You get one console view per window, with just the errors, warnings and XMLHttpRequests related to it, initially hidden behind a green (prior to the first encountered error condition) checkmark in the status panel, or a red one reporting the number of errors registered. Click it, to see the errors, as in the common Firefox error console (formerly named "javascript console"). Or maybe somewhat tidier. Click an erring file name/line number, and see the culprit open up in a new window, focused on the line.

Curious about XMLHttpRequest traffic? Each request gets a line of its own, where you can quickly peek at sent data, received data, and even browse through the properties of the XMLHttpRequest object, a mere click away. Great for a no-effort in-depth view of AJAX applications' chatter with the host server.

And finally, the console command-line:ish input field, where you can instantly apply javascript to the live page, as with Jesse Ruderman's javascript shell.

This bit was what I had hoped to get some more input on, as I had observed this tiny peculiarity: while the current scope is the window object, there is some pollution in the unqualified namespace -- the $ function, for instance, is not the window.$ function (even when defined), but what appears to be some code internal to FireBug:

Unfortunately it doesn't work in this context though, so it is probably an unintentional bug that this ever got exposed in the first place.

But imagine the splendour of having a drop-in Mochikit, or Dojo, or your own favourite unobtrusive javascript framework, instantly accessable for live debugging of any page, regardless of page prerequisites, right in this console. ("Unobtrusive", because something like Prototype that affects the page universe would most likely add more debugging confusion than convenience, seriously breaking WYSIWYG.) A possibility I'd love to see in coming versions.

This morning I started out looking for bits on how to put FireBug to best use, cutting needless pain and labour out of javascript web development. It's a well crafted tool by Joe Hewitt (of Document Inspector fame), which I missed by a few moments last time I browsed Firefox extensions.

To the naked eye, FireBug is first and foremost as visually tidy and to the point as typical Mac appliances, neatly concealing the power it packs, rather than packing its interface with featuritis. You get one console view per window, with just the errors, warnings and XMLHttpRequests related to it, initially hidden behind a green (prior to the first encountered error condition) checkmark in the status panel, or a red one reporting the number of errors registered. Click it, to see the errors, as in the common Firefox error console (formerly named "javascript console"). Or maybe somewhat tidier. Click an erring file name/line number, and see the culprit open up in a new window, focused on the line.

Curious about XMLHttpRequest traffic? Each request gets a line of its own, where you can quickly peek at sent data, received data, and even browse through the properties of the XMLHttpRequest object, a mere click away. Great for a no-effort in-depth view of AJAX applications' chatter with the host server.

And finally, the console command-line:ish input field, where you can instantly apply javascript to the live page, as with Jesse Ruderman's javascript shell.

This bit was what I had hoped to get some more input on, as I had observed this tiny peculiarity: while the current scope is the window object, there is some pollution in the unqualified namespace -- the $ function, for instance, is not the window.$ function (even when defined), but what appears to be some code internal to FireBug:

Unfortunately it doesn't work in this context though, so it is probably an unintentional bug that this ever got exposed in the first place.

But imagine the splendour of having a drop-in Mochikit, or Dojo, or your own favourite unobtrusive javascript framework, instantly accessable for live debugging of any page, regardless of page prerequisites, right in this console. ("Unobtrusive", because something like Prototype that affects the page universe would most likely add more debugging confusion than convenience, seriously breaking WYSIWYG.) A possibility I'd love to see in coming versions.