Note that you are off by 1, exactly, in one corner case.

Splice doesn't work the way you think it does. Your solution actually uses quadratically more memory allocations than this solution does. For that reason, splice is also the slowest array method in the language, making your solution quadratically slower.

Even in lower-level languages, arrays usually occupy a continuous chunk of memory addressed via offset, so there is no pointer to reassign, so splice can't be fast. Linked lists have that advantage, but also have distinct disadvantages (mainly slow data retrieval).

@cskyleryoung: The "runner up" wasn't always the runner-up. I don't think it's a stretch to say that both solutions helped each other gain points; ooflorent's solution and mine have a lot in common. The difference being, I've demonstrated how to use a tokenizer, which is generally good practice when writing a parser.

However, this language is really very simple and so many people took exception to my solution for being 'overkill' (just read the other comments). I expect it will soon lose the top spot. Which I am OK with, because I like the other solution as well (it is almost canonical). But when you start writing real world parsers, just know you can expect to write tokenizing/lexing code.

Please make sure your performance test will be accessible indefinitely, and next time you reference a different solution, please link to it. That way, your comments will stay intelligible in the future, even if the ranking changes.

@tommynaut: You're correct, thanks for letting me know!

For anyone left wondering, this does not mean the above proof is incorrect: Big-O notation represents an at most  relationship for how the run time increases with increasing n.

You mean the declaration? If you don't assign a value to a variable at declaration, its value is set to undefined.

The last variable is used in the set case and holds the last key in a property path. In the set case, the last key in the path is the property name that val is assigned to.

A fair comment. The longer the string, the more time is saved by checking for these easy cases upfront.

It's the minimum from the previous step. It shows a continuity, what we might call an 'induction hypothesis'. If min was the minimum from the previous step, and we take the minimum between that and the number we are currently looking at, we know that what we return is the minimum over all (so far), right? So we know we will end up with the minimum of all the numbers once we're done.

But I accept your criticism about the naming. prevMin would have been clearer.

Honestly I'm more upset about the initial, though. available is so much better.

DSPACE(n) is a superset of DTIME(n) [1]. This means at best your algorithm matches the time complexity of this one. But this rule also applies to the case where n is known ahead of time and the data structure can be allocated all at once (best-case scenario). So your algorithm is almost guaranteed to be asymptotically worse than O(n).

Or in layman's terms: Allocating space takes time. Allocating n memory cells generally takes at least n units of time. In a scenario where you don't know the value of n (such as this) you have no choice but to grow your data structure gradually. Once you've used up all the currently allocated space, you need to allocate a bigger space somewhere else and copy the values over. And so on.

Bitwise operators internally convert JavaScript numbers (doubles) to signed 32-Bit integers to perform their function; see the spec for the bitwise NOT operator and bitwise binary operators. 2,147,483,647 is the largest positive value a signed 32-Bit integer can take (see e.g. its Wikipedia article).

edits: Originally I said that their return value is a 32-Bit integer, which is true, but beside the point.

Just so you know: That's called spread syntax and is also mistakenly called the spread "operator" (see below). Not to be confused with rest parameter syntax.

This is an example of destructuring assignment:

var [a, b, c] = [1, 2, 3];
console.log((a + b) === c); //true

As for why spread isn't an operator: operator expressions have a return value at run-time, e.g. x === true ? 'foo' : 'bar'. This means you can substitute them with a variable; instead of if( 'length' in a ) {...} you can write var aHasLength = 'length' in a; if( aHasLength ) {...}. The same does not work with spread syntax.

In part, this is true. Certainly the comment is in response to seeing too many solutions using bitwise operators. This is my 6th solution to this kata, but none of them used bitwise operators: [1] [2] [3] [4] [5]

I wrote this solution. I can tell you it breaks two tenets of javascript best practices of old: (1) avoid the comma operator and (2) always delimit blocks with curly braces. Whether these are still as relevant now as they were then is debatable.

I've always held that the comma operator has its place in loop conditions. You should get acquainted with it. But in this case it's the wrong tool for the job. I've virtually never used it before, but I think this is a case for the do ... while loop.

It's possible, yes, but not preferable. In valid strings, you'd check the count twice as often, and for no benefit.