Whilst internally it does indeed us a loop -- possibly multiple loops -- they are done from the compiled language JS is written in, and not as the interpreted code.

You have to remember that JavaScript is an interpreted language... what you write is run on top of a coded engine instead of "directly on the metal". This is why C, C++, Pascal, Ada, etc, will mop the floor speed-wise with JavaScript no matter how good the JS engine. Also why assembly (which is just tokenized machine language) will mop the floor with compiled languages in the majority of cases as you're working in the language the hardware understands.

You might also hear that some languages use a "virtual machine" like Java or .Net. "Virtual machine" is literally just another form of interpreter that simply works with a pre-compiled byte-code that's a hair more efficient than parsing the text every time. They may also mix in a "Just in time compiler" that will try and compile as needed, but the compilation process itself can often take as long if not longer than just interpreting it.

In any interpreted/scripting language you are almost always best off using built in commands to do things rather than brute forcing it, because nothing you write for user-code will beat the compiled system code.

An excellent example of this is RegExp. You'll often hear developers say that regular expressions are "slow" and "should be avoided" when that's utter poppycock. Why? Because nothing you write as an alternative can be as fast as the system methods. Ever, it just doesn't work that way.

This is part of why some languages -- PHP for example -- have such massive function libraries. So that you can call them instead of writing your own slower alternatives.

Though there are exceptions to this. Element.classList is a great one as it's slow... No, painfully slow. This is because the new classList property is an array-like and JavaScript "Arrays" are NOT actually what "real programmers' would call an Array. They're actually "pointered lists" which is a slow-ass (but very versatile) way of implementing them.

Because it's an array-like and the methods on it operate on that list, the various Element.classList methods are in fact SLOWER than a regExp on Element.className is.

Basically this:

myDiv.classList.remove('test');

Is slower than:

myDiv.className = myDiv.className.replace(/\btest\b/g, '');

Even though it's less code and clearer. Code clarity vs. speed is a huge issue in interpreted languages, particularly when they're "source code distributed".

As such even though it's a rather massive number of loops, the three regex and single FOR w/substring is likely the fastest way of doing it just because it's relying on system functions for those loops instead of slower user generated code.

Though I'd write a benchmark before I put money on that. V8 does some weird optimizations that could change that, and each-and-every JS engine / browser is different. What holds true in Chrome might be complete nonsense in Safari, FF, or Edge... much less the absolute sluggart that is IE.