You have a good point. Unless JS exposes some API to directly control the capacity, we have to guess which use cases are more common and which use cases are fin

You have a good point. Unless JS exposes some API to directly control the capacity, we have to guess which use cases are more common and which use cases are fine to ignore. On the other hands though, JS's lack of capacity control means that developers are not conscious about the memory usage after all and JS engines have to do something about that anyway. Indeed, if you look at the actual bug [1], one commentator does mention exactly what I have said: > This is a great idea! Both shift() and pop() can treat the elements array as a dequeue. A "shrink capacity to 1/2 when usage is <1/3" would give us O(1) amortized performance for shift() and pop(), while avoid edge cases where we keep shrinking/growing for alternating add/remove ops around the shrink/grow boundary. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1348772 https://bugzilla.mozilla.org/show_bug.cgi?id=1348772