Its because they don't do the same thing

Math.floor() favors the number equal to/less than the parameter, Math.floor(-15.5) is -16 while (-15.5 | 0) is -15

Also because the returned value is int32[0],

Math.floor(2147483648.5) is 2147483648 while (2147483648.5 | 0) is -2147483648

You are fine if you know the input is less than (2^31) + 1 and you want to truncate, rather than floor.

[0]: http://www.ecma-international.org/ecma-262/6.0/#sec-binary-b...

There is no substantial difference in performance on mine (within 2%), although the OR was always a little bit faster.

Chrome 45 on Linux

It's odd that a bitwise operator should have the effect of truncating the float (since X|0 == X)? I'm guessing there's an implicit type conversion to int in the middle?

And every time a developer sees that, they're going to google "bar javascript" "single bar javascript" "bitwise or javascript" "bitwise or javascript effect" until they figure out WTF is going on.

This all to save a fraction of a microsecond on an operation that's called 60 times on the page.

i/13|undefined works too

gulp I guess I should stop using parseInt :/