blogZero

There used to be a lot of talk about browser wars (both old ones and new), but now days it seems the race is on to see who can develop the fastest JavaScript engine. Not surprising given the explosive growth in front-end development, and JavaScript frameworks and effects libraries. Oh, and a little thing called Ajax. So I spent some time researching and evaluating the current, and future, state of JavaScript implementations and these are my findings.

Evaluation Parameters

Before I get into what's on the horizon, I took the time to evaluate the relative performance of JavaScript in four current browsers. I'll be using the WebKit SunSpider JavaScript benchmarking tool on my Dell XP Pro laptop with the latest Service Packs installed. Internet Explorer is not in the mix because, first of all I can't stand the browser, but mostly because it would likely be crushed by the other competitors—listed below by product, version, vendor, and JavaScript engine:

• Firefox v3.0.3 (Mozilla) (SpiderMonkey)
• Safari v3.1.2 (Apple) (SquirrelFish)
• Chrome v0.3.154.9 (beta) (Google) (V8)
• Opera v9.62 (Opera) (Presto)

To level the playing field, each test was performed after a fresh restart with no other foreground applications running. Of the four, Firefox was the most heavily loaded, at least in terms of the number of extensions/plugins installed. I'm not sure if that would have an impact on the results or not. In all cases there were no other tabs open to skew the results (Google mail leaps to mind).

Firefox

 RESULTS (means and 95% confidence intervals)
-------------------------------------------------
Total:                 6506.0ms +/- 1.1%
-------------------------------------------------

 3d:                    693.6ms +/- 2.0%
   cube:                264.2ms +/- 3.6%
   morph:               200.0ms +/- 2.6%
   raytrace:            229.4ms +/- 1.6%

 access:                997.4ms +/- 1.2%
   binary-trees:        152.2ms +/- 3.0%
   fannkuch:            473.4ms +/- 0.6%
   nbody:               236.8ms +/- 3.3%
   nsieve:              135.0ms +/- 4.5%

 bitops:                789.8ms +/- 3.2%
   3bit-bits-in-byte:   186.4ms +/- 4.5%
   bits-in-byte:        212.0ms +/- 0.6%
   bitwise-and:         151.0ms +/- 0.8%
   nsieve-bits:         240.4ms +/- 7.6%

 controlflow:           166.6ms +/- 6.5%
   recursive:           166.6ms +/- 6.5%

 crypto:                494.8ms +/- 1.7%
   aes:                 174.2ms +/- 1.3%
   md5:                 160.2ms +/- 2.1%
   sha1:                160.4ms +/- 3.1%

 date:                  571.4ms +/- 4.5%
   format-tofte:        357.4ms +/- 6.6%
   format-xparb:        214.0ms +/- 7.8%

 math:                  742.0ms +/- 1.9%
   cordic:              351.2ms +/- 1.8%
   partial-sums:        218.4ms +/- 5.5%
   spectral-norm:       172.4ms +/- 1.1%

 regexp:                508.6ms +/- 7.1%
   dna:                 508.6ms +/- 7.1%

 string:               1541.8ms +/- 0.4%
   base64:              176.4ms +/- 3.5%
   fasta:               381.6ms +/- 1.6%
   tagcloud:            296.0ms +/- 3.4%
   unpack-code:         476.0ms +/- 1.3%
   validate-input:      211.8ms +/- 4.8%

Safari

 RESULTS (means and 95% confidence intervals)
