> // now arr is [empty, empty, 2, '-4': -4]

I'm not sure because I'm not at home, but did you verify this pseudocode? Pseudocode doesn't have to be valid syntax, that's the point pf course. But it should bring the point across regarding the behavior of actual programs, no?

AFAIK, unquoted colons inside of array literals in JS are illegal.

I'd understand it better if you had written sth like

  {"0": undefined, "1": undefined, "2": 2, "-4": -4}

It is fairly clear that you are opting out of all optimizations applicable to what

  Array.prototype

is meant for in JS. The distinction between "empty" (in this special case, sparse arrays) and the primitive value "undefined" is similar to the difference between non-declared and undefined variables when not using const/let — which every one should do IMO, along with ES Modules instead of legacy node- or bundler-specific module syntax. Also, using var in 2023 makes only sense to me for two cases:

- REPL context wishing to redeclare identifiers other than functions defined using the function keyword - very legacy browser Targets, < latest IE11

Sparse arrays are, just like var, a historic relic.

I have never encountered any code where sparse arrays were intentionally used or appeared at all.

Arrays are objects in JS, yes. You can construct a sparse array using

  Array.from({length: 5})

"sparse arrays" are generally confusing and seldom desirable.

And JS is honest that it's an interpreted language where "arrays" are not even required to have a uniform member data type - which of course is very advisable for reasons that go beyond code readability.

But let's be honest, is (i.e.) PHP more clear in this regard?

Personally I hate PHP's mishmash of arrays and maps ways more than the JS version. Both are syntactical sugar for memory-managed and heavily optimized "map" like objects where the keys are restricted to primitive types.

Personally, I like that JS at least has a usable notion of strict equality and makes it easy to understand when values are references (always, unless they are primitive).

PHP's copy-on-write behavior, reference operators and the mishmash of "associative" and "indexed" arrays are much harder to actually understand and bigger footguns IMO.

JS has massive quirks, but what you show is not surprising for anyone doing JS with a modicum of proficiency.

JS is a scripting language.

People tend to forget this because of fast JIT compilers and because of TypeScript, I guess.

Sparse arrays are a relic and the differences between your "empty" and the actual primitive value "undefined" in JS are not of any practical significance in my opinion.

It's really a wart, but not one of practical relevance.

At least this differentiates this from "problems" like

  ["1","2","3"].map(parseInt)

that are really just a lack of basic syntax understanding.

>// now arr is [empty, empty, 2, '-4': -4]

This isn't pseudo-code. It's what your browser will output as the value for arr

What will seem weird and unexpected in this is that you're essentially dealing with dictionaries rather than arrays. They just have a length attribute bolted on that counts the highest key number as a length.

Yes that's what it is and I still would agree with you that this one of the really interesting warts/quirks of JS. Sorry if my comment sounded antagonistic, wasn't intended that's why I was editing some of it before reading your reply.

Highest key number + 1