Tell me young padawan, have you ever needed to assign a variable inside an if block and realized “oh no! I can’t access this outside the block further down where I need it!”, then end up writing something like this?

let foo

if(condition) {
  foo = 'bar'
} else {
  foo = 'bbq'
}

doThingsWith(foo)

Of course, you tried to use const first like a good frontend dev, but realized, oh yeah, “constants” can’t be reassigned. You can mutate the objects they hold sure (because that’s totally how constants work everywhere else…), but you can’t reassign them! So you switch to defining a let, which will always start life out as null. What you may not know if you started doing JavaScript development within the past 5-6 years, is that there’s more than const and let. In fact, for the majority of JavaScript’s life, nothing was ever defined as const or let. There was only var. Most frontend linters of today try to disallow any usage of the supposedly dreaded var keyword, and maybe mostly for good reason, but there are still cases where it’s useful. I contend that the above code snippet which I’ve seen from junior, mid, and senior engineers alike is an artifact of being stockholm syndromed by their own tooling, beaten into submission, and conditioned by the overall frontend community to avoid var at all costs. Here, in my opinion, is the perfect counter example.

if(condition) {
  var foo = 'bar'
} else {
  var foo = 'bbq'
}

doThingsWith(foo)

There truly is no reason to disregard this here, and if using typescript you have avoided completely the requirement that the previous version be inferred or explicitly typed as null | string. So go forth and use var when the situation calls for it. There’s no reason not to.