Fun question! So in JavaScript, every value with the "number" type is represented under the hood with a 64-bit (or "double-precision") floating point number. Floating point numbers represent a value with a combination of fractions and exponents, which allows them to represent a lot of numbers (with varying degrees of precision), but at the end of the day, the value still has to fit within 64-bits somehow. So there are limits. In this case, the highest number a 64-bit float can possibly represent happens to be 1.7976931348623157e+308 (this number is stored in the constant Number.MAX_VALUE should you ever need to reference it). Your value of 1e+309 is larger than that, so the best a 64-bit float can do is call it Infinity. Under the IEEE 754 floating-point standard (which JavaScript uses), there are some special values, like NaN and Infinity. You can basically think of NaN as "something went wrong with this number" and Infinity as "this number is bigger than I can do anything useful with". Both special values sort of infect anything they touch. The result of any math with NaN is NaN. The result of (almost) any math with Infinity is Infinity. console.log(NaN * 2); // NaN console.log(Infinity - 100); // Infinity console.log(Infinity * 0); // NaN Jumping back to those varying degrees of precision, the highest integer you can represent without losing any precision happens to be a good deal smaller than 1e+308. Since everything is actually a float under the hood, you can only get up to 253 - 1 (or 9,007,199,254,740,991) before you can't trust integer math to work right anymore (that number is stored in the constant Number.MAX_SAFE_INTEGER by the way). console.log(9007199254740991 + 10); // 9007199254741000 Now, the good news for anyone who loves big numbers, is that JavaScript recently added a new primitive type, "bigint". You can make a value a BigInt by adding an n to the end, or by calling BigInt on it. const num = 7; // <-- number const big = 7n; // <-- bigint const int = BigInt(7); // <-- bigint There are two big differences between BigInts and vanilla numbers. They are integers, not floating point. This means you can't represent fractions, but you also never lose precision. They are variable-bit. They start as 64-bit, but if the value gets to large, more bits are added. So with BigInt, we can represent big numbers. let x = 10n ** 309n; // e-notation not supported with BigInt console.log(x); // 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000n And we can safely do big integer math. console.log(9007199254740991n + 10n); // 9007199254741001n But any decimal places just end up getting dropped. console.log(5n / 2n); // 2n More on reddit.com

That SO solution is more elegant. It uses map to create a new array of just the values, then passes that to the built-in Math.max. Your solution is slightly more complicated and basically does just what Math.max does anyway. Edit: However, I knocked together a quick jsperf and it looks like the Math.max version is slower: http://jsperf.com/math-max-vs-ternery Personally I'd still go with Math.max as I find it easier to understand, and I really doubt there will be many situations in which this'd be a performance bottleneck. More on reddit.com