Jason Knight

The less code you use, the less there is to break

Nov 11, 2017

"i, j, k" has been pretty much standard for iterators in C syntax languages -- which JavaScript, PHP, and a host of others are -- since 1972. If you do not recognize what those are for, you're probably in the wrong business. For some reason Pascal programmers will use "t, n, v" -- never found out why...

If it's a event callback, you KNOW what it's being passed, again why waste time saying event.

Whilst I do like verbose code, you have to draw the line at where you go from clear to just plain obtusely pedantic. It's the opposite of where some people go so cryptic you can't figure anything out, mistaking over-the-top obfuscation for being 'concise'.

So long as the practice is standard (i, j, k) or obvious (event on an callback for an event handler), I don't see the problem with it.

At the same time, "handleAction" is a nice big word, but VAGUE. If you called it "eventHandler" or "eventCallback" you wouldn't need to explain "e". Sometimes it's not about making everything verbose, it's about making the vague obvious in a manner that explains everything else!

Though minimizing the impact of variables like 'i' can be fun in JavaScript... check this out:

var allInputs = document.getElementsByTagName('input');
for (var i = 0, input; input = allInputs[i]; i++) {
    input.disabled = true; // for example
}

As valid nodelist entries would never be loose false, it works... isolating our "cryptic" iterator variable to the "for" line. We wouldn't even need it inside the loop. I actually use this method a lot.

Sunny Singh

Creating Content & Code

Nov 11, 2017

I'm in the mindset of just because something has been done a certain way for a long time doesn't make it the best way. Thus, I understand that I'm making a controversial statement because it questions the way we've all been writing code.

My other main argument for verbose variables is that event.preventDefault() reads better in my head. Even out loud, most people will say "e dot prevent default". For that reason I really don't mind typing out the few extra characters. It's not as extreme as I think you state it is, but I can see your point of it being the opposite of too cryptic.

Better yet:

document
  .getElementsByTagName ('input')
  .forEach (input => {input.disabled = true})

When it's not necessary to worry about the iterator index, better to just forgo having it visible in the relevant code at all.

EDIT: Oh, Nvm, apparently getElementsByTagName returns an HTMLCollection and not a NodeList, so instead never use getElementsByTagName, because that function is just stupid. Instead do this:

document
  .querySelectorAll ('input')
  .forEach (input => {input.disabled = true})

EDIT 2: Apparently getElementsByTagName is much faster than querySelectorAll because it generates a live collection instead of a static collection, meaning if any nodes under the qualifying selector are added to the DOM, HTMLCollection adds it to itself and recomputes its length. The following works:

Array
  .from (document.getElementsByTagName ('input'))
  .forEach (input => {input.disabled = true})

Joe Gaspar You might be surprised in V8. For the most part in Spidermonkey and... Is Edge's engine also called Chakra, or is that the renderer? In any case in FF and Edge which are near identical in performance, yes the most you'll probably see in speed difference is around 8%... BUT...

In V8 the difference between:

Array.from(list).forEach(input => {

...And:

for (var j = 0, input; input = list[j]; j++) {

Is almost DOUBLE the performance or more... this is evident by if you are doing something INSIDE those loops with the resultant 'input' variable such as:

input.disabled = Math.random() < 0.2;
input.checked = Math.random() < 0.2;

You still end up with almost a 60% speed difference 'twixt the two!

I'm going to update my benchmarking routine/page to my latest elementals.js library and show you what I mean. The difference on ancient slow scripting engines is debatable, not on V8 in Chrome/Vivaldi/Opera it's in a whole different star system -- made all the scarier by the fact that even the slowest technique in V8 is 50% faster than the fastest in Spidermonkey -- which is how Chrome can run non-web assembly code as fast or faster than the poorly and inaccurately named "web assembly" on FF.

Search Hashnode