I typically don't write about most performance analysis tools because, frankly, most of them are quite bland and don't provide very interesting information or analysis. dynaTrace provides some information that I've never seen before - in any tool on any browser.

dynaTrace Ajax works by sticking low-level instrumentation into Internet Explorer when it launches, capturing any activity that occurs - and I mean virtually any activity that you can imagine. I noticed very little slow down when running the browser in tracing mode (although it's sometimes hard to tell, considering the browser). However all of the tracing is recorded and saved for later, making it easy to record sessions for later analysis.

Above is the result of a recorded session, logging in to Gmail, reading a mail, and logging back out again. All aspects of the session are saved: Network requests, JavaScript source, all DOM events, etc. I had a hard time finding information that wasn't saved by the tool.

This is the full timeline view of loading a single the Gmail inbox. All network traffic, JavaScript parsing and execution, browser events, and CPU load can be seen.

You can select a segment of the timeline and get a view that looks like the following:

In the above you can see a clearer picture of the exact interactions happening. A phenomenal amount of inline JavaScript execution followed by page layout calculation coinciding with loading of some data over the network. You can mouse over the individual blocks on the timeline to get more information (such as if the JavaScript execute was the result of a timer or what Ajax requests were firing to cause the network traffic). Additionally you can click the blocks to dive in and take a deeper view of the trace.

Digging in to the execution of an XMLHttpRequest on a page we get to see some of the full execution stack trace - and this is where the tools starts to become really interesting. The tool is capable of tracing across JavaScript, through the native XMLHttpRequest, through the network request, and back to the handler that fires when the request is done. This is phenomenal. This is the first tool that I've seen that's capable of tracing through native methods to give you a picture of what activity triggers which actions and the complete ramifications of what happens (in both CPU usage and execution time).

Note that in the stack trace view you can click any piece of code and see its location anywhere inside the source code (and this even works after you've already closed the browser and have moved on - all source code is saved for later analysis).

While it's interesting to trace through code to look for problems the bigger question is usually: Where are slowdowns occurring? This is where the HotPath view comes into play:

This looks like a typical execution count view - like the one that you might see in Internet Explorer's built in tool or in Firebug - except for one important point: This view includes JavaScript parsing and layout rendering times. This is huge! No other tool provides information on how long it takes to parse all the JavaScript code on your site or how long it takes to do all the rendering. Clicking those entries allows you to see a breakdown of every time JavaScript was parsed or a layout was rendered - from which you can trace back to get even more information about what caused those actions. I don't want to seem too excited but I really am, this is just an incredible amount of information - and it gets even better:

Not only can you see the execution count for your defined JavaScript methods but you can also see execution time for the built-in DOM methods! Wondering what native method calls are slowing down your application? Wonder no more. From the HotSpot view you can filter by DOM or regular JavaScript and see exactly where execution time is going and what methods are so slow.

dynaTrace provides an additional view, called PurePath that attempts to figure out problematic scripts:

Just another way to try and get a full picture as to where your application is slowing down and what may be causing the problem.

In all I'm hugely impressed with this (free!) tool and am already using it to do more testing and performance analysis on my code. I don't think any browser has ever had a tool capable of this type of analysis, let alone Internet Explorer 6 and 7, which are still a very real part of any developer's workflow.

I chatted with some of the dynaTrace guys and asked them to add in memory profiling and to support more browsers. If they can provide this quality of instrumentation for CPU and execution time I hope they can do the same for memory usage, the next un-tapped realm of JavaScript performance analysis.

For the jQuery project we've run all of our community discussions through Google Group mailing lists for the past three years. At this moment the main jQuery group is the second most popular programming group (next to Android developers) clocking in at over 21,000 members. We also have the jQuery Dev and jQuery UI groups. The main jQuery group averages around 83-143 messages per day. I also use Google Groups for discussion on a number of my other projects (Processing.js, Env.js, Sizzle.js, and TestSwarm).

This post isn't so much about the usefulness of mailing lists as a discussion medium, it's the complete failure of Google Groups as an adequate purveyor of public discussion software. For the jQuery project we're already in the process of moving the full discussion area to a forum that we control. We should have it set up, and everything moved over, within the next month or two.

There is one area in which Google Groups continues to shine: Private, or restricted, mailing list discussions. However any attempts at using it for a public discussion medium are completely futile.

The primary problem with Google Groups boils down to a systemic failure to contain and manage spam. Only a bottom-up overhaul of the Google Groups system would be able to fix the problems that every Google Group faces.

To better illustrate the problem, let's step through the common experience of running a Google Group.

The Beginning

When you create a public group everything will go well for a couple days, at most. Without fail an onslaught of spam will start to come through your group - I've even seen it happen within the first day. It happens to every group and doesn't matter how well you advertise it (or try to hide it). After having watched Google Groups for as long as I have I can only assume that there exists no spam filtering whatsoever. Or, if there is any, it's the most grossly incompetent spam filter I've ever seen.

When these spam messages start to come to your group a couple things will happen. First, you may not even notice the spams coming through. Since you're likely reading the list in a competent email client (such as Gmail) it'll detect the messages and dump them into your personal spam folder. Don't be surprised if you visit your group and see a pile of spammy messages sitting there greeting your new visitors.

Most email client spam detection software is smart. It looks for common points of failure and tries to take care of the root problem. One such tactic is to realize that a lot of spam is coming from a single address (like a Google Group) and start to flag most of it as it comes through (regardless of the actual content). The result is that much of your list is being flagged as a false positive. In the case of Gmail people will then start to un-flag the falsely-binned group messages. This works well until the system starts to think that all group messages are ok - and here comes the spam again.

To fight the spam you'll likely start flagging emails as "spam" in the groups interface. This works well (the user is permanently banned and the message deleted) - until a couple hours pass, that is. You'll see the spammer return, with a slightly different username, posting the same exact spam messages. Flagging a user/message as spam does absolutely nothing to train the groups spam detection system (for reasons that aren't entirely clear and only be explained by incompetence).

It's a horrible game of cat and mouse with the spam destroying the quality of your group. It's at this point that you say "enough is enough" and you turn on moderation for your group.

Moderation

Google Group moderation seems like a palatable idea but in practice is aggravating and crippling. To start, it creates a horrible first-participation experience for your users. For example, let's say you go to bed at the same time as someone in Tokyo attempts to post a message to the group; you won't be able to moderate the message through for many hours (and that's assuming that you moderate messages during your work day). While the experience is much worse than instant posting it is par for the course for most moderation systems.

Of course, this would assume that Google Groups actually informs the users that their message has been held in moderation. Looking through the moderation queue you can see users attempting to submit their message over-and-over again, wondering why it isn't working. Eventually they'll just give up in frustration.

In order to combat this you'll typically need to bring on a bunch of people to help with the moderation duties. In the case of the main jQuery and jQuery UI groups we divvy up the moderation based upon the time of day and week (and where the moderator lives). This is incredibly frustrating but still manageable.

This moderation load also assumes that you are able to successfully navigate the abysmal Google Groups moderation user interface. It's a horrible quagmire of radio buttons and un-evenly spaced rows with no visual delineation. I've provided an example of the interface below (BEWARE: Contains Not Safe For Work text).

When you begin moderating all the radio buttons start on the "Ignore" column, it's your duty to move all the messages to the right columns. The "Spam" and "Always Allow" columns were added just recently (thank goodness) - the moderation process use to be much worse.

With a user interface this bad mistakes happen. Sometimes spam accidentally slips through, sometimes users get completely banned. I estimate that this happens about once in every couple hundred messages. With 84-143 messages coming to the main jQuery Google Group every day that means that there'll be at least a few users banned and a few spam coming through every week.

While the occasional spam slipping through is a reality of the web, accidentally banning users is unacceptable - but it does happen, even when you don't mean to. For example, here's a message that I got from a user just today:

I seem to have been banned from the jQuery Google Group for a reason
I'm not aware of.
> The owner of this group has banned you from this group.

Not sure if this is another Groups glitch or not. I can still access
the jQuery UI group, though.
My account is under email: XXXXX@gmail.com

Please advise. Thanks.

Nothing quite like insulting, confusing, and scaring your users, due to a poorly-designed user interface and abysmal spam detection. This is the reality that Google Group owners have to live with on a daily basis.

All of this changed a couple weeks ago.

End Game

The final straw was placed upon my patience with the Google Groups system a few weeks ago. Spammers are now spoofing the email addresses of existing group participants to sneak their messages through. Previously you would've seen a delightful "FREE MOVIE DOWNLOADS" spam from "freemovies123@gmail.com" - but now you'll see it coming from existing group users - or even the group moderators themselves. This cheat completely bypasses the moderation system since the spammers are pretending to be pre-moderated users.

The Google Groups system is completely fooled. The spam message comes in claiming to be from an existing group participant - and according to the Google Groups interface there is no difference. If you click the user's name you'll be taken to a full listing of that user's posts (with the spam messages delightfully interspersed).

For example, here's a user whose email address is being spoofed and an email that was actually sent to Google Groups. Note that the actual email is coming from a .ch domain and not from the actual Gmail server.

The only "cure" to this problem is to watch for a spam message to come through and then force that user into a permanent state of moderation. Of course, you then have to be careful not to bring that user into a "pre-approved" state the next time you clean up the moderation queue. There is no way to keep track of which users should be kept in a always-moderate state and which should skip moderation.

At this very moment my own email address, and the email addresses of most of the jQuery group moderators, are being spoofed by spammers. This means that we (the owner and moderators of the group) have to moderate our own messages before we post, for fear of letting a spoofed spam through. This will likely happen indefinitely since Google Groups has been notoriously slow to fix problems with the site.

On top of all of this, Google Groups actually strips out many of the original spam indicators from the message when it re-broadcasts it to the full list. This means that when the message finally arrives at a user's email client it actually looks like it came from the spoofed user. Since I'm currently being spoofed I've actually had a bunch of my legitimate email end up in spam folders as a result. Having my email address become flagged as a spammer is positively infuriating. The fact that Google Groups is silently sitting by and blindly letting this happen communicates one thing to me: Google Groups is dead, time to move on as quickly as possible.

Moving On

I've completely given up on Google Groups - and I'm not the only one. Feel free to ask any Google Group moderator and I'm certain that you'll only get a sad shake of their head. The situation is completely untenable - which is why the jQuery team is actively working to get all our lists off of Google Groups as quickly as possible.

To give you an idea of the overall level of quality that Google Groups exhibits here is an anecdote: A couple weeks ago the jQuery UI Google Group was completely deleted for no apparent reason. It was gone for the better part of a day before it was restored. The only mechanism for contacting support, even in a situation as serious as that, is to post on a public Google Group. We never received a response from an admin regarding the missing group. Are there backups of group data? Who knows! Forget it, life is too short for the stress and aggravation that Google Groups provides.

While Google Groups provides a mechanism for exporting a CSV members list it provides no way to export the full message archive for a group. With over 120,000 messages tied up in the main jQuery Google Group alone it's going to take some significant work to get everything out and move on. Our only avenue of escape (short of screen scraping the entire Google Group archive) is doing an IMAP dump of my personal Gmail account and extracting all the jQuery group posts from it. I'm sure that experience will be absolutely delightful as well.

Bye Google Groups, you won't be missed.

Nearly the entire jQuery project team had the opportunity to meet for two days prior to the conference and hash a number of things out - figuring out most of the planning for the upcoming year. The core dev team also had the opportunity to meet and work for two days just after the conference. We're much closer to shipping 1.3.3 now (which is likely to become 1.4, with all the new features that're being added).

(Left to Right: Mike Hostetler (Infrastructure), John Resig (Core), Paul Bakaus (UI), Brandon Aaron (Core), Richard D. Worth (UI), and Scott Jehl (UI and Design team)

A full list of the presentations that were given can be found on the events site. All the presentations that I gave can be found below.

Recent Changes to jQuery's Internals

A run-down of all the features and internal changes made in 1.3, 1.3.1, 1.3.2, and 1.3.3/1.4.

Understanding JavaScript Testing

A broad overview of all the different testing solutions that exist for JavaScript and where they might best fit into your full testing solution.

State of jQuery '09

A quick overview of the past year of jQuery and a look towards the upcoming year.

I've been slowly working on a new JavaScript book that covers many of the specifics behind how and why JavaScript libraries are designed they way that they are - titled Secrets of the JavaScript Ninja. I'm still working on the book - I have four chapters left to write - and am hoping to have it completed this year.

Incidentally Manning Publishing is running a special (today only!) offering the ebook version of Secrets of the JavaScript Ninja for 50% off the normal price, if you use the coupon code pop0901. (Note: I've heard that it may also work for the ebook + paperback version of the book.)

A number of excerpts from the book can be found in the site archive. My Learning Advanced JavaScript interactive tutorial is also based upon the contents of the book.

Note: The book is not yet complete, nor has it gone through any proofreading or technical editing - there will be mistakes. Also, yes, I'm aware that the cover of the book has a samurai on it, not a ninja - I'm working with the publisher to rectify this.

I've also been asked if people should buy Pro JavaScript Techniques (my Apress book from 2006) or my upcoming one. I should note that the upcoming one is much more advanced than my previous one - covering much more complicated topics and more about cross-browser development. If you're looking for a good introductory book to JavaScript and the DOM I strongly recommend Nicholas Zakas' Professional JavaScript Developers book.

TestSwarm, the project that I've been working on over the past 6 months, or so, is now open to the public. Mozilla has been very gracious, allowing me to work on this project exclusively. At the beginning of April I moved from my old position as a JavaScript Evangelist on the Mozilla Evangelism team to that of a JavaScript Tool Developer on the new Developer Tools team (whose other major project is Bespin).

For more information on Test Swarm I've written up a detailed explanation of what Test Swarm provides and where it fits into the landscape of JavaScript developer tools.

I've also recorded a screencast walkthrough of the TestSwarm site:

Test Swarm Walkthrough from John Resig on Vimeo.

Additionally, there are two previous posts that I've made on TestSwarm:

• JavaScript Testing Does Not Scale
• Presentation on TestSwarm at JSConf

There are some additional screenshots of Test Swarm in action on Flickr.

More Information:

• Test Swarm Source Code
• Test Swarm Bug Tracker
• Test Swarm Discussion Group
• Test Swarm Twitter Updates

If you're interested in using Test Swarm I strongly recommend reading the project overview first. If you have any further questions please direct them towards the Test Swarm discussion Group.

TestSwarm ended up being a very challenging project to get to an alpha state (and probably will be even more challenging to get to a final release state). Dealing with cross-browser incompatibilities, cross-domain test suite execution, and asynchronous, distributed, client execution has been more than enough to make for a surprisingly difficult project. It's mostly written in PHP and uses MySQL as a back end (allowing it to run in virtually any environment). Patches will absolutely be appreciated.

This project has been a long time coming now, the first inklings started back in 2007. Some of us on the jQuery team were discussing ways to distribute the test suite load to multiple browsers in an automated fashion. Andy Kent came along and proposed a participatory application for testing visual code (such as jQuery UI). We worked on that code base for a while but it didn't get off the ground. Eventually I decided to re-tackle the problem early on in 2009. Even in its rough alpha state we've already been able to make great use of TestSwarm. For example, here's a view of jQuery commits run in TestSwarm:

The vertical axis is SVN commits to jQuery (newer commits at the top), the horizontal axis are all the different browsers that we target. Using TestSwarm we've been able to easily spot regressions and fix them with a minimum amount of hassle (especially since all the results are logged).

And this is only the beginning. There are so many different directions in which Test Swarm can be taken. For example:

• A pastebin-like service where you can drop in code and see the results come back, from many browsers, in real-time.
• IDE integration for sending minor changes out for quick testing.
• Manual testing of user interface code. Pushing manual tests, with instructions, to users for them to walk through.
• Distributing tests to any number of browsers, rather than a specific sub-set. (You could use this to embed a tiny iframe in your site to collect test results from a small sampling of our users.)
• The ability to drive and test browser code or extensions.

And the list goes on. I'm definitely curious to see what directions the community is interested in driving the code base. I've gotten it to a level where it's particularly useful for me and the jQuery team - where should we go from here?

Unfortunately I'm short on time at the moment (trying to launch a project this week) but I have to say, at least, a few words about the hacker and artist _why.

At this moment, _why's online presence appears to be no more. All of his sites and code are gone. This includes, and is not limited to:

• http://twitter.com/_why
• http://github.com/why
• http://whytheluckystiff.net/
• http://poignantguide.net/
• http://hackety.org/
• http://shoooes.net/
• http://hacketyhack.net/
• http://tryruby.hobix.com/

Two conjectures are common at the moment: His account(s) were hacked and sites taken down or he simply decided to delete his online presence. I personally believe that he did this deliberately and with some amount of forethought.

One of the things that's made _why unique amongst programmers is that he has worked in virtual anonymity. Some people knew his name but it was never a focus of his online persona (and, at least, never actively associated with him as a person - I've seen sites that purport to identify him, but they're generally incorrect, and fringe, at best). Even live, giving talks or performing music, he still went by his pseudonym.

Reading through the original discovery thread you can see a full range of emotion regarding his disappearance; Anger, confusion, and sadness.

Personally, I feel a mixture of joy and amazement.

_why, the code he's written, the persona he projected, and the art he produced has been a long-time admiration of mine. Some only see _why's code or writing (Why's Poignant Guide to Ruby, for example - which can still be purchased on Lulu).

I tend to see _why more as an artist. He used a wide variety of mediums for his exploration: Written word, drawings, code, and even music.

Not many know that he released an album to go along with Why's Poignant Guide to Ruby. One of my favorite songs from the album is the one for the second chapter: This Book is Made (of Rabbits and Lemonade).

Nothing can capture the artistic ethos of _why better than the above song.

_why - even in his code - was eccentric, humorous, cute, and whimsical. He relished his ability to express his art and was extremely good at it, at the same time.

Underlying the layer of whimsy that permeated his work there was a more serious tone: expression, simplicity, and education. In all of his code, and writing, he was constantly trying to find ways to bring the art of hacking to more people - to younger people - to simplify the complexities that normally permeate development.

It's never completely clear from his writing, but I like to imagine _why with children. Either as a grade school teacher or with his own children. Finding ways to communicate with them, teach them, and encouraging their imagination and freedom of expression.

Due to his expressive nature I feel like I understand _why, even though I only managed to chat with him once, for a couple minutes, on IRC. I can especially appreciate his anonymity.

In my life I constantly try to keep my work and personal life separate. What _why did with his online persona has been a great inspiration to me. He was successful in having virtually no bleed-over of his personal life (with his family and friends) into his online persona, and likely vice-versa.

People get way too caught up in their work. I like to think that he was able to keep the products of his online persona separate from the rest of his life, treating them as completely distinct entities - the perfect, clear-cut, division between personal life, work, and play.

Seeing the complete deletion of his online persona doesn't terribly surprise me. Back in 2007 _why closed his main blog (RedHanded). That event truly shocked me, but it helped me to better understand him as a person. The blog, even though he had put years of work into it and people strongly identified him with it, was immaterial. It didn't feel like the right place to talk anymore so he moved on to another place, abandoning the old site.

If there's any analogy that I can make about _why, his online persona, and all the works that he's produced over the years it's to the Tibetan Buddhist tradition of the sand mandala.

Sand mandalas are incredibly intricate works of art that take many people many days to construct. They're very expressive, but fragile, works of art.

After a mandala has been constructed - and displayed - it is ceremoniously deconstructed - which is meant "to symbolize the Buddhist doctrinal belief in the transitory nature of material life."

_why's entire online presence and code was presented in the sand mandala that was '_why'. The person behind '_why' simply decided to move on and close that portion of his life.

I've seen a few people ask why he opted to remove his code - why didn't he take his work seriously? (Especially since others have grown to depend upon it.)

Looking at the cumulative work and art of _why it should become painfully obvious: The online presence of _why, and all the code, writing, music, and drawings that've been produced are a mere transitory portion of one person's life. He was constantly moving from project to project, blog to blog. Now he's truly moved on and we should feel joy in having gotten to know him, and his art, over the past couple years.

While this isn't a eulogy for a living person - I fully expect that he's happy and continuing to explore life with his friends and family - it's a eulogy to one portion of one man's life.

I wish I could better express what I feel for _why. Whenever I think of him I think of artistic expression, happiness, and the joy of exploration.

To _why: Thank you for bringing your code and art to us over the past couple years. It's been greatly appreciated, more than you can know. Please continue to enjoy your life and bring your joy and whimsy to others all over the world.

Normally in order to achieve any sort of computation using JavaScript you would need to break your jobs up into tiny chunks and split their execution apart using timers. This is both slow and unimpressive (since you can't actually run anything in parallel - more information on this in How JavaScript Timers Work).

With our current situation in mind, let's dig in to Web Workers.

Web Workers

The Web Worker recommendation is partially based off of the prior work done by the Gears team on their WorkerPool Module. The idea has since grown and been tweaked to become a full recommendation.

A 'worker' is a script that will be loaded and executed in the background. Web Workers provide a way to do this seamlessly, for example:

The above will load the script, located at 'worker.js', and execute it in the background.

There are some HUGE stipulations, though:

1. Workers don't have access to the DOM. No document, getElementById, etc. (The notable exceptions are setTimeout, setInterval, and XMLHttpRequest.)
2. Workers don't have direct access to the 'parent' page.

With these points in mind the big question should be: How do you actually use a worker and what is it useful for?

You use a worker by communicating with it using messages. All browsers support passing in a string message (Firefox 3.5 also supports passing in JSON-compatible objects). This message will be communicated to the worker (the worker can also communicate messages back to the parent page). This is the extent to which communication can occur.

The message passing is done using the postMessage API, working like this:

The Client:

This particular message-passing limitation is in place for a number of reasons: It keeps the child worker running securely (since it can't, blatantly, affect a parent script) and it keeps the parent page thread-safe (having the DOM be thread safe would be a logistical nightmare for browser developers).

Right now Web Workers are implemented by Firefox 3.5 and Safari 4. They've also landed in the latest Chromium nightlies. Most people would balk when hearing this (only two released browsers!) but this shouldn't be a concern. Workers allow you to take a normal piece of computation and highly parallelize it. In this way you can easily have two versions of a script (one that runs in older browsers and one that runs in a worker, if it's available). Newer browsers will just run that much faster.

Some interesting demos have already been created that utilize this new API.

RayTracing

This demo makes use of Canvas to draw out a rendered scene. You'll note that when you turn on the workers the scene is drawn in pieces. This is working by telling a worker to compute a slice of pixels. The worker responds with an array of colors to draw on the Canvas and the parent page changes the canvas. (Note that the worker itself doesn't manipulate the canvas.)

Movement Tracking

(Requires Firefox 3.5. About the demo.) This one uses a number of technologies: The video element, the canvas element, and drawing video frames to a canvas. All of the motion detection it taking place in the background worker (so that the video rendering isn't blocked).

Simulated Annealing

This demo attempts to draw outlines around a series of randomly-placed points using simulated annealing (More information). It also includes an animated PNG (works in Firefox 3.5) that continues to spin even while all the processing is occurring in the background.

Computing with JavaScript Web Workers

The other day Engine Yard started an interesting contest (which is probably over, by the time that you're reading this).

The premise is that they would give you a phrase, which you would take the SHA1 of, and try to find another SHA1-ed string that has the smallest possible hamming distance from the original.

The phrase was posted the other day and developers have been furiously working to find a string that yields a low value.

The current leader is using a series of dedicated GPUs crunching out results at a pace of a couple hundred million per second. Considering the rate at which they're progressing any other implementation will have a hard time catching up.

Of greater interest to me were two pure-JavaScript (1, 2) entrants into the competition - they both run completely in the browser and utilize the user's JavaScript engine to find results. While neither of them have a prayer of overcoming the GPU-powered monsters dominating the pack, they do serve as an interesting realm for exploration.

Reading through the source to both implementations they both utilize nearly-identical tactics for computing results: They execute a batch of results broken up by a timer. I've played around with them in different browsers and have been able to get around 1000-1500 matches/second. Unfortunately they both peg the CPU pretty hard and even with the timer splitting they manage to bog down the user interface.

This sounds like a perfect opportunity to use Web Workers!

I took the Ray C Morgan implementation, stripped out all the UI components and timers, and pushed it in to worker (through which 4 of them are run in parallel). (I submit results back to the original implementation, just in case a good result is found.)

Check out the demo and source:

• SHA1-Crunching Web Worker Demo
• 'Parent' Source
• Worker Source

I ran the old implementation against the new one in the browsers that support Web Workers to arrive at the following results:

How does this implementation work? Digging in to the source of the parent launcher we can see:

To start, we're constructing the worker and listening for any incoming messages. There are three types of messages that can come from the worker: "rate" (a 'ping' from the worker notifying the parent how quickly it's running), "found" (sent back when a new high scoring phrase has been found by the client), and "mybest" (sent when the worker gets a new personal-best high score).

Additionally we can see the initialization data sent to the client in worker.postMessage. Unfortunately we have to pass the data in using a string in order to have it work in all browsers (only Firefox 3.5 supports the ability to pass in a raw JavaScript object).

Looking at the contents of the worker we can see some more, interesting, logic.

The two 'distance' checks take place deep in the computation logic. After a new match has been found it is compared against the existing high scores. If this a sufficiently good-enough the result is sent back to the parent page using postMessage.

The 'stats' function is called periodically, which then reports back the current rate of processing to the parent page.

The 'onmessage' callback listens for the initialization data to come from the parent page - and once it's been received begins processing.

--

In all I found this project to be a lot of fun - a relatively minor amount of code yielded 2-3x faster computation power. If you're doing any computation with JavaScript you should definitely opt to use Web Workers if they're available - the result is both faster and a better experience for the end user.

The script itself is completely standalone (no dependencies) and can be included in any page relatively painlessly. Additionally, since it's just HTML, CSS, and JavaScript, it's completely themeable and customizable to the style of your site. Before explaining how to use it, some demos:

Demos

Simple Style

Vertical Style

How to Use / Installation

Getting the Easy Retweet Button running on your site is painfully easy (ha!).

Step 1: Include the retweet.js file in the <head> of your web site.

(Note: You should place and use a copy from your own site, in case mine ever goes down.)

(Note 2: You DO NOT need a bit.ly account in order to use this script. A working one is provided for you by default.)

Step 2: Add a class of 'retweet' to any anchor that you wish to turn into a Retweet button - or add a link with classes of 'retweet' and 'self' to add a retweet button for the current page.

Retweet link for the current page: (See example at the end of this blog post.)

Retweet link for other page:

Wordpress: If you're using Wordpress you could sculpt a custom button like so, placed in your single.php theme file (although, the above link types should be more than sufficient for most cases):

The script has been tested in Internet Explorer 6-8, Opera 9-10, Safari 3.2-4, Chrome 2, and Firefox 3-3.5. Please write a comment if you encounter any problems.

Configuration and Themeing

There are a few options for the Retweet button that you can use. If you're going to change them you can do so by changing the following properties after you've already loaded the retweet.js file. However, I highly recommend that you download a copy of the retweet.js file, make the changes in the file itself, and simply load that result instead.

RetweetJS.link_text (Default: "Retweet")

You can change this to another value and change the text in all of the Retweet buttons. (Good for handling different languages.)

RetweetJS.count_text (Default: "clicks")

Right now only "clicks" are supported but if you specify "none" it will show no count (and load much faster, as a result).

RetweetJS.prefix (Default: "")

Setting to "RT @jeresig " will add it to the front of the tweets.

RetweetJS.styling (Default: The full CSS used for styling the retweet button.)

You'll probably want to either tweak the CSS from inside the file itself or completely overwrite it and include your own styling elsewhere. The markup for the button is surprisingly simple:

And if you have a vertical-style button the markup is:

RetweetJS.bitly_user
RetweetJS.bitly_key

These default to a dummy account ('retweetjs') that can be used indefinitely. However if you wish to keep track of your own links and add them to your own Bit.ly account then please add in your Bit.ly username and API key (which can be found on your Bit.ly account page). These values should be changed within the retweet.js file itself.

Alternatives

Two alternatives that I know about are the Tweetmeme Button and the Backtype Tweetcount.

Some of the major differences between this script and those are:

• Completely Unobtrusive You can place the script in the <head> of your document instead of inline. The other scripts rely upon document.write() and write out iframes into your document.
• Speed Retweet.js works completely asynchronously, loading data and updating the rendering as it comes in. This means that the buttons won't block your page while they're loading (unlike the other buttons).
• Pure HTML/CSS The result is just pure HTML styled with CSS - you can customize it however you wish, no images are required.
• Number of clicks, not retweets. The number of retweets may be interesting to some but it's a poor indicator of actual traffic. Instead, the number of clicks coming in is shown instead (a much more useful number).
• You control the data All tracking works directly through Bit.ly, not a third party - this means that all the clicks and traffic can be stored straight in your bit.ly account, not some third parties.
• 100% Open Source This script is released under the MIT license and is completely open to modification and redistribution. The full source is available on Github.

If you have any questions regarding the script please feel free to post them her in the comments. If you have any tweaks for the script, please apply them against the source repository. Enjoy!

One of the biggest wins of the HTML 5 recommendation is a detailed specification outlining how parsing of HTML documents should work. For too many years browsers have simply tried to guess and copy what others were doing in hopes that their parser would work well enough to not cause too many problems with HTML markup found in the wild.

While some parts of HTML 5 are certainly more contentious than others - the parsing section is one that is almost universally appreciated by browser vendors. Once browsers start to implement it users will enjoy the improved compatibility, as well.

One of the first implementations of the HTML 5 parsing rules was actually created to power the HTML 5 validator. (If you're interested in testing it out, http://ejohn.org/ should validate as HTML 5.) This particular implementation is in Java, provides SAX and DOM interfaces for use, and is open source.

This is particularly interesting because Henri Sivonen (the author of the validator) just recently landed (Warning: Massive web page) a brand new HTML 5 parsing engine in Gecko, destined for the next version of Firefox.

What's interesting about this particular implementation is that it's actually an automated conversion of Henri's Java HTML 5 parser to C++. This conversion happens automatically and changes will be pushed upstream to the Mozilla codebase.

Normally I would balk at the mention of a wholesale, programmatic, conversion of a Java codebase over to C++ but the results have been very surprising: A 3% boost in pageload performance.

And this is on top of the litany of bug fixes and compliance checks that this code base will be providing. You can examine some of the progress that went into the constructing the patch in the Mozilla bug.

If you're interested in giving the new parser a try (it's doubtful that you'll see many obvious changes - but any help in hunting down bugs would be appreciated) you can download a nightly of Firefox, open about:config, and set html5.enable to true.

If there was ever a time to start playing around with the jump to HTML 5, now would be it. Since HTML 5 is a superset of the features provided by HTML 4 and XHTML 1 it ends up being surprisingly easy to 'upgrade': Just start by swapping out your current (X)HTML Doctype for the HTML 5 Doctype:

<!DOCTYPE html>

From there you can check the site HTML 5 Doctor for additional details on how to get the new HTML 5 elements working in all browsers.

It will be of great help to me if you could quickly fill out the question below. I will release the results of the survey as soon as possible. Thanks!

The poll is now closed. I've received 1853 responses and plan on writing a detailed blog post on the results. Thanks everyone!

More information on the frameworks listed above:

• JSUnit
• Selenium Core
• JSSpec (MooTools)
• UnitTestJS (Prototype)
• QUnit (jQuery)
• DOH Unit Testing (Dojo)
• YUITest 2
• YUITest 3
• Mochitest
• ScrewUnit
• JsUnitTest
• jsUnity
• JsTestDriver
• Crosscheck
• Env.js
• FireUnit

The description from the JSConf site summarizes the talk well:

John Resig presents his mystery topic, which is actually three topics that strike his interest. First up is measuring performance and a quick introduction to benchmarking (and its positives and negatives). This is followed by JavaScript Games which he unveils some super cool hidden functionality (cheat codes++) on the jQuery web site. This is followed up by the introduction of John's distributed continuous test framework platform, Test Swarm. It is jam packed with Nirvana and goodness so be sure to watch both parts.

Part 1: Measuring JavaScript Performance, JavaScript Games

Part 2: Distributed JavaScript Testing, Q&A

Additionally, the slides from the talk are up on Slideshare.

The second half of the post is all about the new NodeIterator API that was just implemented. For those that are familiar with some of the DOM TreeWalker APIs this will look quite familiar.

It's my opinion, though, that this API is, at best, bloated, and at worst incredibly misguided and impractical for day-to-day use.

Observe the method signature of createNodeIterator:

This is excessive for what should be, at most, a simple way to traverse DOM nodes.

To start, you must create a NodeIterator using the createNodeIterator method. This is fine except this method only exists on the Document node - which is especially strange since the first argument is the node which should be used as the root of the traversal. The first argument shouldn't exist and you should be able to call the method on any DOM element, document, or fragment.

Second, in order to specify which types of nodes you wish to see you need to provide a number (which is the result of the addition of various constants) that the results will be filtered against. This is pretty insane so let me break this down. The NodeFilter object contains a number of properties representing the different types of nodes that exist. Each property has a number associated with it (which makes sense, this way the method can uniquely identify which type of node to look for). But then the crazy comes in: In order to select multiple, different, types of nodes you must OR together the properties to creating a resulting number that'll be passed in.

For example if you wanted to find all elements, comments, and text nodes you would do:

NodeFilter.SHOW_ELEMENT | NodeFilter.SHOW_COMMENT | NodeFilter.SHOW_TEXT

I'm not sure if you can get a much more counter-intuitive JavaScript API than that (you can certainly expect little, to no, common developer adoption, that's for sure).

Next, the filter argument accepts an object that has a method (called acceptNode) which is capable of further filtering the node results before being returned from the iterator. This means that the function will be called on every applicable node (as specified by the previous whatToShow argument).

Two points to consider:

• The filter argument must be an object with a property named 'acceptNode' that has a function as a value. It can't just be a function for filtering, it must be enclosed in a wrapper object. Update: Actually, this isn't true - at least with Mozilla's implementation you can pass in just a function. Thanks for the tip, Neil!
• The argument is required (even though you can pass in null, making it equivalent to accepting all nodes).

The last argument, entityReferenceExpansion, comes in to play when dealing with XML entities that also contain sub-nodes (such as elements). For example, with XML entities, it's perfectly valid to have a declaration like <!ENTITY aname "<elem>test</elem>"> and then later in your document have &aname; (which is expanded to represent the element). While this may be useful for XML documents it is way out of the scope of most web content (thus the argument will likely always be false).

So, in summary, createNodeIterator has four arguments:

• The first of which can be removed (by making the method available on elements, fragments, and documents).
• The second of which is obtuse and should be optional (especially in the case where all nodes are to be matched.
• The third which requires a superfluous object wrapping and should be optional.
• The fourth of which should be optional.

None of this actually takes into account the actual iteration process. If you look at the specification you can see that all the examples are in Java - and when seeing this a lot of the API decisions start to make more sense (not that it really applies to the world of web-based development, though). In JavaScript one doesn't really use iterators, more typically an array is used instead. (In fact a number of helpers have been added in ECMAScript 5 which make the iteration and filtering process that much simpler.)

I'd like to propose the following, new, API that would exist in place of the NodeIterator API (dramatically simplifying most common interactions, especially on the web).

I'd also like to propose the following helper methods:

Beyond finding elements, finding comments and text nodes are the two most popular queries types that I see requested.

Consider the code that would be required to recreate the above using NodeIterator:

This proposed API would return an array of DOM nodes as a result (instead of an NodeIterator object). You can compare the difference in results between the two APIs:

NodeIterator API

Proposed API

Another example, if we were to find all elements with a node name of 'A'.

NodeIterator API

Proposed API

Almost always, when finding some of the crazy intricacies of the DOM or CSS, you'll find a legacy of XML documents and Java applications - neither of which have a strong application to the web as we know it or to the web as it's progressing. It's time to divorce ourselves from these decrepit APIs and build ones that are better-suited to web developers.

Update: An even better alternative (rather than using constants representing node types) would be something like the following:

Just refer back to the back objects representing each of the types that you want.

There are a number of other new features and APIs that need attention, as well. The largest of which are Strict Mode and native JSON support.

Strict Mode

Strict Mode is a new feature in ECMAScript 5 that allows you to place a program, or a function, in a "strict" operating context. This strict context prevents certain actions from being taken and throws more exceptions (generally providing the user with more information and a tapered-down coding experience).

Since ECMAScript 5 is backwards-compatible with ECMAScript 3, all of the "features" that were in ECMAScript 3 that were "deprecated" are just disabled (or throw errors) in strict mode, instead.

Strict mode helps out in a couple ways:

• It catches some common coding bloopers, throwing exceptions.
• It prevents, or throws errors, when relatively "unsafe" actions are taken (such as gaining access to the global object).
• It disables features that are confusing or poorly thought out.

Most of the information about strict mode can be found in the ES5 specification [PDF] on page #223.

It should be noted that ECMAScript 5's strict mode is different from the strict mode available in Firefox (which can be turned on by going to about:config and enabled javascript.options.strict). ES5's strict mode complains about a completely different set of potential errors (whereas Firefox's existing strict mode tries to enforce some good practices, only).

How do you enable strict mode?

Simple. Toss this at the top of a program to enable it for the whole script:

Or place it within a function to turn on strict mode only within that context.

Note the syntax that's used to enable strict mode (I love this!). It's simply a string in a single statement that happens to contain the contents "use strict". No new syntax is introduced in order to enable strict mode. This is huge. This means that you can turn strict mode on in your scripts - today - and it'll have, at worst, no side effect in old browsers.

As you may note from the examples here and in the previous post there are virtually no new syntax additions or changes to the language in ECMAScript 5. This means that you can write your ES5 scripts in a manner that will be able to gracefully degrade for older useragents - something that wasn't possible with ECMAScript 4. The way in which strict mode is enabled is a great illustration of that point in practice.

A neat aspect of being able to define strict mode within a function is that you can now define complete JavaScript libraries in a strict manner without affecting outside code.

A number of libraries already use the above technique (wrapping the whole library with an anonymous self-executing function) and they will be able to take advantage of strict mode very easily.

So what changes when you put a script into strict mode? A number of things.

Variables and Properties

An attempt to assign foo = "bar"; where 'foo' hasn't been defined will fail. Previously it would assign the value to the foo property of the global object (e.g. window.foo), now it just throws an exception. This is definitely going to catch some annoying bugs.

Any attempts to write to a property whose writable attribute is set to false, delete a property whose configurable attribute is set to false, or add a property to an object whose extensible attribute is set to false will result in an error (these attributes were discussed previously). Traditionally no error will be thrown when any of these actions are attempted, it will just fail silently.

Deleting a variable, a function, or an argument will result in an error.

Defining a property more than once in an object literal will cause an exception to be thrown

eval

Virtually any attempt to use the name 'eval' is prohibited - as is the ability to assign the eval function to a variable or a property of an object.

Additionally, attempts to introduce new variables through an eval will be blocked.

Functions

Attempting to overwrite the arguments object will result in an error:
arguments = [...]; // not allowed

Defining identically-named arguments will result in an error function( foo, foo ) {}.

Access to arguments.caller and arguments.callee now throw an exception. Thus any anonymous functions that you want to reference will need to be named, like so:

The arguments and caller properties of other functions no longer exist - and the ability to define them is prohibited.

Finally, a long-standing (and very annoying) bug has been resolved: Cases where null or undefined is coerced into becoming the global object. Strict mode now prevents this from happening and throws an exception instead.

with(){}

with(){} statements are dead when strict mode is enabled - in fact it even appears as a syntax error. While the feature was certainly mis-understood and possibly mis-used I'm not convinced that it's enough to be stricken from the record.

The changes made in ECMAScript 5 strict mode are certainly varied (ranging from imposing stylistic preferences, like removing with statements, to fixing legitimately bad language bugs, like the ability to redefine properties in object literals). It'll be interesting to see how people begin to adopt these points and how it'll change JavaScript development.

All that being said, I'm fairly certain that jQuery is ES5-Strict compatible right now. Once an implementation of the language is made available (so that that premise may be tested) I'll happily switch jQuery over to working exclusively in strict mode.

JSON

The second major feature of the language is the addition of native JSON support to the language.

I've been championing this move for a long time and I'm glad to see it finally arrive in a specification.

In the meantime PLEASE start migrating your JSON-using applications over to Crockford's json2.js. It is fully compatible with the ECMAScript 5 specification and gracefully degrades if a native (faster!) implementation exists.

In fact, I just landed a change in jQuery yesterday that utilizes the JSON.parse method if it exists, now that it has been completely specified.

There are two primary methods for handling JSON: JSON.parse (which converts a JSON string into a JavaScript object) and JSON.stringify (which convert a JavaScript object into a serialized string).

JSON.parse( text )

Converts a serialized JSON string into a JavaScript object.

JSON.parse( text, translate )

Use a translation function to convert values or remove them entirely.

JSON.stringify( obj )

Convert an object into a serialized JSON string.

JSON.stringify( obj, ["white", "list"])

Serialize only a specific white list of properties.

JSON.stringify( obj, translate )

Serializes the object using a translation function.

JSON.stringify( obj, null, 2 )

Adds the specified number of spaces to the output, printing it evenly.

JSON.stringify( obj, null, "\t" )

Uses the specified string to do the spacing.

Additionally, a few new generic methods have been added to some of the base objects but, frankly, they aren't that interesting. The results from String, Boolean, and Number are just equivalent to calling .valueOf() and the result from Date is equivalent to calling .toISOString()

.bind()

A welcomed addition to the language is a built-in .bind() method for enforcing the context of a function (virtually identical to Prototype's .bind implementation).

Function.prototype.bind(thisArg, arg1, arg2....)

Enforces the 'this' of the specified function to a specific object - and passing in any specified arguments.

Considering how long this function (and its equivalents) have been around it's a welcome addition to the language.

Date

Dates are now capable of both parsing and outputting ISO-formatted dates. Thank goodness, about time. rimshot

The Date constructor now attempts to parse the date as if it was ISO-formatted, first, then moves on to the other inputs that it accepts.

Additionally, date objects now have a new .toISOString() method that outputs the date in an ISO format.

.trim()

A native, built-in, .trim() is now included for strings. Works identically to all the other trim methods out there - with the potential to possibly work faster.

Steven Levithan has discussed the trim method in great depth.

Array

The JavaScript Array Extras that've been around for, what seems like, forever are finally formally specified. This includes the following methods: indexOf, lastIndexOf, every, some, forEach, map, filter, reduce, and reduceRight.

Additionally a new Array.isArray method is included, providing functionality very similar to the following:

Altogether I think ECMAScript 5 makes for an interesting package. It isn't the massive leap that ECMAScript 4 promised but it is a series of respectable improvements that reduces the number of obvious bugs while making the language safer and faster. I'm looking forward to when some implementations start to go public.

Update: I've posted more details on ECMAScript 5 Strict Mode, JSON, and More.

There are a few new APIs included in the specification but the most interesting functionality comes into play in the Object/Property code. This new code gives you the ability to dramatically affect how users will be able to interact with your objects, allowing you to provide getters and setters, prevent enumeration, manipulation, or deletion, and even prevent the addition of new properties. In short: You will be able to replicate and expand upon the existing JavaScript-based APIs (such as the DOM) using nothing but JavaScript itself.

Perhaps best of all, though: These features are due to arrive in all major browsers. All the major browser vendors worked on this specification and have agreed to implement it in their respective engines. The exact timeframe isn't clear yet, but it's going to be sooner, rather than later.

There doesn't appear to exist a full implementation of ES5 at this point, but there are a few in the works. In the meantime you can read the ECMAScript 5 specification (PDF - I discuss pages 107-109 in this post) or watch the recent talk by some of the ECMAScript guys at Google.

Note: I've provided a couple simple, example, implementations for these methods to illustrate how they might operate. Almost all of them require other, new, methods to work correctly - and they are not implemented to match the specification 100% (for example there is no error checking).

Objects

A new feature of ECMAScript 5 is that the extensibility of objects can now be toggled. Turning off extensibility can prevent new properties from getting added to an object.

ES5 provides two methods for manipulating and verifying the extensibility of objects.

Object.preventExtensions( obj )
Object.isExtensible( obj )

preventExtensions locks down an object and prevents and future property additions from occurring. isExtensible is a way to determine the current extensibility of an object.

Example Usage:

Properties and Descriptors

Properties have been completely overhauled. No longer are they the simple value associated with an object - you now have complete control over how they can behave. With this power, though, comes increased complexity.

Object properties are broken down into two portions.

For the actual "meat" of a property there are two possibilities: A Value (a "Data" property - this is the traditional value that we know and love from ECMAScript 3) or a Getter and Setter (an "Accessor" property - we know this from some modern browsers, like Gecko and WebKit).

• Value. Contains the value of the property.
• Get. The function that will be called when the value of the property is accessed.
• Set. The function that will be called when the value of the property is changed.

Additionally, properties can be...

• Writable. If false, the value of the property can not be changed.
• Configurable. If false, any attempts to delete the property or change its attributes (Writable, Configurable, or Enumerable) will fail.
• Enumerable. If true, the property will be iterated over when a user does for (var prop in obj){} (or similar).

Altogether these various attributes make up a property descriptor. For example, a simple descriptor might look something like the following:

The three attributes (writable, enumerable, and configurable) are all optional and all default to true. Thus, the only property that you'll need to provide will be, either, value or get and set.

You can use the new Object.getOwnPropertyDescriptor method to get at this information for an existing property on an object.

Object.getOwnPropertyDescriptor( obj, prop )

This method allows you to access the descriptor of a property. This method is the only way to get at this information (it is, otherwise, not available to the user - these don't exist as visible properties on the property, they're stored internally in the ECMAScript engine).

Example Usage:

Object.defineProperty( obj, prop, desc )

This method allows you to define a new property on an object (or change the descriptor of an existing property). This method accepts a property descriptor and uses it to initialize (or update) a property.

Example Usage:

Object.defineProperty is a core method of the new version of ECMAScript. Virtually all the other major features rely upon this method existing.

Object.defineProperties( obj, props )

A means of defining a number of properties simultaneously (instead of individually).

Example Implementation:

Example Usage:

Property descriptors (and their associated methods) is probably the most important new feature of ECMAScript 5. It gives developers the ability to have fine-grained control of their objects, prevent undesired tinkering, and maintaining a unified web-compatible API.

New Features

Building on top of these new additions some interesting new features have been introduced into the language.

The following two methods are very useful for collecting arrays of all the properties on an object.

Object.keys( obj )

Returns an array of strings representing all the enumerable property names of the object. This is identical to the method included in Prototype.js.

Example Implementation:

Example Usage:

Object.getOwnPropertyNames( obj )

Nearly identical to Object.keys but returns all property names of the object (not just the enumerable ones).

An implementation isn't possible with regular ECMAScript since non-enumerable properties can't be enumerated. The output and usage is otherwise identical to Object.keys.

Object.create( proto, props )

Creates a new object whose prototype is equal to the value of proto and whose properties are set via Object.defineProperties( props ).

A simple implementation would look like this (requires the new Object.defineProperties method).

Example Implementation: (by Ben Newman)

Other implementation:

Note: The above code makes use of the Mozilla-specific __proto__ property. This property gives you access to the internal prototype of an object - and allows you to set its value, as well. The ES5 method Object.getPrototypeOf allows you to access this value but not set its value - thus the above method cannot be implement in a generic, spec-compatible, manner.

I discussed Object.getPrototypeOf previously so I won't bother discussing it again here.

Example Usage:

Object.seal( obj )
Object.isSealed( obj )

Sealing an object prevents other code from deleting, or changing the descriptors of, any of the object's properties - and from adding new properties.

Example Implementation:

You would seal an object if you want its existing properties to stay intact, without allowing for new additions, but while still allowing the user to write to or edit the properties.

Object.freeze( obj )
Object.isFrozen( obj )

Freezing an object is nearly identical to sealing it but with the addition of making the properties un-editable.

Example Implementation:

Freezing an object is the ultimate form of lock-down. Once an object has been frozen it cannot be unfrozen - nor can it be tampered in any manner. This is the best way to make sure that your objects will stay exactly as you left them, indefinitely.

All together these changes are very exciting, they provide you with an unprecedented level of control over the objects that you produce. The best aspect, though, is that you will be able to use these features to build larger and more complex features in pure ECMAScript (such as building new DOM modules, or moving more browser APIs into pure-JavaScript). And since all the browsers are on board this is absolutely something that we can look forward to.

Armed with a battery of tests he analyzes the various browsers manually (a painstaking task) but it yields some sweet fruit:

He breaks down the results into three areas (note: The results are very much still a work in progress, as noted by PPK, so please be aware of that before making any specific decisions on implementation or usability):

• Mobile JavaScript/CSS Tests - These are the most comprehensive tests, analyzing a number of common DOM methods, Ajax, touch events, keyboard events, font styling, and custom events. Scanning the tables of results should be able to give you a pretty good picture of what mobile browsers are like.
• Mobile CSS - Covering everything from CSS selectors (new and old) along with basic and advanced styling techniques.
• Mobile W3C CSSOM - Covers aspects like screen size, mouse position, document size, and scroll offset.

In general, the results are terribly painful. The majority of the devices and browsers available today are a complete mess. Thankfully smart devices are making solid inroads bringing along good-quality browsers (WebKit-based browsers and Opera Mobile) but it's going to be a while before those devices are widely available.

Peter-Paul gave two follow-up talks on mobile browser testing, at Google and at Yahoo, that are worth watching, for additional details.

Google Talk on Mobile Browsers

Yahoo Talk (also discusses mobile browsers)

PPK is also organizing the Fronteers conference, taking place this fall in Amsterdam. I plan on attending and speaking, as well.