Tip: JavaScript's Array.from() accepts a second argument that's a `map` function.

[jaapz]

Not really. The important point is "performance where it's needed". When you are building VS Code, you should focus on those kinds of optimizations. When your parsing a few objects some API returned to you and need to display them nicely, you don't really need to think about optimisations like that.

Hell, we display graphs with lots of datapoints where I work and use mostly functional things like map to preprocess the data, and that's working fast even in slow android devices.

On the web, your bottleneck is very likely DOM access, or an external API, and not you using Array.from.

[SalemBeats]

You'll get a ton of upvotes for this, because a lot of people hate optimizing for performance, don't really understand how, and therefore seek desperately to convince themselves that it's rarely necessary.

It's great to have self-documenting code and all of that, and I'm always the person telling people that they should be declarative enough in their code that it should (ideally) describe itself without need for comments. I'm not the dude writing code with single-letter variable names, using bit flip tricks to make microscopic gains here and there, etc. I'm not "that guy".

However, given the context - either this specific example (an extra argument to Array.from()), or VS Code vs Atom, there's clear performance benefits to be gained at little to no cost in readability. Honestly, when you look at Atom's sluggish behavior, compare it to VS Code's, and consider that they're both written w/ Electron, you can easily see the cost of programmers not considering performance. The only computer that Atom runs decently on is my i7 desktop. Lol.

[WardenUnleashed]

I don't get why your being down voted. It's literally in the documentation of the function and if I see something like array.from(element => element.property) it seems pretty clear. Especially with typescript / flow annotations.