-------------------------------------------------
Total:                 6428.2ms +/- 1.1%
-------------------------------------------------

 3d:                    745.0ms +/- 1.9%
   cube:                240.2ms +/- 3.7%
   morph:               258.4ms +/- 3.9%
   raytrace:            246.4ms +/- 2.7%

 access:                977.0ms +/- 2.1%
   binary-trees:        132.0ms +/- 4.2%
   fannkuch:            474.8ms +/- 2.4%
   nbody:               242.2ms +/- 5.6%
   nsieve:              128.0ms +/- 8.1%

 bitops:                782.8ms +/- 2.1%
   3bit-bits-in-byte:   120.0ms +/- 0.0%
   bits-in-byte:        176.0ms +/- 3.9%
   bitwise-and:         292.4ms +/- 3.6%
   nsieve-bits:         194.4ms +/- 3.6%

 controlflow:           154.2ms +/- 4.3%
   recursive:           154.2ms +/- 4.3%

 crypto:                442.8ms +/- 3.0%
   aes:                 164.2ms +/- 6.7%
   md5:                 136.2ms +/- 5.2%
   sha1:                142.4ms +/- 4.2%

 date:                  624.8ms +/- 1.1%
   format-tofte:        262.0ms +/- 2.1%
   format-xparb:        362.8ms +/- 1.6%

 math:                  811.4ms +/- 2.9%
   cordic:              322.6ms +/- 3.3%
   partial-sums:        330.2ms +/- 4.5%
   spectral-norm:       158.6ms +/- 3.8%

 regexp:                520.8ms +/- 0.1%
   dna:                 520.8ms +/- 0.1%

 string:               1369.4ms +/- 6.9%
   base64:              184.0ms +/- 3.7%
   fasta:               328.2ms +/- 3.1%
   tagcloud:            314.4ms +/- 30.2%
   unpack-code:         268.6ms +/- 4.0%
   validate-input:      274.2ms +/- 2.4%

Chrome

 RESULTS (means and 95% confidence intervals)
-------------------------------------------------
Total:                2697.4ms +/- 2.6%
-------------------------------------------------
 3d:                   237.8ms +/- 12.9%
   cube:                53.8ms +/- 9.3%
   morph:              120.6ms +/- 24.5%
   raytrace:            63.4ms +/- 3.0%

 access:               154.6ms +/- 6.0%
   binary-trees:        10.8ms +/- 18.9%
   fannkuch:            54.4ms +/- 3.5%
   nbody:               54.0ms +/- 9.4%
   nsieve:              35.4ms +/- 7.7%

 bitops:               119.8ms +/- 5.6%
   3bit-bits-in-byte:    9.8ms +/- 5.7%
   bits-in-byte:        18.8ms +/- 7.2%
   bitwise-and:         37.4ms +/- 3.8%
   nsieve-bits:         53.8ms +/- 11.1%

 controlflow:            6.8ms +/- 8.2%
   recursive:            6.8ms +/- 8.2%

 crypto:                96.8ms +/- 4.4%
   aes:                 33.8ms +/- 9.9%
   md5:                 32.4ms +/- 3.4%
   sha1:                30.6ms +/- 2.2%

 date:                 621.6ms +/- 2.7%
   format-tofte:       264.8ms +/- 6.5%
   format-xparb:       356.8ms +/- 1.8%

 math:                 198.4ms +/- 5.3%
   cordic:             105.2ms +/- 10.6%
   partial-sums:        67.2ms +/- 5.1%
   spectral-norm:       26.0ms +/- 3.4%

 regexp:               547.4ms +/- 1.7%
   dna:                547.4ms +/- 1.7%

 string:               714.2ms +/- 2.2%
   base64:              73.0ms +/- 13.6%
   fasta:               99.8ms +/- 2.8%
   tagcloud:           188.0ms +/- 3.7%
   unpack-code:        246.0ms +/- 1.2%
   validate-input:     107.4ms +/- 3.0%

Opera

 RESULTS (means and 95% confidence intervals)
