Many actions and examples posted here (even for beginners) seem to be built around things like:
for (i = 0; i < actions.length; i++) {
p.addButton(actions[i]);
}
rather than:
actions.forEach(
buttonName => p.addButton(buttonName)
);
Pity the poor beginner …
for statements have several moving parts and fiddly details, each of which can go wrong, especially when working with the (still quite rudimentary) editing and testing environment of Drafts JS.
With for ( … ; … ; … )
-
First, we have to introduce an index variable,
- (the undeclared i in the example above will often work, but it will also trigger an error if a preceding script step (very sensibly and helpfully) contains
'use strict'). Many scripters, especially beginners, would be puzzled and frustrated.
- (the undeclared i in the example above will often work, but it will also trigger an error if a preceding script step (very sensibly and helpfully) contains
-
then we have to obtain the length of the list
- (obtaining it repeatedly, for every single test, as in the example above, will often be absolutely fine, but with longer lists, the cost of all that unneeded recalculation of the list length will grow exponentially – in proportion to the square of the length of the list. Prepare for delays.)
- then we have to get our heads around, and manage with care, an in-place mutation suffix. Not something we will necessarily have seen in school, and a member of a class of operators that are famously prone to trip us up.
- then we have to remember that the 3 separate parts of the parenthesis stage of a for statement are delimited by semi-colons and not by commas. We all claim that we haven’t been caught out by that one …
- and as for the array that we are working through, we have to get items by index. Item 1 has index 1, like in Applescript, right ?
.forEach has just one moving part – a function.
- A function is a just an expression with a named gap, fill the gap, and you have a complete expression.
- Thats it.
So it does rather puzzle me to see for used as a default, and even as Exhibit 1 in examples for beginners.
Why ?
There is no right and wrong in scripting, just:
- what works and what doesn’t, and, within that …,
- what is best optimized for a particular purpose or context.
What is for optimised for ?
- Compressing down the execution time at any cost (tho while (i–) is faster, and the whole JSC interpreter is very fast anyway, and will seldom be the bottleneck in running a Drafts script)
- maximizing the time spent debugging and retyping (for easily goes wrong), and
- feeling like a proud technician – it’s not easy to master all those fiddly details and get fluent in them, so there’s a certain glow of achievement and of in-group pride.
What is .forEach optimised for ?
- Minimizing time wasted in debugging, also
- minimizing time wasted in typing, and just
- simplifying the mental model.
So for some people (especially those who mainly script as a distraction from the real task in hand) for ( … ; … ; …) will definitely always be the right choice – an endless and refreshing fountain of bugs and delays from which we can drink to our heart’s content, while maintaining a serious and technical expression on our brows. (@mattgemmell, for example, should clearly continue to use it. It will protect the rest of us from a surplus of those books 
For others, especially for beginners, and for anyone who just needs a little extra automation from time to time, quickly and cheaply, with as little time lost in debugging as possible, and with the minimum mental effort, .forEach is a better bet.
And all those vars ? …
Well var is now obsolete in the flavour of Javascript used by Drafts – left in only for backward compatibility. It wasn’t replaced for nothing, and will trip you up, but that’s another story …