jQuery: Performance analysis of selectors

In this article jQuery is tested with different selectors in order to find specific elements in the DOM tree. The delay of each selector is precisely calculated and the idea is to find out which one is the fastest for the given goal.

jQuery is one of the best javascript libraries I have ever worked with. It is quite simple and usually reduces the amount of javascript code in web applications. Besides all the advantages it brings to the web community, we have to pay attention to a few details when reusing this library in order to get the best part of it.

I will describe a few tips on how to improve the performance of your javascript code. Most of these tips aren’t a big deal if your pages are small and simple. But if you create complex html pages, you should follow them in order to prevent the browser from locking when the page loads up. Even if you are not concerned with performance at all, learning these things will bring benefits to your overall knowledge about this library.

jQuery has a bunch of different selectors – as you can see from the documentation here – and I won’t consider all of them in this analysis. My idea is to explore different ways of finding a specific element in the html page by using different types of search. Benjamin Sterling has already researched this topic here, but I want to add a different point of view, which is more accurate and provides more alternatives for the developers.

Let me start talking about the test html page, which has over 20,000 elements separated in chuncks of 5,000. Basically, there are 5,000 divs + 5,000 spans+ 5,000 paragraphs and 5,000 small tags with the following characteristics:

<!-- 5000 'div' elements -->
Div 0


Div 1

Div 4999

<!– 5000 ‘span’ elements –> <span id=”b-0″ class=”span-0″ row=”b-0″>Span 0</span> <span id=”b-1″ class=”span-1″ row=”b-1″>Span 1</span> … <span id=”b-4999″ class=”span-4999″ row=”b-4999″>Span 4999</span> <!– 5000 ‘p’ elements –> <p id=”c-0″ class=”p-0″ row=”c-0″>Paragraph 0</p> <p id=”c-1″ class=”p-1″ row=”c-1″>Paragraph 1</p> … <p id=”c-4999″ class=”p-4999″ row=”c-4999″>Paragraph 4999</p> <!– 5000 ‘small’ elements –> <small id=”d-0″ class=”small-0″ row=”d-0″>Small 0</small> <small id=”d-1″ class=”small-1″ row=”d-1″>Small 1</small> … <small id=”d-4999″ class=”small-4999″ row=”d-4999″>Small 4999</small>

The 20,000 elements above are generated by javascript. They provide a good laboratory to check the speed of each selector, since we can expect more accurate results in this analysis. The page itself has a few more tags to display information and execute each test, but this shouldn’t affect the final results.

The test page is available here. It takes a few seconds to load because the javascript must create the DOM tree as described above. So please be patient. Note also that each test uses the measure() function, which calculates the delay of the call in milliseconds.

Test 1 – Finding an element by ID

The first test is to find an element by its ID. I decided to get the element whose ID is “d-2642”. We can do this in three different ways:

A – Using the ID selector

B – Using attribute search

C – Using attribute search + tag

Running this test for the first time in different browsers, I could reach the results displayed in the following table (in milliseconds). It is clear that the # operator is the most efficient one.

Firefox Opera IE6 IE7 Safari
A 156 0 31 40 0
B 3609 828 2344 841 844
C 578 93 406 210 172

Test 2 – Finding an element by Class

Although CSS classes are intended to be reused among elements, you might create some elements with a unique class name just to identify and retrieve them through javascript. This is exactly what we test in this second test by seaching the element whose class is “p-4781”. We have four alternatives:

A – Using the class selector

B – Using the class selector + tag

C – Using attribute search + tag

D – Using tag search + filter

After running this test for the first time in different browsers, I got:

Firefox Opera IE6 IE7 Safari
A 2891 641 1718 631 329
B 453 78 313 180 78
C 422 109 578 201 187
D 203 266 375 210 94

The table above shows case B as the fastest selector for most browsers (except Firefox). It is easy to understand why case A isn’t efficient, since the code has to iterate over all elements of the DOM tree. Case C and D aren’t that bad, but I would say case B should be the preferred one for this goal.

Test 3 – Finding an element by Attribute

The third test is to find elements by a given attribute value. Sometimes this technique is useful and I decided to test it by searching for the element that has “c-3221” as the value of the row attribute. There are four possibilities in this case:

A – Using attribute search

B – Using attribute search + tag

C – Using tag search + filter

D – Using (tag + attribute) search + filter

Running this test for the first time in different browsers, I could get the following results:

Firefox Opera IE6 IE7 Safari
A 6610 1390 2500 801 1156
B 1250 360 406 200 250
C 1265 968 485 231 281
D 4078 1000 656 320 625

Case B is for sure the best approach to find an element by a specific attribute value.


