Please don't shuffle an array like this. Array.prototype.sort requires the comparison function to be referentially transparent (i.e. to always return the same result when given the same two elements to compare), otherwise the sort order is undefined. For example, imagine how far from "shuffled" the resulting array will be if a bubble sort is used with a randomised comparison function.
The European Browser Choice screen was a good example of where this style of sorting can come and bite you - the browser choice screen was designed to display a selection of browsers in random order, but the above sorting code unintentionally biased it towards particular browsers.
Fisher-Yates is a better idea, of course, since it is pretty short and runs in linear time, but if someone insists on a sort-based one-linear this should work:
Argh, I missed the edit time window: "one-linear", should be, of course, "one-liner". Fisher-Yates is O(n), but the sort makes this algorithm Omega(n log n).
While I agree in principle, there are many cases where you don't care about the statistical quality of a random shuffle, where brevity has its benefit.
You don't understant. The code cited isn't even guaranteed to terminate by the spec; browsers could just go into an infinite loop if the comparison function effectively lies to them so the array never looks sorted... and this would be perfectly reasonable behavior.
So it's not that you get a bad random shuffle; it's that your code might never return from that sort() call.
And to be clear, there have been cases of "hang" bugs being reported to browser vendors in situations exactly like this one because people were writing boneheaded script like this.
Unlikely is an understatement -- the probability of an infinite sequence of PRNG outputs that prevents any sort algorithm from terminating is negligible.
When? It's not like anyone is asking you to write the shuffling code by hand, so when is time so precious, and space so constrained, that it's beneficial to use this "brief" incorrect solution over taking the 5 minutes to google a correct solution and copy-pasting that?
I'm not sure if it's "almost done". I bought the MEAP (early access) a long time ago, and for months nothing happened at all. Then a second author came on board to get things moving.
A few days ago I got an update from Manning:
"What's new?
Chapter 2, "Testing and Debugging" has been added.
Chapter 3, "Functions are fundamental" has been revised.
What's next?
Our next update will be coming quickly, with revised versions of Chapter 4 on closures and Chapter 5 on object-orientation with prototypes.
I haven't bothered yet to actually look at the PDF, it sounds like it's still in a rather early stage.
Wow, I'm seriously overjoyed to discover the "yield" operator, which I did not know existed (it barely shows up anywhere!). No more hackishly using window.setTimeout() to yield in JS pseudo-thread simulations!
Javascript 1.x where x > 5 are proprietary extensions of Mozilla.
Some of those extensions (e.g. Array Extras) trickled into the wider language, but as far as I know most of them (including let and generators) are confined to Gecko-based browsers still.
I use the pattern listed under "Objects private and public members" frequently and feel they missed an important point.
They really should add something like:
function MyConstructor( pub, priv ) {
var thisMyConstructor = this; //**Copy the 'this' variable**
var privateVariable = priv;
this.publicVariable = pub;
Otherwise "public" variables can't be accessed in private functions because "this" no longer references the object. So, from what I've learned it's always best to copy "this" to a private variable and use the private variable for consistency.
"1259359833574" isn't a magic constant. JavaScript uses // for comments. The number is just an example of the possible output of the expression "+new Date()" (specifically, it was the time at which the author of that page evaluated the expression).
Use a Fisher-Yates shuffle instead.