Rodney Rehm

A couple of days ago the following snippet made its way into my Twitter timeline:

as you can see in the fiddle, »It Works!«:

while this code does what is expected (namely showing/hiding nested lists), it has a couple of problems that are not visible and thus not apparent to the developer.

I won't be explaining anything that hasn't been covered in other blogs 1232343234 times in the last couple of years. But apparently we can't stop repeating these things over and over again.

Registering Events

Registering multiple event handlers on the same set of elements:

can be replaced by a single call to .on():

Instead of manually registering mouseenter and mouseleave events, we could have simply registered a hover:

And just to cover this too, you can register the same handler for multiple events:

All of this (and quite some more) is explained in the docs.

Event properties

When jQuery invokes event handlers, it passes an $.Event instance. This object contains all data associated with the event. It's a normalization of the native event objects (IE vs. real browsers) which you can still access through event.originalEvent.

We've previously established that we can register a single function for multiple events. But now we have to somehow identify if we are to show or hide the nested menu. We could do that by checking the list's display status:

Or we could ditch the slow and ugly DOM access and simply ask event.type:

Delegated Events

I couldn't explain the basics of event delegation any better than Steve Schwartz. If you don't know how delegating events works, read that post!

Thanks to event delegation, we stop binding the mouseenter and mouseleave events to every single <li> in our menu. Instead, we bind one event handler to the menu, and make sure it's only triggered for events happening on our "top-level" <li>:

Benefits of delegating events

• Quicker page load: DOM is only burdoned to register one event handler on the <ul>, rather than registering a handler for each <li>
• less memory consumption: 1 event handler instead of many
• New <li> automatically "inherit" the event handling

Considering the Context

Event delegation is possible because events "bubble" through the DOM. So each parent element in the hierarchy (up to document) is asked if it has a handler bound for event. If so, the handler is executed and the event bubbles up to the next parent element.

The above code prints #menu document. That is because document is the very last element in the bubbling chain. Knowing this, and the fact that we can abort the bubble process with event.stopPropagation() or event.stopImmediatePropagation() we can make sure that the event bubble stops at #menu:

The above code prints #menu. The handler on document is never executed, because the bubble was stopped.

With that in mind, our handler should now look like this:

Selectors

There is tons of material on the web explaining jQuery selector performance. I'm not going to repeat all of that, just what's important to us in this case:

• use $(context).find(selector) instead of $(selector, context)
• use $(context).children("ul") instead of $(context).find(">ul")

Most of jQuery's traversal functions accept a selector just like .find(). In the case of .children() (and .siblings(), .next() and so on) the selector is used as a filter. So $(context).children() will give you all direct descendants, and $(context).children("ul") will filter that down to all direct descendant <ul>.

With that in mind, our handler should now look like this:

Just take a minute and browse through jQuery's traversing functions. I bet there are a couple you haven't heard of yet.

Accessing Properties

There are two ways to access an object's properties:

With that in mind, our handler should now look like this:

Ternary Operator

Do you know the ternary operation?

Shrinking Things

Since both variables $ul and fade are only used once, they could also be replaced by inline code:

Strictly speaking, this should be the most performant scenario. We're not (only) writing code for the computer, but for other developers as well. While dropping the variable declarations may be nice from a performance point of view, the resulting code gets more complex to read.

I do not recommend taking this step. Keep code readable, even if that makes it a little more verbose.

Hard-Coding Options

Baking possibly configurable values into your source code is a bad idea - simply because you have no way of changing these properties later on. Try to avoid writing code that does things like .fadeIn(300). Those 300 milliseconds may look awesome on your development machine, but totally crap out on some old computer running IE6 (or on an iPhone, iPad, iWhatever). This doesn't solely apply to animations, but given the example code, we'll focus on that.

If you've ever read the .animate() docs, you'll probably know about "slow" and "fast". In its animation functions, jQuery accepts numbers (being a duration in milliseconds) and strings (being names of predefined durations). These predefined durations are accessible in jQuery.fx.speeds:

$(selector).fadeIn("foobar") will sillently fall back to jQuery.fx.speeds._default (because "foobar" wasn't defined).

For our script we could've setup jQuery.fx.speeds.listlist = 300; and used it by replacing $ul[fade](300); with $ul[fade]("listlist");. With that, we have the option of changing the 300 milliseconds whenever we want or need to.

Conclusion

• Use Event Delegation
• Mind your selectors, avoid find() if jQuery has a traversal function for it
• DRY: Dont Repeat Yourself - keep your code as concise as possible

Continue reading / watching jQuery Anti-Patterns for Performance by Paul Irish.