-------------------------------------------------
Total:                 7536.2ms +/- 1.2%
-------------------------------------------------
 3d:                    815.6ms +/- 2.7%
   cube:                254.4ms +/- 2.5%
   morph:               302.6ms +/- 5.5%
   raytrace:            258.6ms +/- 2.3%

 access:               1160.4ms +/- 0.8%
   binary-trees:         82.4ms +/- 7.3%
   fannkuch:            568.8ms +/- 1.0%
   nbody:               314.6ms +/- 1.9%
   nsieve:              194.6ms +/- 3.5%

 bitops:                987.2ms +/- 10.8%
   3bit-bits-in-byte:   116.2ms +/- 5.6%
   bits-in-byte:        238.2ms +/- 44.3%
   bitwise-and:         378.6ms +/- 1.4%
   nsieve-bits:         254.2ms +/- 2.6%

 controlflow:            98.2ms +/- 10.3%
   recursive:            98.2ms +/- 10.3%

 crypto:                454.6ms +/- 2.8%
   aes:                 214.2ms +/- 5.5%
   md5:                 120.2ms +/- 0.5%
   sha1:                120.2ms +/- 0.5%

 date:                  551.0ms +/- 2.9%
   format-tofte:        290.6ms +/- 5.3%
   format-xparb:        260.4ms +/- 0.3%

 math:                  638.6ms +/- 3.1%
   cordic:              278.2ms +/- 5.8%
   partial-sums:        206.2ms +/- 3.4%
   spectral-norm:       154.2ms +/- 4.3%

 regexp:                871.6ms +/- 2.5%
   dna:                 871.6ms +/- 2.5%

 string:               1959.0ms +/- 1.0%
   base64:              200.4ms +/- 0.3%
   fasta:               392.6ms +/- 1.3%
   tagcloud:            390.6ms +/- 2.4%
   unpack-code:         765.0ms +/- 0.9%
   validate-input:      210.4ms +/- 4.2%

Findings

Ranked from fastest to slowest overall:

1. Chrome — 2697.4ms
2. Safari — 6428.2ms
3. Firefox — 6506.0ms
4. Opera — 7536.2ms

Now I'm not a statistician, but Safari and Firefox yielded very similar results in the middle ground, while Chrome was the clear winner with Opera at the bottom (surprising, given the browser's reputation for performance). SunSpider has a nice feature that allows you to compare two result sets. The difference from fastest to slowest was a staggering 279% speed increase in Chrome over Opera. Of course a lot depends on what you're using JavaScript for, hence the breakdown into categories and different operations within those categories. If you enjoy pouring over raw data, by all means have at it.

On the Horizon

Over the past several months we've seen all manner of announcements and articles about JavaScript performance improvements and what to expect when this research and development makes its way into the mainstream. We've learned about trace trees, JIT compilers, direct-threaded, bytecode optimizers, and so on. Mozilla, for example, plans to roll out it's TraceMonkey engine with the release of Firefox 3.1. For the impatient, you can grab a copy of the 3.1 nightly builds and enable TraceMonkey now if you want to play with it or do your own testing. One can only speculate on how Google and Opera will respond to these latest developments.

Related Reading

• TraceMonkey Update (Brendan Eich)
• The Birth of a Faster Monkey (Mike Shaver)
• TraceMonkey (John Resig)
• Extreme JavaScript Performance (Ars Technica)
• SquirrelFish has Landed (Cameron Zwarich)

Joe Hewitt may be a lesser known member of the original three Firefox cast, but among DOM and JavaScript developers, his work is legendary. In a later Power Tools installment, I will cover in more detail the DOM Inspector, for which he is perhaps better known. At least until recently. This article focuses on FireBug, which Joe has been working on continuously of late (among other endeavors) and what he ultimately considers to be a DOM Inspector replacement.

The latest version of FireBug was released September 12th, 2008.

What in the hell is a FireBug?

I won't get into entomology—which ironically in Greek means "that which is cut in pieces"—although there really is such a thing as a firebug. The extension, on the other hand, is designed to make the Web developer's job a whole lot more productive. With it you can inspect and debug your markup, stylesheets, JavaScript, and even keep an eye on asynchronous XHR object calls back to your server.

Unlike the DOM Inspector, FireBug normally runs in a horizontal console (although you can open it in a separate browser window) underneath the document's rendered view. A statusbar icon indicates if there are any problems with the current page, which can indicate any number of conditions including errors, warnings and results from:

• JavaScript
• CSS
• XML
• XMLHttpRequest (aka XHR or Ajax)
• Chrome

