So tell me this, Speedy Gonzales… given that the screen in front of you is capable of rendering a new set of pixels 60 times per second, or twice that if you have a hot new 120 Hz iPad or Razer phone, how many class names of elements would you need to inspect before .matches() took more than 16ms (or 8!) and .indexOf() took less than 16ms (or 8!), thus resulting in an actual difference manifested in reality?
(Despite it still being imperceptible to anything but a lizard.)
I have just gotten busy in order to respond to your comment and am pleased to report that, on this page, if I iterate over all 703 DOM nodes and check each one to see if it has the class graf, I can either do this for each element, el:
/(\"|\s)graf(\"|\s)/.test(el.className)Note that I’m looking for a full class name match, not purely the existence of some string of letters, so I must look for entire valid class strings— requiring a regex. Word boundaries (\b) aren’t enough, because a class name can contain these and still be valid.
I am 90% sure this is the right regex, and 0% pleased that I’m not 100% sure. I would have to go and read the spec to be confident.
Anyhoo, this takes 0.83 milliseconds to find the 10 matching elements out of 703.
(Let’s ignore the fact that 17% of developers will have gotten the regex wrong — or forgotten it — and therefore introduced a difficult-to-detect bug into their code in the name of ‘performance’.)
I apologise for the incoherence of the proceeding sentences, but I’m quite drunk.
Now, I could also do things the semantic way, as suggested in the article:
el.matches('.graf')Which takes, looping over all 718 elements (there’s more now because I’m typing out this response) um, 0.83 milliseconds.
If you don’t care to look further up the page, I will tell you that this is the same amount of time. Weirdly, exactly the same amount, to three significant figures!
Or maybe I’m lying. It’s hard to tell, right?
Assuming I am not lying (I’m not), no matter which method you choose, you would, in theory, be able to loop over several thousand DOM nodes before even a 120 Hz iPad takes a single refresh of the pixels on its screen (the point at which theory becomes reality).
And if you’re updating the DOM as a result of all of those calculations, the layout step probably takes much longer than 0.83 ms to complete anyway.
On this site, for example, a single layout (as a result of resizing the screen) takes 50ms on a big fat i7 with more ram than a sheep farm.

So, if you’re looping over 5,000 DOM nodes you have much, much bigger problems than the ‘performance difference’ between .matches() and .indexOf() (which doesn’t work, so obviously you meant to say .test() on a regex), and of course I don’t want to downplay the fact that THERE IS NO PERFORMANCE DIFFERENCE on the scale of 700 DOM nodes.
It’s Kraken Rum, if you’re wondering, with a splash of dry ginger ale.
