4

I am using Backbone and decided that I wanted a way to differentiate between HTML elements that were bound and those that were not.

So I would write (in HAML):

.container
  .title(name='title')
  .separator

As you can see it's clear that the dynamic element is title.

The reason for this was so I could mess around with the style and rename classes without worrying about breaking the app. It also means in the template I can tell what the dynamic elements are without needing to go back and forth with the Backbone View.

This means that I use $('[name=title]', this.el) to reference this element from code. I am wondering if this is slow and be a noticeable issue if used everywhere. I have read that id is fastest. I am using lists of items so id is unrealistic. How does class compare to name lookups?

Also, if you have suggestions about keeping track of dynamic elements in HTML templates I'd love to hear them.

FYI:

  • I got the idea because I was originally using the Backbone.ModelBinding plugin which used data-bind attributes for dynamic elements, but I am moving away from it now.

  • I'm using CoffeeScript, Backbone and haml_coffee templates.

  • I've also read the $(this.el).find('[name=title]') is faster than providing context to the selector.

Follow-up question:

A convention for indicating whether an HTML element is referenced from JS code

Updated jsperf to test all suggestions:

http://jsperf.com/class-or-name-attr-lookup/3

Community
  • 1
  • 1
vaughan
  • 6,982
  • 6
  • 47
  • 63

2 Answers2

2

Searching the name attribute of a DOM element might be a little bit slower than the class due to the need for Sizzle - the selector engine that jQuery uses - would need to parse the selector in order to determine exactly what needs to be found. Sizzle would need to determine from the string "[name=title]" that it first needs to be looking at the "name" attribute of all elements being searched and that the value of that attribute is "title" exactly. While I have read that Sizzle is very fast what it does I can only guess that it is going to be slower than a native JavaScript call to a DOM element attribute - class (element.className) - value.

To confirm my suspicions I made a perf: http://jsperf.com/class-or-name-attr-lookup. The results aren't what I would have suspected on the .find and .children calls but what I stated above seems to be supported in the first two examples at least. However, I have seen performance boosts in production code when using the most specific selector - e.g. .children instead of .find - as it isn't looping over unnecessary elements.

Also, I made a test a while ago to illuminate some of the differences between using a simple selector syntax and some more obscure and/or jQuery-ish syntax to compare performance that I thought was interesting: http://jsperf.com/id-id-vs-id-class/2.

I Hope some or any of this helps anyone.

kalisjoshua
  • 2,306
  • 2
  • 26
  • 37
  • Thanks heaps. Great answer! The `class w/ scope` vs. `named w/ scope` tests are quite convincing. I suspect `class w/o scope` wins due to the small size of the document. ID vs. class is interesting too. I wonder if using only ID selectors would cause any user-perceivable speed-up. In my current dev workflow its not really possible though, maybe with a javascript compiler like Google Closure it might be though. – vaughan Feb 09 '12 at 04:51
0

name lookups are probably no worse than class lookups, but consider that with the selector you have specified it will have to enumerate all DOM elements to find it. If I were you, I'd at least specify the type you need:

this.$("div[name=title]")

Also note the shorthand that you can use inside a backbone view; this.$ is a shortcut for $(this.el).find, which is functionally the same as $(selector, this.el)

EDIT

To answer your further question as to why this would be, there aren't any functions in the DOM that will return all elements with a specific class name; it is possible that there is something newer that I'm not aware of, but a quick google search hasn't turned it up if so. You can look at a sample implementation of finding DOM nodes with a specific class here.

Since that algorithm requires looping over all of the elements in the set anyway it isn't any more expensive to check the name attribute than it is to check the class attribute. (note that I haven't actually benchmarked that, but I don't know of any reason to suspect differently).

This plays into the reason that I suggested at least specifying the type of DOM element; if you use a selector such as $("[name=title]") then jquery will be forced to enumerate every single element in the DOM to find what you're looking for; granted, in this case you're only searching a small subset of the DOM (children of your view) so that isn't as big of an issue, but if you specify the type such as $("div[name=title]") then it can at least do the optimization of using getElementsByTagName where available.

(I say where available because I believe that some browsers allow calling getElementsByTagName on a subset of DOM nodes and some only on document)

taxilian
  • 14,229
  • 4
  • 34
  • 73
  • I am more interested in a justification as to why `name lookups are *probably no worse* than class lookups`. – vaughan Jan 31 '12 at 13:39