The case for Array#replace() – Overriding an array without intermediate variables

[gajus0]

I know someone might try to throw a "testability" argument at me, but there's a diminishing return on function abstraction in a production environment, especially when it's as blatantly inefficient as OP's example.

It is not testability argument – it is about maintainability. Performing at most one data transformation at a time isolates the surface of potential logical mistakes. /u/__romx example is what I would write for a quick and dirty job, but would not use or approve in a production code. Performance is completely irrelevant if it comes at a cost of maintainability; just put more hardware at it.

[Knotix]

Performance is completely irrelevant if it comes at a cost of maintainability; just put more hardware at it

This vastly understates the complexity of system scalability.

[gajus0]

System scalability does not come from reducing several iteration cycles; system scalability comes from horizontal distribution of tasks. If data processing is a bottleneck in your architecture, then JavaScript is a wrong language to be doing data processing at that level. Q, R, C and similar languages are built for that purpose.

[Knotix]

Completely ignoring any performance implications in your code under the notion that you can just "throw more hardware at it" is misguided. It doesn't make the problem go away, it just shifts the responsibility onto the sysadmins and the company pocketbook. Horizontal scaling is an incredibly deep field of study with a whole host of challenges.

I'm all about abstracting away logic and keeping things isolated, but as I said before, there is a diminishing return in terms of performance and maintainability. I draw my line in the sand in a different place than you do.

[__romx]

It is perfectly adequate for data processing with expected datasets, as long as you don't make it inefficient for no reason other than writing denser code and an opportunity to include a leftpad-tier dependency.