It's probably the game programmer in me coming out. Don't allocate things because something has to garbage collect them later. That takes time, causes glitches etc.
I wrote the below a while ago about this. It really doesn't matter if you are sure the code isn't going to work on giant data or be called frequently. If that is the case then my "dont allocate/copy/garbage collect" OCD kicks in :)
Nice article. It's actually something I've given little though to. Thanks for sharing, I'm sure I'll think of it in the future now.
Glad you like it :) Honestly only do that when it matters though - I mean I write code that uses all of the slow things when I know it will not be handling lots of data because it's quicker to write and that is the important thing for the task at hand!
Specifically on your point of immutability, a lot of frameworks in many languages implement collections like this. I usually just use them without even thinking about the memory issues. Your example in the article is very eye opening!
Yeah immer.js allows you to mutate arrays and then it works out an immutable version from it. That's very cool, but still has a cost as I replied in the comments to that article with a sandbox example showing (on my machine at least) significant frame drops in some use cases.
It so happened the example I had given and then implemented in immer is a kind of kryptonite to immer.js (because it happens over multiple cycles) but yeah, I see things on DEV all the time that use spread in loops - I just think, hope no one calls that example with 1 million entries not the example 10!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.