and even problems encountered from remote domains—which can be the source of massive numbers of errors (I'll leave it to Joe to name names). Thankfully you can suppress these messages, or disable FireBug entirely for certain domains, through the options menu.

Almost every object in the FireBug interface is actually a hyperlink. Elements in the source view can be expanded or collapsed and your current XPath is displayed as you explore the document structure. Like the browser itself, views are toggled through a tabbed interface, which include Console, HTML, CSS, Script, DOM, and Net. Each tab has one or more sub-functions associated with that feature.

By using FireBug, you will quickly learn just how much is going on behind the scenes of even the simplest Web page.

Power Tools

• console.log()

Forget about using alert() to test or debug your scripts. By adding console object logging to your code you can pinpoint exactly what is going on, and even restrict messages according to different levels of severity including: informative, debug, warnings, or errors.

The console object also allows you to make assertions to more deeply test your code as well as performing stack traces, time sections of code, and log the number of times a function is called and has been executed.

All of the console logging methods can format strings using patterns similar to the C stdio printf() family of functions.

Command Line Functions

For command line junkies like me, console mode gives you access to a wealth of query and history/editing features you're probably already familiar with. Even more powerful are the following predefined shorthand functions:

• $("id") - A shortcut for document.getElementById().
• $$("css") - Returns an array of elements that match a CSS selector.
• $x("xpath") - Returns an array of elements that match an XPath selector.
• $0 - Variable containing the most recently inspected object.
• $1 - Variable containing the next most recently inspected object.
• $n(N) - Returns the Nth most recently inspected object.
• inspect(object) - Displays an object in the DOM Inspector.
• dir(object) - Returns an array of property/method names on an object (Python anyone?)
• clear() - Clears the console.

>>> inspect(document)

is a good place to get started.

CSS Quick Search

While in Inspect mode, you can use the quick search box to locate any element by entering a CSS selector. FireBug will display all matching elements in the console view, which you can then expand to view more details or switch tabs to explore the stylesheet that defines the rules for each element, the computed propeties and layout/display attributes, JavaScript events that are attached to the element, and even the gory details of DOM for the selected item.

You can also use quick search to match JavaScript events.

In the future, Joe plans on adding XPath search as well as plain text. For those in a hurry, you can try the getElementsBySelector() JavaScript function, which uses the Firefox XPath API to translate CSS selectors to XPath making them a lot faster than searching the DOM directly.

FireBug 1.2

Some of this material is a bit dated. For the latest on FireBug, visit the new Get FireBug Web site and in particular the "Learn more" feature links on the home page and the documentation section.

Prototype version 1.5 has just been released and includes many enhancements and bug fixes. Best of all, excellent online API documentation. For more information on the latest version, visit the Prototype blog.

Joe Hewitt has announced the final release of FireBug 1.0. Rather than go into all the details about new features and enhancements here, I'm going to refer you to the Yahoo! User Interface Blog where you can view a lengthy video featuring Joe as he demos the new version. Joe has put an enormous amount of work into this extension, if you use it regularly and it saves you time and frustration, then consider helping out with a donation.

JavaScript development just keeps getting more efficient and powerful!

Rather than manually installing either the IE7 or Firefox 2 upgrades, I thought I'd wait and see which one initiated the installation first, through an auto-update. Microsoft won this battle (I'm still waiting on Mozilla but not the least bit concerned about it). However, and this is typical for Microsoft, the installation was anything but convenient. Since the browser is so closely tied to the core OS, it took something on the order of 20 minutes and several reboots to finish.

I suspect the Firefox upgrade will be relatively painless, based on past experience. The only thing you have to do typically is restart is the browser itself, which makes perfect sense. If anything, I may have some issues with extensions that are no longer "compatible" and will be disabled after installation. Several of my favorite extensions will no longer be necessary anyway, as Firefox 2 now has the same functionality built-in.

