You can do it without either of those with this:
Array.from(nodeList$).map(myFunc)
or if you want to spread
[...nodeList$].map(myFunc)
Array.from(nodeList$).map(myFunc)
or if you want to spread
[...nodeList$].map(myFunc)
Unless your nodelist is insanely large, this is going to be a trivial GC to perform.
But the web just feels like it’s getting slower, grinding up CPU. I think in aggregate, this stuff does matter and it’s just wishful thinking to say it doesn’t.
It’s like at some point as a profession we took the mantra of “don’t prematurely optimize” as an excuse.
Honestly, js feels like a much better language today, especially with ts, and hopefully there are improvements that can be made with modern approaches at the JIT layer, but until then, I’d love it if we could just have a more performant web. It might not matter to you on your powerful dev machine, but it does to me now that I’ve given up the powerful dev machine.
I don't think the web is getting slower because we're using more map() instead of for...of loops. It's getting slower because what is being developed is getting more complex.
Feature bloat and excessive network load are the main reasons that the web feels slower imo.
I can tell you that when I navigate around the web doing nothing more than having some web apps open, the UI for the whole OS will start stuttering and the fans will kick into action. `top` says this is all chrome.
I buy that the problem is “feature bloat,” but I also think a great deal of these features are possible with a heck of a lot less code and a heck of a lot less pointless GC etc.
.filter().map() may not itself be alarming for a few hundred elements…but it is for a few hundred elements multiplied by a few hundred features. If you still want those few hundred features, maybe it would be nice if some thought had gone into making them individually perform better.
Tangent: I love the Unix philosophy! Do one thing well. Nothing more satisfying than being able to pipe inputs to outputs and put together little programs out of modular components. But when you want to build a program, you don’t do that, because you care about the “well” part of “do one thing well.”
Context does matter for a lot of this, and I think there’s probably a lot of grey area here. Doing something high level? Whatever, just get the job done, focus on readability, don’t worry about the weird performance edges of it. It’s just that those chunks have a tendency to become bigger chunks and get included where they were never intended, or where their underlying implementation is accidentally replicated multiple times for slightly different outputs (in the abstract, like doing .map().map().map()).
Anyway I can tell I’m losing the thread and ranting mindlessly now…
In this case, the code size is about the same if you run as-is (if you're doing DOM manipulation, performance is likely a real concern). I'd agree it would be premature optimization if we were talking about moving from a map to a full-blown loop or something, but it's hardly a huge change.
Another great example is chaining myarr.filter().filter().map().map() or some such that I sometimes see. Lodash shortcuts normal map with the assumption of arrays without holes and then uses their own iterators to avoid multiple copies. This results in a huge performance boost.
A final consideration here is transpiling. The above methods would actually increase the code size quite a bit trying to work around any edge cases and hit performance even more.
"Premature Optimization" is always a matter of opinion. Some people might consider implementing quicksort instead of bubble sort to be a premature optimization. Others might disagree with me and believe that you should always use loops instead of forEach or map. In any case, this is hardly the only case for using call/apply.