You should stop using `parseInt()`

Unless you're doing this in the order of hundreds of thousands, performance is neglible (I've rarely come across use cases like this in prod systems)

While it's nice to think about these things and how you write code, I will always push back on people looking to enforce issues or 'standards' like this in PRs because they're rather subjective POV on style or rely on contrived performance benefits. If this seems like a harsh response, I apologise, but I'm wary of articles with titles like you 'should' be doing this, or you 'must not' do this, etc.

there are of course use cases where it’s beneficial to use it, for example if you want to extrapolate an integer out of a floating number, which is a good 50% faster than Math.round().

Two things here -

1. parseInt doesn't do any rounding, only truncation. The equivalent Math function would be Math.trunc:
   

   Math.round('0.999') // 1
   Math.trunc('0.999') // 0
   parseInt('0.999')   // 0
   
   Math.round('-0.999') // -1
   Math.trunc('-0.999') // -0
   parseInt('-0.999')   // -0
   

2. Running benchmarks in Chrome, the performance benefit of parseInt over Math.round is reversed if you explicitly convert to a number first:
   

   const bench = (desc, cb) => {
       const start = new Date()
   
       for (let i = 0; i < 1e7; ++i) {
           cb()
       }
   
       const end = new Date()
   
       console.log(desc, `${end - start} ms`)
   }
   
   bench('parseInt',       () => parseInt('3.2', 10))       // 374 ms
   bench('round coerced',  () => Math.round('3.2'))         // 738 ms
   bench('round explicit', () => Math.round(Number('3.2'))) //  70 ms
   bench('trunc coerced',  () => Math.trunc('3.2'))         // 671 ms
   bench('trunc explicit', () => Math.trunc(Number('3.2'))) //  62 ms
   

Today is finally the day I could use the information from this article. I came across a case where I had to cast a string to number. Worked flawlessly and Number() provides a nice interface to work with 👍

Ok, but you did sum up the issue yourself in the examples. ParseInt will order to an integer whereas Number will get the proper numeric representation. Which means the outcome ma not be an int, which is what ParseInt guarantees .
The use of ParseInt can be replaced with Number if and only if it's accompanied by Math.round. This is not an edge case or an odd use case, it's the missing piece to have the intended outcome: an integer. The odd case is requiring the use of radix.

const myNumber = '1';
console.log(+myNumber);

const myNumber = '1.5';
console.log(+myNumber);

Shorter.

By the way, you will need parseInt anyway, if you want to deal with custom base number other than 10. Example is to convert HEX color code into RGB color code:

console.log([
    parseInt('ff', 16),
    parseInt('a5', 16),
    parseInt('00', 16)
]);

Very useful and well written post! Thank you!

What about eval()?

Keep in mind that both return different results when when passing nullish or boolean values:

parseInt(); // NaN
parseInt(null); // NaN
parseInt(''); // NaN
parseInt(true); // NaN

Number(); // 0
Number(null); // 0
Number(''); // 0
Number(true); // 1

This post is already a bit old, but the topic is still relevant. And the advice in this post is very much incomplete. Watch this:

Number('0x4') // 4
Number('-0x4') // NaN
Number(null) // 0
Number(undefined) // NaN
Number('') // 0
Number('  ') // 0

The Number constructor is highly unreliable when it comes to interpreting user input from a form.

Unfortunately all oneliners in Javascript are broken. Nothing works. Neither parseInt nor Number nor any other implicit or explicit attempt to convert the value.

You always have to use a combination of different functions plus some manual checking for special cases like empty string, null, or undefined... otherwise you will always experience inconsistent behavior.

Or use +