This experiment was an attempt to find the right and fastest way of finding specific elements in the DOM tree using jQuery. Every jQuery developer should know and understand these details in order to create efficient code. Benjamin Sterling gave the first step in such performance analysis, but I could provide another point of view, which uses a big DOM tree and more alternatives to be checked.

JGoodies Binding API: The Basics

Learn the basics of the JGoodies Binding API, which allows you to separate the application logic from UI components. This can lead to better code and strategic separation of concerns. This is the first relevant step towards the Presentation Model pattern.

The JGoodies Binding API offers a set of classes that helps the applicability of the Presentation Model pattern in java. It was developed on top of the Swing API and has some mechanisms to bind UI components to variables and objects that can be operated independently of their visual representations.

You can download the API from the JGoodies website. This and other libraries are available here. Inside the zip file you will find the source code, the documentation, examples and the JAR file you should add to your classpath to run the examples.

Now let’s study the idea behind this API. There are two basic cases that you must understand:binding components to single values and binding components to lists of objects.

Case 1 – Binding Components to Single Values

In order to better understand this binding idea, imagine that you have a boolean variable that is bound to a JCheckBox. This “connection” means that whenever we change the value of this variable, the JCheckBox reflects this change. This is also true for the opposite direction, so that when we click on the JCheckBox, the variable receives the edited value.

In this same scenario, imagine now that we bind another component to our boolean variable – say – a JToggleButton. Now there are two components that visually display the same value held by that variable. Without surprise, you can realize that whenever the boolean value is changed, both components reflect the new value. Also, if you click either on the JCheckBox or theJToggleButton, the variable and all components bound to it are immediately updated.

This technique is a fundamental step towards the creation of the View and Presentation Model classes in the Presentation Model pattern, where the UI components are kept in the former, and the variables that describe the GUI state, in the latter.

In practice, components that can be bound to a single value are those that display a single value on the screen. This includes: JLabel, JTextField, JTextArea, JCheckBox, JRadioButton,JPasswordField and JFormattedTextField.

To connect these components to a variable, we need an implementation of the ValueModel interface (package com.jgoodies.binding.value), which holds a value and keep it synchronized with the value displayed by the component. Therefore, we can change the value held by theValueModel and the component will reflect this change. In the same way, if the user edits this value through the GUI, the ValueModel will receive the provided value.

