the performance difference between classes and IDs is irrelevant
Instead of a test with a list of 1000 elements, try a test with a nested list of 1000 elements. The performance problem with classes is that the browser has to traverse the DOM to find them, starting from the deepest element and working up. It's pretty quick, but not that quick when you have a deep tree. Whereas finding an element by ID is literally just a single lookup in an index regardless of where the element actually appears.
That said, DOM traversal was a very slow procedure for a long time, so browser developers spent a lot of time and energy optimising it. It's way better than it was. It could well be the case that classes don't have the performance problems they once did. Unfortunately, the test in this article won't show whether that's true or not.
To clarify, if you have a selector like "div.class a", and HTML like;
..then the browser goes to every anchor in the DOM and then looks up the tree asking 'Does this div have a class of 'class'?". That's what's slow. If you use "div#id a" then the browser can look for the id more quickly. That's why IDs are faster.
No, browsers key IDs off a hash table in exactly the same way that they key classes. The reason is that the Web depends on being able to have multiple elements with one ID.
Source: I implemented this in Servo and studied Gecko, WebKit, and Blink code for it.
The performance problem with classes is that the browser has to traverse the DOM to find them, starting from the deepest element and working up. It's pretty quick, but not that quick when you have a deep tree. Whereas finding an element by ID is literally just a single lookup in an index regardless of where the element actually appears.
Best I'm aware this was true until browsers all supported getElementsByClassName:
The only material difference between that and looking up a DOM ID is that the first yields an array (of a potentially wide range of tags) instead of a single element.
Plus, as already highlighted in a separate comment, `div.class a` or `div#id a` will both work the DOM tree from every `a` element up (just like describe) anyway.
Just to pile on what you said, I believe that with Flex and other CSS rules, the DOM tree is less deep then it used to be (less wrappers for alignments).
Obviously, I don't work at the scale of Facebook, but it's a tendency that I have witnessed in different projects.
So it's possible that the speed tradeoff between classes and ids become irrelevant, if it's not already.
Did you read the article? It said explicitly that regardless of `div.class a` or `div#id a` the same lookup takes place - every anchor on the page's parent is checked to see if it has the id or class specified by the selector.
So the selector `a#id` will be faster than `a.class` but a parent selector uses the same heuristic.
Comments
the performance difference between classes and IDs is irrelevant
Instead of a test with a list of 1000 elements, try a test with a nested list of 1000 elements. The performance problem with classes is that the browser has to traverse the DOM to find them, starting from the deepest element and working up. It's pretty quick, but not that quick when you have a deep tree. Whereas finding an element by ID is literally just a single lookup in an index regardless of where the element actually appears.
That said, DOM traversal was a very slow procedure for a long time, so browser developers spent a lot of time and energy optimising it. It's way better than it was. It could well be the case that classes don't have the performance problems they once did. Unfortunately, the test in this article won't show whether that's true or not.
To clarify, if you have a selector like "div.class a", and HTML like;
<div class="class"><div><div><div><div><div><div><a>Woo!</a></div></div></div></div></div></div></div>
..then the browser goes to every anchor in the DOM and then looks up the tree asking 'Does this div have a class of 'class'?". That's what's slow. If you use "div#id a" then the browser can look for the id more quickly. That's why IDs are faster.
No, browsers key IDs off a hash table in exactly the same way that they key classes. The reason is that the Web depends on being able to have multiple elements with one ID.
Source: I implemented this in Servo and studied Gecko, WebKit, and Blink code for it.
Best I'm aware this was true until browsers all supported getElementsByClassName:
http://caniuse.com/#feat=getelementsbyclassname
The only material difference between that and looking up a DOM ID is that the first yields an array (of a potentially wide range of tags) instead of a single element.
Plus, as already highlighted in a separate comment, `div.class a` or `div#id a` will both work the DOM tree from every `a` element up (just like describe) anyway.
Just to pile on what you said, I believe that with Flex and other CSS rules, the DOM tree is less deep then it used to be (less wrappers for alignments).
Obviously, I don't work at the scale of Facebook, but it's a tendency that I have witnessed in different projects.
So it's possible that the speed tradeoff between classes and ids become irrelevant, if it's not already.
Did you read the article? It said explicitly that regardless of `div.class a` or `div#id a` the same lookup takes place - every anchor on the page's parent is checked to see if it has the id or class specified by the selector.
So the selector `a#id` will be faster than `a.class` but a parent selector uses the same heuristic.