While I'm on the topic of Microsoft, am I the only developer who's jaw dropped in amazement when they heard that Zend is now working with them to improve the stability and performance of PHP running under IIS? As far as I can tell, this boils down to a port of FastCGI as an add-on to the server. I've never used Windows on the server-side, and you couldn't pay me six figures to use IIS. Perhaps Microsoft is following IBM's lead in recognizing and supporting the role of open-source.

Over the years I've tested many so-called Web server (log file) stats packages, including Webalizer, AWStats, and lately, a slick remote JavaScript solution from Google—better known as Analytics.

The results? My visitors are me. Whoa, what the hell does that mean (and why should it come as no surprise)?

The typical profile of a visitor to this site is:

• Running XP
• Has a screen resolution of at least 1024x768
• At 32-bit color depth
• Their browser is Firefox
• Speaks English
• Is on a broadband connection
• They have JavaScript, Flash, etc. enabled

The rest fall off quickly into the long tail. And even though I've taken pains to accommodate them, I no longer worry too much about the scant 2 hits from a person on a Sun workstation with a browser that is as old as the hills.

I would probably be more concerned if I got millions of pageviews a day, but at some point you have to say to yourself, is it really worth the effort? Why should I bust my balls for the few people that are too lazy to educate themselves and install a decent browser?

After all, this site is geared for Web developers and if they are still running IE6 on Windows 98 with a dial-up connection (or whatever), then they need to wake up and smell the coffee.

The past month has seen a fair share of rumors flying around about AdSense revenue generated by the Firefox Search Bar—when the default Google search engine is used of course. In January, Blake Ross published his first book, Firefox For Dummies. If he decides to write another one, would this be the title?

This brilliant piece of humor and artwork was created by designer Jamey Boje of graphicsguru.com.

As far as the grapevine goes, you can speculate all you want and total dollar amounts are irrelevant. The hardworking Mozilla team has brought us some incredible products and they deserve support on all sorts of levels, including financial ones. No organization can compete with the likes of Microsoft without revenue.

If you want to show your support but prefer a more direct approach, head over to the Mozilla Store. They have plenty of cool swag and other stuff. I have a Firefox t-shirt, coffee mug and, if they ever get the Mozilla logo in shirt sizes other than XXL, I will order one of those too.

For more information on Blake Ross, visit his Wikipedia page.

A few days ago an informal poll appeared on the Digital Web news page asking visitors if they are Formally Educated or Self-Taught? I was surprised by the large number of respondants (many of them highly influential developers) stating they are mostly self-taught.

Another prevalent thread running through the comments is the concept of learning by observation, or what I like to call "how'd they do that?" In order to understand a technique, one of the best methods is to study source code. This is easy enough to do with any browser, and Firefox has some extensions that make it even easier. On my own Web site I try to expose as much as possible, including the markup, PHP source code, I also list my CSS and JavaScript files in the sitemap, and so on. These are just niceties, because other than code originating on the server-side (PHP for example), anything delivered to the user-agent is viewable in source form. Unless you're in the obfuscation camp, which I'm not here to discuss (shame on you if you are).

By now you may have heard of Ajax, and the booming trend in dynamic or DOM or client-side scripting that goes along with it. In other words, JavaScript is red-hot right now. If you're just getting into scripting, then this is a damn fine time to be learning by studying the code that drives all this stuff. It's also a fine time to be learning JavaScript because its reputation as a toy language with many poor examples is quickly being replaced by a new-found respect and clean, structured code.

As far as JavaScript code goes, there are a couple of different sources you're likely to run into. Embedded JavaScript can be found right in the markup. This is still almost as common as it is a bad practice. So there you are, back to viewing the page markup. Often this practice is made even worse by code that is disorganized and dispersed all over the place. There is also inline JavaScript, most often used to fire on certain events such as onclick, but I'm not going to get into that here. Likewise for so-called "javascript:" protocol URLs, such as those used by bookmarklets.

A better solution is to use the src attribute of the <script> element to include external libraries of code. Some developers claim this can cause the page to load more slowly since it involves an extra HTTP GET request for each included JavaScript source file. In my opinion modularity, code maintenance and browser caching of the external scripts easily trumps these concerns.

