I wish authors would actually test their performance claims before publishing them.

I quickly benchmarked the two code snippets:

    arr.slice(10, 20).filter(el => el < 10).map(el => el + 5)

and

    arr.values().drop(10).take(10).filter(el => el < 10).map(el => el + 5).toArray()

but scaled up to much larger arrays. On V8, both allocated almost exactly the same amount of memory, but the latter snippet took 3-4x as long to run.

Iterator Helpers:

  arr.slice(10, 20).filter(el => el < 10).map(el => el + 5)

> This is really inefficient because for each transformation a new array should be allocated.

.slice[0] does not allocate, nor does .filter[1], only map does.. so one allocation.

  arr.values().drop(10).take(10).filter(el => el < 10).map(el => el + 5).toArray()

Allocates once for .values[2], and again for .toArray[3].. there's decreased efficiency here.

Swapping variables:

Only do this if you don't care about performance (the advice is written like using the array swap hack is categorically better).

[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[3]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Vast majority of JS/TS we write doesn’t live on the critical path and should be optimised for readability over performance.

However, when it does, it should be explicitly recognised, appropriate boundaries put, and that code written in a completely different style altogether. There are A LOT more of idiomatic and widespread JS/TS patterns that should not be used in such code.

Before TS, I used to write games in C# (Unity), and it was the same there too. I think this distinction between two kinds of code holds in a lot of environments.

Neither of these cases are more readable, if you want a readable swap can you get better than:

  const [a,b]=swap(b,a);

It does look a lot like linq, and has the same hidden complexity problem of linq.. while C# went through extreme lengths to optimise the performance penalties down to almost negligible - JS isn't there yet (and may never be after requiring multiple engines to catch up). An individual function in a chain of drop/jump/take/filter/change(map)/cast steps cannot look ahead to future needs, nor re-order for better efficiency... a (good) software engineer can. In the same way there's good ways to write SQL (benefit from indexes and reduce the set quickly) and bad (cause full table scans).