public interface ValueModel {
    Object getValue();
    void setValue(Object o);
    void addValueChangeListener(PropertyChangeListener propertyChangeListener);
    void removeValueChangeListener(PropertyChangeListener propertyChangeListener);

There are two ways to connect a ValueModel to a UI component. The first one is to use the static method bind() of the Bindings class (package com.jgoodies.binding.adapter):

JTextField textField = new JTextField();
ValueModel valueModel = new ValueHolder();
Bindings.bind(textField, valueModel);

Notice that we create a ValueModel using the ValueHolder class, which is the implementation that we need for this case.

The second possibility is to use a convenient class called BasicComponentFactory (found incom.jgoodies.binding.adapter), which has methods to create the components with the binding idea in mind:

ValueModel valueModel = new ValueHolder();
JTextField textField = new BasicComponentFactory.createTextField(valueModel);

It is important to remember that whenever we bind a UI component to a ValueModel, the former must understand the value held by the latter. Therefore, we can connect without problems aJCheckBox to a ValueModel that holds a Boolean object, but NOT to a ValueModel that holds aDate. If the ValueModel receives a value that cannot be handled by the component, it will throw an Exception.

Case 2 – Binding Components to Lists of Objects

The second type of binding that we can address with the JGoodies API is useful to handle lists of objects that must be displayed on the GUI. In this case the following components can be used:JComboBox, JList and JTable.

The list of objects is represented by the javax.swing.ListModel interface, which provides:

– access to the objects in the list;
– the size of the list;
– capability to observe changes in the list.

public interface ListModel {
    int getSize();
    Object getElementAt(int index);
    void addListDataListener(ListDataListener l);
    void removeListDataListener(ListDataListener l);

Since this interface belongs to the Swing platform, the JGoodies’ contribution was two implementations that keep things as simple as the java.util.List interface: ArrayListModel (which inherits from ArrayList and implements ListModel) and LinkedListModel (which inherits fromLinkedList and implements ListModel).

As you can notice, the ListModel interface is not aware of selected objects in the list. This is actually good because in practice there may be lists where only one object can be selected at a time and others where multi-selection is desired. Thus, the ListModel alone does not solve our binding problem.

For lists of objects that can have only one object selected at a time, we can use theSelectionInList class (com.jgoodies.binding.list package). For lists that accept multi-selection, there is no generic class to handle this situation – this will be the subject of another article.

The SelectionInList class is basically a wrapper for a ListModel and a ValueModel. TheValueModel is used here to hold a reference to the selected object in the list. Let’s se how is can be used:

ListModel listModel = new ArrayListModel();
ValueModel selectedItemHolder = new ValueHolder();
SelectionInList selectionInList = new SelectionInList(listModel, selectedItemHolder);

We can bind a SelectionInList object to a JComboBox using an adapter:

JComboBox comboBox = new JComboBox(new ComboBoxAdapter(selectionInList));

We can bind JLists using the same component factory explained before:

JList list = BasicComponentFactory.createList(selectionInList);

The case for JTables is a little bit more complex because we need a TableModel implementation with defined columns.

Here is the source code of an example: https://www.dropbox.com/s/z5e3xouoqzdrawh/JTableBinding.zip?dl=0

Easy way to detect clutter in User Interfaces

Learn the screen scratch technique to easily identify visual clutter and noise in user interfaces.

There is an easy technique to identify visual clutter in GUIs that I would like to share with you. It is so simple that everybody can apply it quickly and everywhere. The technique is called Screen Scratch.

As you might have noticed, UI toolkits like Swing, AWT and SWT (among others) paint their components using colors that emulate a pseudo-3D image and produces a depth impression on the screen. This is exactly what we explore with this technique.

Imagine that your fingers could feel these 3D levels while you move them along the screen: how deep would your fingers vibrate? If you could “feel” a high degree of vibration, chances are that the screen is cluttered and needs to be revised. On the other hand, if you could notice just a few levels of depth, the screen is probably well designed and there is no visual noise.

It is important to remember that the goal of this technique is to identify components, borders and lines that should not stay together and were added by some developer without UI design skills. As a first example, take a look at a software tool called wGetGUI. Its screen is so cluttered that we would feel it as a piece of sandpaper.

Figure 1: Two possible arrangements of the same panel

With this technique we can easily spot the clutter on the UI due to the excessive number of borders and nested panels.

In general, the only borders that should be left on the GUI are component borders, since they bring important information to the users. Therefore, don’t try to change or remove them unless you know what you are doing.

Another point to which we have to pay attention is the emerging GUI styles available everywhere. Have you ever seen those beautiful shiny and glossy components that bring a soft and elegant UI to almost any software?

elegant Figure 2: Elegant Look-and-Feel with glossy components.

Components like the ones above would make our nails slide smoothly on the screen and this could be a problem to this technique. In this case, pay special attention to borders and other lines that are too close to each other. In fact, this is something that cannot be easily disguised even when the appearance of the components are well designed. Take a look at the nested borders of the JTabbedPane components above. Okay, this is just a demo app, but it should be clear to everyone that it contains lots of clutter.

What is the Presentation Model pattern?

In this article I explain the Presentation Model pattern, its structure and layers.

Presentation Model is a design pattern used to build desktop GUIs with a clean separation of concerns. One of the most important advantages of this pattern is the easy creation of unit tests that can focus on the application logic without touching UI components. In fact, this is a goal that many other patterns have failed to accomplish. Read the advantages of the Presentation Model pattern for more details.

The first characteristic of the Presentation Model pattern that you have to understand is how its classes (often referred to as layers) are organized. Figure 1 shows its structure, which details the following classes: view, presentation model and service layer. Before explaining each of them, pay special attention to the references (arrows) and notice that the class that holds the state and logic of the GUI (presentation model class) does not have a reference to the view. What happens is exactly the opposite: the view that has a reference to this class.

Let’s understand the role of each of these classes in the pattern:

  • View: Simple class that contains the UI components. The displayed data reflects the state kept by the Presentation Model class.
  • Presentation Model: Class that holds the state of the GUI and its logic. The code operates on data and variables in memory and is unaware of the existence of UI components and presentation formats.
  • Service Layer: Class that represents a channel between the Presentation Model and the outer world, where different types of service might exist (e.g., EJBs, databases, etc.). What lies beyond this layer is not seen by the Presentation Model class.



Figure 1: Three layers of the pattern

The Presentation Model class has no idea about views. It simply holds the state of the GUI and fires events when this state changes. Moreover, it is possible to attach more than one view to a presentation model instance, which leads to diferent visualizations of the same data.

The separation into decoupled layers and different responsibilities brings important advantages to the GUI implementation and maintenance. When we work this way, the layers become thinner and Ö consequently Ö more simple, which increases the understandability of the code. Besides that, the operations with models and business rules happen only in the presentation model layer, where the unit tests can reach efficiently.

The Presentation Model pattern applied without a framework requires some synchronization code between the layers (see the articles on the JGoodies Binding API).