I would certainly say "no" to having your basic array type be a hashmap as a hashmap is several orders of magnitude slower than an array for all operations on small arrays and for access for all sizes, although there is nothing wrong with also having hashmap and linked list collections if you need O(1) inserts.

However, what I was referring to is much worse than that:

JavaScript arrays are defined as a normal hashmap with string keys with hooks on assignment to parse the key as a uint32 and update the length property if the value is larger than the current one, and on length assignment iterate over all keys and delete those that successfully parse as a uint32 and has a numeric value larger than the one assigned to length.

Ah yes, I had forgotten about Typed Arrays, which is a terrible name for what is in fact a buffer view. The entire arraybuffer/typedarray system was a later (≥IE10 if I am not mistaken?) hack added to make up for the fact that Array and Number are super inefficient for data processing.

But regardless of them being a bandaid, you are correct that it is an exception. ArrayBuffer and all its views count 10 types in total, so were they the only exception? If so, I believe my point still stands.

That's just how it optimizes their usage under-the-hood, but as far as JS is concerned they are all hash maps.

For example, try this:

    var foo = [1,2,3];  // or `foo = new Array(1,2,3)` also works
    foo['bar'] = 'test';
    console.log(foo);

and you get:

    0:1
    1:2
    2:3
    bar:"test"