I've always wondered why I only see questions about checking for the exceptional floating point values in a Javascript context, not, for example, a C context, where people probably hit these problems more often. Perhaps C programmers are more prepared, but I think it's more insidious:

This is one of those weird points where Javascript seems like a confused mutant combination of a high-level language and a low-level one. It doesn't give you the power to manipulate the bits of a value, but simultaneously exposes you to all the strange, pointy bits of floating point implementation. It would be a lot nicer if it either gave you the power to fully manipulate the bits, or abstracted away the nastiness of the implementation, but no, they chose wrong in both directions.

If you mean that maybe bitwise operators shouldn't have been included at all if javascript was only going to have one numeric type which would be floating point, maybe you're right. However they can be useful as long as your integers or bit flags are smaller than 2^32 (or 2^31 depending on what you're up to), just pretty slow as every operation needs to do a double->int32->double conversion.

on the other hand, -0 and +0 are a pretty straightforward result of the normal floating point representation, are sometimes useful, and IEEE 754 defines +0==-0. Hiding them under a single 0 would have been more of a hack than having to deal with the difference very very occasionally.

I'm saying Javascript should've thought out its exposed number api a bit better. Either give me the bytes, or give me a number object that does infinite precision behind the scenes for me, don't make me do backflips to figure out whether I'm under/overflowing.