Let's use "undefined" in favour of "void 0"

[revelt]

I noticed that using env preset Babel turns all instances of undefined into void 0.

Arguments in favour of void 0 are mainly void (pun intended):

• Allegedly it safeguards undefined from reassigning. This is not relevant now since ES5 spec was released a decade ago which prohibits that. Since then, you can't reassign undefined primitive.
• Allegedly it takes less space than undefined. Three characters less. But minifying is not the purpose of Babel, is it?

Arguments against void 0:

• void is operator, undefined is primitive type. By definition, primitive type is more efficient to process than operator whose result is the same primitive type. The difference might be negligible but I haven't seen void 0 vs undefined perf tests proving that.
• ESLint flags up void 0 as a code bug, which means if you review Babel CommonJS build file (coming from Rollup typically), you'll see linting errors everywhere where you previously used undefined
• For JS newcomers void 0 is an unnecessary burden to learn and obfuscated Babel builds make it more difficult to understand what Babel does.

---

I know, this is not a bug per se or a feature per se, but nonetheless it's an important, fundamental issue that needs to be looked at. I see no reason why we should transpile down to ES3 JS spec (because, technically, that's what we're doing at the moment).

Thank you.

[babel-bot]

Hey @revelt! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[nicolo-ribaudo]

void is operator, undefined is primitive type. By definition, primitive type is more efficient to process than operator whose result is the same primitive type. The difference might be negligible but I haven't seen void 0 vs undefined perf tests proving that.

I'm 99% sure that void 0 is optimized by engines, so it isn't slower. It might even be a little faster because the engine doesn't have to check if undefined is defined somewhere in the scope. (This is just a supposition)
Anyway, unless you use void 0/undefined millions of times you shouldn't see the difference.

ESLint flags up void 0 as a code bug, which means if you review Babel CommonJS build file (coming from Rollup typically), you'll see linting errors everywhere where you previously used undefined

ESLint is configurable 😛

For JS newcomers void 0 is an unnecessary burden to learn and obfuscated Babel builds make it more difficult to understand what Babel does.

Well, there are many things waaay more difficult to understand than void 0 (have you ever looked at for...of output? 😅 )

[revelt]

@nicolo-ribaudo Thanks for quick response and sharing your view on this issue!

[loganfsmyth]

void is operator, undefined is primitive type. By definition, primitive type is more efficient to process than operator whose result is the same primitive type.

That is not quite a correct characterization. The undefined in most code is an expression that evaluates a global binding named undefined whose value has the type undefined. That means actually evaluating it requires a scope lookup. Also, unless you can show hard numbers that support the claim of it being more efficient, I'm absolutely disagreeing with that.

In the context of scope lookups, I think the bigger issue for me is that while a global undefined is locked down and non-configurable in ES5, there's still nothing stopping people from doing

var undefined = 4;

in their own module. That means that when Babel needs a reference to an undefined value, it would need to actually analyze the scope where the code will be injected to see if anyone has declared a variable named undefined and if so, fall back to void 0. Given that we'd need it there as a fallback either way, it is very unclear that there's anything to gain from what you're proposing.

ESLint flags up void 0 as a code bug, which means if you review Babel CommonJS build file

Running random linting rules on third-party files is never going to come up green. It does not seem like focusing on this specific case adds much weight when there are likely to be many other failures.

For JS newcomers void 0 is an unnecessary burden to learn and obfuscated Babel builds make it more difficult to understand what Babel does.

It's certainly slightly more work, but it's very straightforward to learn. There's also tons about the code Babel outputs that makes it hard to read. Optimizing for that case isn't generally something Babel aims to achieve.