The differences I see is the stupid new "const" for nothing. (Not that it seems to serve any purpose other than breaking client-side code), the new array assignment that's not real-world deployable client-side either, the arrow functions that will instantly by their mere presence cause scripting to stop dead in its tracks in IE whilst making the code painfully and aggravatingly cryptic...
NOT a fan of these new techniques that like many newer "features" reek of bad ideas from other languages being shoe-horned into JavaScript because people coming from Java or Ruby to node.js "miss" them.
Though in this case, it's your use of const that's the problem as the "a" variables are isolated in scope existing for each iteration as a unique value. That block level scope means that every loop in your original gets its own "a" variable whist using "var" on mine means they do not. The value of A stops being block scope or an immutable reference.
NOT that I would be trying to pass values in/to and event handler given how it then interferes with "Event" and forces a situation where your perfectly good callback ends up wrapped in an anonymous function in a situation where anons are just slowing down the code and increasing the memory overhead.
Of course since your anchors have no scripting off href for graceful degradation, and have scripting only functionality, one has to question why they are <a> in the markup in the first place. Even with the scripting addition of the href="#" they're not navigable as <a>.
Don't even get me STARTED about the use of innerHTML or the slow backtick string BS.
If we skip fixing the markup issues and just talk the functionality, I'd have written that same thing -- if one were to use the querySelectorAll method -- as:
(function (d, info) {
var
demo = d.getElementById('demo'),
anchors = d.querySelectorAll(info);
for (var i = 0, a; a = anchors[i]; i++) {
a.href = '#';
a.setAttribute('data-count', i);
a.addEventListener('click', doTask, false);
}
function doTask(e) {
demo.textContent =
'# ' + e.currentTarget.getAttribute('data-count') +
' : ' + e.currentTarget.textContent;
e.preventDefault();
}
})(document,'#menu a');
Storing the count on the anchor as data- where we can retrieve it in the event. This way it's a property of the element instead of turning garbage collection into a nightmare with the enfeebled (and misleading) "const" crap.
I have a similarly low opinion of "let".
Though in practice I'd use neither technique, instead walking the DOM.
(function (d, target) {
var
demo = d.getElementById('demo'),
li = d.getElementById(target).firstElementChild,
count = 0;
if (li) do {
li.firstElementChild.href = '#';
li.firstElementChild.setAttribute('data-count', count++);
li.firstElementChild.addEventListener('click', doTask, false);
} while (li = li.nextElementSibling);
function doTask(e) {
demo.textContent =
'# ' + e.currentTarget.getAttribute('data-count') +
' : ' + e.currentTarget.textContent;
e.preventDefault();
}
})(document,'menu');Which even though it's about 90 bytes more code, would execute many, MANY times faster.
One of the keys to either technique being the storage of #demo as a VAR scope so that we aren't wasting time trying to get hold of it every blasted time the event first. We get it ONCE since methods like getElementById are are one of the slower operations you can call. Same goes for avoiding the use of querySelectorAll in favor of the DOM walk.
Though the real laugh is after gzip compression, the DOM method is typically (though not always) smaller. Your original gzipping to 317 bytes, my rewrite with the for loop going to 287 bytes, and the final DOM walking version being 300 bytes even.
But yeah, that wasteful const/let garbage, arrow function garbage, const of nonsense, etc, etc? Complex, convoluted, inefficient, and introduces performance issues on the back end that make me wonder "Just who thought adding this to JavaScript was a good idea?!?"
Probably the same people who think the RUST language is a good thing, when it's akin to someone looking at C++ and going "this is way too clear and concise, what can we do to **** this up and make programming even MORE difficult?"
I don't get the appeal, they don't do anything that couldn't be done cleaner, simpler, and faster without them. Of the many good and useful things added in the latest flavors of ECMAScript, they are the worst. Horrifically bad. Another of the many things that seem to have been created just to make the language larger, more complicated, and harder to use.
But what do I know? As a Wirth language fan I've always found block-level scoping a bit derpy. If function level is insufficient, you're likely ridiculously and painfully overthinking how your code should work.
Topic: JavaScript: Fastest way to iterate array-likes with non "loose false" values (Read 2039 times)