[golergka]

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.

[gnabgib]

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

  const [newA,newB]=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).

[neonsunset]

To be fair Unity is somewhat special because it requires a lot more massaging to get acceptable performance in the happy path than standard C# code. In the latter you mainly care about large allocations if application is latency-tolerant (i.e. as long as you don't touch LOH it's fine) or avoiding allocations in general if it's latency-sensitive. There isn’t that much difference with regular sane C# code.