Once you learn the quirks of JavaScript you get used to it. Also you should not use forEach in JS, take a quick look at this page.
https://phoenix35.js.org/good-practices.html
The objection that it's not functional is invalid; procedural traversal with a callback function, object or closure, is a time-honored pattern in software.
Most of the other problems cited are not with forEach per se but the language in which forEach finds itself.
None of the alternatives presented are more attractive than
for (let i = 0; i < obj.length; i++) {
let elem = obj[i];
}
foreach (i, elem, obj) {
}
#define foreach(ivar, elvar, obj) \
for (let ivar = 0, elvar; \
ivar < obj.length && (elvar = obj[ivar], true); \
ivar++)
That source is simply incorrect. forEach is perfectly fine to use as long as you realize what is happening. It iterates an array where each thing is a function that returns a promise. Of course the results aren't what they expect.
ES5 array additions suffer from being a little too early (though later stuff wouldn't exist otherwise, so...). They are designed to deal with holey arrays (arrays with indexes missing). This is extremely uncommon today, but was decently common once upon a time. They were also created before the iterator protocol.
The real fix is to design iterator versions that can handle things like async generator functions.
> it should be deprecated and removed from the language in a timely manner.
NOTHING can be removed from the language once added. Doing that would break all the older websites that depend on it (technically, a few minor breaks happened after they tested millions of sites and couldn't find anything that was adversely affected). At best, they can block older features from newer features. For example, using class syntax or a bunch of other ES6 language structures automatically makes your code shift into "use strict" mode.
I hope they introduce a "use strict 2" variant that strips away more of the undesirable features than the current "use strict" does.
> Since Javascript is based on C syntax, it should have the preprocessor that the birthplace of C saw it fit for that language not to be without.
That pre-processor was a source of untold nightmares. Direct injection leads to bugs. If someone is going that route, full-blown macros are the only answer. There is a full-blown macro system Mozilla created a few years ago, but it's not very popular.
There also exist some C-style pre-processors for babel too, but they should be avoided because lisp's gensym is a critical feature that they and C both lack.