So once you land on that page with the fancy JavaScript effects, what is the best way to study the techniques being used? One method is to open the source of the page, locate the code embedded in it, or in the case of external source, copy the URL to the file and make a separate request with your browser. Using this rather tedious method for external code with Firefox and most other browsers will result in the code being displayed in a window as plain text, although IE has a nasty habit of prompting you to download the file rather than simply displaying it.

A more elegant solution is to use JSView, a Firefox extension which will open up separate view-source windows for any or all external JavaScript files referenced by the current page (it will do the same thing for external CSS). I find this method acceptable if I only want to look at a particular file, and it sure beats hunting through the markup, copying (and possibly having to modify "../.." paths) then pasting the URL into the address bar of a another tab or window so you can continue to view and test the rendered page.

But this method only works for external source code. Some pages use a mixture of external files and embedded code. In these cases, the all-powerful Web Developer extension really shines. From the Information menu, select "View Javascript" and the extension opens a new tab with all the JavaScript from the current page concatenated into one view. Code from external files are labeled as such with links to the files, and embedded JavaScript is labeled as "Inline Script" referencing the document that defined it. The code appears in source-order, or in other words in exactly the same sequence as it is appears in the markup.

But source order is not important to the JavaScript interpreter embedded in your Web browser. It simply builds a collection of objects after receiving and parsing each form of source code, and then waits for some event to fire that will trigger the intended behavior. If you think in these terms, which I recommend, then Steve Chipman's JavaScript Object Tree favelet/bookmarket is the way to go. To use it, simply drag a copy of the link to your bookmarks toolbar, then on the page you want to study click the link. A new <div> element appears overlaying the top portion of the document and in it you will find a collapsed tree-view of every object type defined by that page. Object types include functions, objects (arrays, dates, etc.), strings, numbers, and so on. To expand an object type into a list of its members, just click on it. To view the value of an object, which in the case of a function is its source code, just click on the item by name. You can easily collapse parts of the tree in the same manner.

Another really handy favelet is Shaun Inman's View Rendered Source, which also overlays the current document with source code, but not JavaScript code. Rather, it displays the browser's internal view of the markup after any changes are made to the DOM. For example, if a script is using Ajax to insert new elements into the document tree and you want to observe the results, then the script will give you a before and after snapshot of the markup.

