I think it rather means that the search time was short enough that neither search tree got deep enough to form advantageous moves. (When I check the detailed output, it seems that the asm.js version visits at least 2x as many nodes as the un-optimized version, independent of Time-per-turn)
That doesn't mean anything, asm.js only increases the amount of positions searched. If it searched more positions and still lost it means it either searched the same depth on average (which means the extra computational power did not finish a deeper search) or it just happened to lose despite it. See if it's searching more positions on average.
Basically UX doesn't have anything to do with the site's performance. Netflix have been solving great problems in development lately but they're due a good user experience uplift. No wonder people enjoy browsing their content more from other devices.
After learning Clojure and ClojureScript I got really excited and was ranting about it to my friend. He skipped Clojure and went straight to ClojureScript and has been having the time of his life.
One thing that's simpler in ClojureScript is that it only has one type of shared mutable reference, the Atom. Atoms are uncoordinated and synchronous. But Clojure has more types, with different behaviour characteristics. So in a way ClojureScript is simpler and could be the introduction.
I found your original article interesting, and I'm glad someone wrote about these Safari issues. But I also have to agree that one has to be very cautious when coming up with article titles. You're giving people a misleading context before even reading the content.
Wow, HN commenters are brutal! :) I thought the title captured the spirit of the piece; the problem was that people shared it without discussing the contents. As if to say, "Welp, that's it: Safari is the new IE. After all, some dude said it!"