I was not aware of the browser deprecation of Shared array buffer. But this (or something like this) is a part of the ECMA proposal which is in stage 4. https://github.com/tc39/ecmascript_sharedmem
I said using forEach (or in-builts) are always a good practice. Now like you have to. For an example, if you have an array with no holes in it, for is better performant then forEach.
// for ... of
for(let node of nodes){
console.log(node);
}
// forEach
nodes.forEach(node => {
console.log(node);
});However it is slow currently in all major browser engines. For fast-path code, you should reach for something else (like a for(;;) loop), but for most other loops I always tend to reach for for...of for it's ease of use and compatibility with iterators makes it a pleasure to use!
At least https://jsperf.com/for-vs-foreach/293 shows that there is no significant difference in for of vs forEach in my version of chrome. There is an insignificant difference acoording to which forEach is actually slower. (One forEach case in that benchmark is only faster because it does something different.)
Edit: looking at the comparison at the bottom, it seems like forEach is actually significant slower than for of since chrome 61.
Thanks for that!
There are many reasons it is faster, but it also has the nice property of working sensibly on any iterable object rather than forEach that only iterates by index, and has an annoying ‘if (index in object)’ in the loop.
the for of is a loop.
at any rate it seems the kind of difference in legibility that would vanish with very little familiarity, I would expect for most people developing JavaScript regularly that forEach would be more legible - even with the arrow function - because it is the construct they encounter and use more often day to day.
Do you mean it's faster? (Don't use performant: use fast or faster instead.)
I disagree, using try/catch/finally for their intended purpose (exceptional cases) is going to be preferable to trying to replicate their function on your own. Even if just from a semantic standpoint (is semantic the word i'm looking for here? it feels wrong...).
>But this (or something like this) is a part of the ECMA proposal which is in stage 4.
I really dislike the idea of true shared memory for the extreme vast majority of cases, and i'm not particularly happy about it's inclusion into browsers, so take what I say here with an appropriate amount of salt. I personally think spectre is only the first of many many problems it will bring if fully integrated. Transferable objects are a much cleaner and safer pattern to use in most cases, and they are here today in all major browsers. I do admit that having shared memory available is a massive bonus to some kinds of problems, but I feel the net impact will be negative. That being said, until a fix for spectre is either in hardware, or they find a way to solve it in software that doesn't destroy SharedArrayBuffer's performance, it's not coming back. And I don't see those happening within a few weeks/months in all honesty.
>I said using forEach (or in-builts) are always a good practice.
That was only one example of many in the article that I felt was making advice which works on one engine (v8), in a well-defined set of situations (sparse array, hot code paths, no async/await in the case of forEach), into a general truth. Not many things are universally true, and spelling out the when, why, and where you should apply this advice will go a long way toward teaching others rather than just giving people a list that they can haphazardly apply.
Like your advice to avoid for...in. If you are iterating over enumerable properties, there is no reason to avoid it. It's slow, because that operation is slow, and most attempts to do it yourself more quickly will either fail, or will have edge cases that may introduce bugs. It's good advice in hot-path code, but shouldn't be universally followed. Especially when the alternative to a few lines of well-understood code is a mess of if statements, key lookups, and undefined/null checks.