Remember that observation and studying working examples are powerful ways to learn how Web software is built, and a great way to improve your skills. Whether you are a new or a seasoned JavaScript developer, if you plan on studying code in the wild then Firefox and its many extensions, and any number of other tools (I'm just scratching the surface here) are the way to go.

If you want to get really fancy with your Site Info Bookmarks Toolbar Folder, you can add favicons to each link. I happen to think this not only improves the visual appeal of the list, it's also a mnemonic aid making it that much easier to pick out the one you're after.

To get started you'll first need to install the Favicon Picker Firefox extension (for Firefox versions prior to 1.5, go here). Since you'll need to have local copies of the icons in order to install them, you'll want a quick way to grab them from each site. I used my Fetch Favicon script to extract them from each URL (you should notice this tool is now on the list of Site Info links, more on that in a sec). Once you fetch the icon, simply drag it out of the browser window and drop it onto your desktop.

In some cases the sites either had no icon, or I had a better one to work with. For more help on creating icons, visit Favicon Tools. If there is enough interest, I may provide a zip file with all the icons in it, or add them to the permanent (and growing) list of Site Info Bookmarks. I'm also investigating a way to save a backup of the Site Info folder, icons and all, and providing the archive to my visitors so they can simply install the whole shebang locally without having to go through all of this trouble.

Until then, the easiest way to add favicons to the list is to save the images temporarily to your desktop and then open the Site Info folder and right click on each corresponding link. From the context menu select "Properties" and after the dialog box opens you should notice a new control group labeled "Icon." Press the "Browse..." button to locate the icon file on your desktop, then click on it to select the icon and return to the Properties dialog. Once you're satisfied you have the right one, click the "OK" button to save. When you're done with all of them, you should have a fancy new list similar to the one on the right.

Most site owners and bloggers are obsessed with checking their traffic stats. I suppose I'm no exception. Frankly, I'm getting my ass kicked by many of the places I haunt. I'm a proud member of the Long Tail club. Hey, the world needs D-listers too.

This led to another pastime—I found myself spending a considerable amount of it investigating other people's sites. How much traffic do they get? Who links to them? Of the folks who bookmark them, what other sites are they bookmarking using the same tags? Who blogs about them? Are they listed on DMOZ? And so on...

Being a lazy sort, I found myself filling up my bookmarks toolbar with one JavaScript link (aka favlet or bookmarklet) after another, until they finally spilled off the right side of the toolbar into one of those auto-generated dropdowns. At that point it was pretty obvious a pattern was emerging, so I created a folder, cleaned up the list, and stuck them all in there for easy access.

Today I figured I can't be alone in this pursuit, so I thought I'd share the list and show you how to create a Site Info folder of your own. Afterwards, from any site you're visiting, you can access all of them lickity-click. These instructions are for Firefox, although I suppose you could set-up something similar with other browsers. I'll leave that to you.

First, create the folder: right click on your bookmarks toolbar and select "New Folder..." You can name it whatever you want, Site Info made sense me. Next, one-by-one from the following list, drag and drop these links into the folder. You can always delete some of them later if you don't find them useful. Or dump the whole damn folder if you want to.

• Alexa Traffic Report
• Bloglines Citations
• Complete Whois
• Del.icio.us URL
• Find Similar Sites
• Google Translate
• Google URL Info
• IceRocket Blog Search
• Netcraft Site Report
• Open Directory Search
• Tailrank Memetrack
• Technorati Cosmos
• URLTrends Report
• Wayback Machine

When you're done, you should have something similar to this:

And there you go, a whole plethora of information about any site, just by visiting it and selecting from the list. I've seen extensions that are similar in concept, but to be honest the last thing I need is another one chewing up resources, or adding any more context menu options for that matter. This is a nice solution, and you're not at the mercy of the extension author when it comes to what information you want access to.

To understand how the links work, just study the source. Most of them use simple encodeURIComponent(location) function calls tacked onto the end of another URI. Others, like the link to search ODP are a little more complicated, in that case because you only want to send the top-level domain to the search script. Another quick way to study these links is to right click on one of them from your Site Info folder and select "Properties..."

I actually built the list using PHP, so if you want a closer inspection without digging through all the markup created by this blog software then visit this prototype page. If I add any more, that's where you'll find them anyway. And that reminds me, if anyone out there has any good suggestions, then by all means don't be shy. A good place to poke around and learn more is Jesse Ruderman's bookmarklets list.

That's it, now you can go back to checking your stats...

The first developer preview release of Firefox 2.0, codenamed Bon Echo, is now available for testing purposes only. You should probably avoid installing it on a production desktop client if you intend to continue using version 1.5.0.1 (or earlier) and want to save your existing environment.

Bon Echo Alpha 1, the first development milestone of Mozilla Firefox 2 aimed at developers and testers, is now available for download from ftp.mozilla.org. Bon Echo Alpha 1 is the first of many developer milestones on the path to Firefox 2. This milestone is focused on testing the backend infrastructure supporting the new Places functionality.

Source: mozillaZine.

New Features

• Changes to tabbed browsing behavior
• New data storage layer for bookmarks and history using SQLite
• Extended search plugin format
• Updates to the extension system to provide enhanced security and localization
• Support for SVG text using svg:textPath

Supported Platforms

• Windows (XP Recommended)
• Linux (tested on Linux Fedora Core 4)
• Mac OS X

A list of notable bug fixes is forthcoming.

If you feel like living on the bleeding edge, or want to help out by evaluating one of the first builds, jump in there and give it a try.