Actually, I was referring to the newer .entries methods. You know, Array.prototype.entries, Set.prototype.entries, Map.prototype.entries etc. They all return iterators and will not be slow.
Meanwhile the old and outdated Object.entries goes over the entire collection to build and return the array, which will then be iterated over by the user again. A truly unfortunate state. But hey, at least they are on the right path on the modern .entries impls!
Since we're on the topic, here's an efficient Object.entries impl instead-
It is quite true that functional approaches in JS are generally slower than the imperative approach, but I do think that it improves readability of the code and the performance overhead can usually be ignored......
Performance overhead can absolutely be ignored... if you don't care about the majority of your users. Usage is moving more and more to mobile devices, which are less powerful than desktops and laptops. They are also battery powered, and the more work the mobile browsers are being asked to do, the more it eats into that battery life.
Is readability of the code (and map is really no more readable than a foreach) really more important than the user base of the final product?
IMO, you should move as much code into the js engine, and using js looping constructs does not do that. Also, for loops are...not as simple as you might have thought...they have been completely screwed up by the people who decide what JS/ES is:
Before, they used to be one of the simplest and most elementary ways to loop.
In JavaScript, now, I never use them. Frankly, these days, there's always something better.
Why couldn't they just do this:
// for( a; b, c ) { d }
{
a;
while (b) {
d;
c;
}
}
Assuming I got that correct - you get the idea anyway.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
.entries should be used sparingly as its performance is bad for large collections. The fastest being for loop.
Actually, I was referring to the newer
.entries
methods. You know,Array.prototype.entries
,Set.prototype.entries
,Map.prototype.entries
etc. They all return iterators and will not be slow.Meanwhile the old and outdated
Object.entries
goes over the entire collection to build and return the array, which will then be iterated over by the user again. A truly unfortunate state. But hey, at least they are on the right path on the modern.entries
impls!Since we're on the topic, here's an efficient
Object.entries
impl instead-playground
yes i thought you were talking about
Object.entries
Can you elaborate on the performance part?
It is quite true that functional approaches in JS are generally slower than the imperative approach, but I do think that it improves readability of the code and the performance overhead can usually be ignored......
Performance overhead can absolutely be ignored... if you don't care about the majority of your users. Usage is moving more and more to mobile devices, which are less powerful than desktops and laptops. They are also battery powered, and the more work the mobile browsers are being asked to do, the more it eats into that battery life.
Is readability of the code (and map is really no more readable than a foreach) really more important than the user base of the final product?
IMO, you should move as much code into the js engine, and using js looping constructs does not do that. Also, for loops are...not as simple as you might have thought...they have been completely screwed up by the people who decide what JS/ES is:
youtube.com/watch?v=Nzokr6Boeaw
Before, they used to be one of the simplest and most elementary ways to loop.
In JavaScript, now, I never use them. Frankly, these days, there's always something better.
Why couldn't they just do this:
Assuming I got that correct - you get the idea anyway.