45

I commonly see developers use an expression like the following in JavaScript:

arr = []
arr[arr.length] = "Something"
arr[arr.length] = "Another thing"

Wouldn't push be more appropriate?

arr = []
arr.push("Something")
arr.push("Another thing")
bloudermilk
  • 17,820
  • 15
  • 68
  • 98
  • 3
    I realise I'm only a hobbyist, but I *do* use `push()`, and now I feel like I'm missing some hitherto secret contraindication for such usage... – David Thomas Mar 27 '13 at 00:27
  • I frequently use it, although I prefer an indexer where it makes more logical sense (like a `for` loop). – Tim M. Mar 27 '13 at 00:28
  • People do sometimes think it's faster. See [Why is array.push sometimes faster than array\[n\] = value?](http://stackoverflow.com/questions/614126/why-is-array-push-sometimes-faster-than-arrayn-value) and [Using the push method or .length when adding to array?](http://stackoverflow.com/q/6772757/1048572) - results vary so wide that it's actually irrelevant. Use what is better to understand. – Bergi Mar 27 '13 at 01:16
  • What is faster is to increment a variable for the index, rather than using push or reading the growing array.length every iteration. Not that the difference is measurable by a human. – kennebec Mar 27 '13 at 06:59
  • Regarding this benchmark, push is faster in Chrome: http://jsben.ch/#/rGPv3 – EscapeNetscape Oct 21 '16 at 10:24
  • They are old developpers who learned javascript before 2010 and nodeJS. If you develop using modern ES6 javascirpt, you will use push. – Netsab612 Jun 07 '22 at 16:02

7 Answers7

61

I actually asked myself the same question at the start of this year. UPDATED with new test cases http://jsperf.com/array-push-vs-unshift-vs-direct-assignment/2

It appears that push is much faster in chrome, and about equal in FF. Also direct is faster in IE9, but I would be interested to see how it performs in IE10.

I would say that most developers would assume setting the length of the array, and then using direct assignment is faster, as is the case with most programming languages. But JavaScript is different. Javascript arrays aren't really arrays, they're just key/value maps just like all other JavaScript objects. So the pre-allocation is essentially falling on deaf ears.

Personally I prefer push (:

gkiely
  • 2,987
  • 1
  • 23
  • 37
  • My assumption was performance too. And at one point, it certainly may have been faster to avoid `push()`. Certainly not anymore though though! +1 – svidgen Mar 27 '13 at 15:07
  • 7
    Direct assignment has become considerably faster in newer versions of Chrome. Direct assignment (even using .length) is now almost twice as fast as using push. – AgDude Feb 04 '14 at 16:30
  • No. Javascript isn't that different here. Setting the length of the array and using direct assignment _is_ actually faster (Safari and Chrome): https://jsperf.com/push-method-vs-setting-via-key/10 It may be because the javascript runtime is typically implemented in C, and does pre-allocation based on some heuristics. See points 1 and 2 here: https://www.quora.com/How-are-javascript-arrays-implemented-internally/answer/Kiran-651 – Magne Apr 24 '20 at 15:09
5

I believe that it's mostly habit.

Some developers use it simply because it's the way they are used to do it, and haven't considered that push would be an alternative.

Some developers have learned once upon a time that one method is much faster than another, and haven't reviewed this in light of the recent performance improvements of the Javascript engines.

Personally I use push frequently. Most of the time readability and maintainability is more important than performance, at least when the performance impact is small enough. The performance tests posted in the answers here show that the performance difference between various methods isn't very big.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005
  • +1, it definitely is. And not only is the performance difference small, but changing between every test case and browser version :-) – Bergi Mar 27 '13 at 01:18
2

Very often when I'm pushing an object into an array, I want the reference to that object to be returned to me. For example:

// Returns object
function createAndAdd(arr) {
  return arr[arr.length] = { id: 1 };
} 
var obj = createAndAdd(arr);

Now I have the new object and I've added it to an array. If I'd used push then I would have been returned the length of the array. It would look like the following:

function createAndAdd(arr) {
  var obj = { id: 1 };
  arr.push(obj);
  return obj;
}

or even uglier, especially if the object gets big:

function createAndAdd(arr) {
  return arr[arr.push({ id: 1 }) -1];
}

Personally, I love functions with immediate return statements. Keeps it simple and easy to look at. Love the question. Thanks for asking it.

jbodily
  • 3,613
  • 2
  • 20
  • 21
1

It's a way to limit nested braclets. If you have enough of them you cant see howmany there are or howmany you need (when later looking at the code). I would use a var, one should only have to count things one time.

bar = foo.length;
foo[ bar++ ] = "new item 0";
foo[ bar++ ] = "new item 1";
foo[ bar++ ] = "new item 2";
foo[ bar++ ] = "new item 3";

http://jsfiddle.net/vEUU3/

gaby de wilde
  • 413
  • 5
  • 2
1

I think its not about performance, or at least is not such a big deal... what really matters here is declarative way vs imperative way.

0

Array.prototype.push method returns the updated array's length while the direct declaration returns the value that is being assigned. That's the only difference I see, but I usually read some best-practices recommendations about the push method being a better way to assign new values to an array.

0

Some coders don't recommend to use array.push() cause it modify the principal object. Instead of push(), you could use the spread operator:

let arrayOne = [1, 2, 3, 4];

let arrayTwo = arrayOne;

arrayTwo.push(5);

console.log(arrayOne);
console.log(arrayTwo);

// equals to arrayOne before the push()
let arrayOneAux = [1, 2, 3, 4];

// spread operator
let arrayThree = [...arrayOneAux, 5];

console.log(arrayOneAux);
console.log(arrayThree);
Mike
  • 14,010
  • 29
  • 101
  • 161