Why new Boolean(false) isn’t a falsy value in JavaScript

Ever wonder why new Boolean(false) isn’t considered falsy in JavaScript? This piece clarifies the distinction between primitive booleans and Boolean objects, and lists the true evaluators: false, 0, '', null, undefined, and NaN. A concise, practical overview with a few relatable examples.

Truthiness in JavaScript: why a Boolean object isn’t what you think

If you’ve ever written a snippet like if (value) { … } and then wondered why something seems to behave oddly, you’ve bumped into one of JavaScript’s trickier ideas: truthiness. It’s not just about whether a value is true or false. It’s about what JavaScript considers “truthy” or “falsy” when it decides whether to execute a block of code. And in the world of Salesforce JavaScript Development (think Lightning Web Components and modern UI scripts), understanding this can save you from squinting at a runtime log that seems to mock you.

Let’s start with the basics—what counts as falsy?

A falsy value is something that, when evaluated in a Boolean context (like an if statement), behaves as false. In JavaScript, there are a handful of common falsy values:

• false

• 0 (zero)

• '' (empty string)

• null

• undefined

• NaN

These are the usual suspects you’ll run into in real-world code. They’re the ones you’ll often flatten with a concise check like if (value != null) to avoid surprises when a variable is missing or empty.

But here’s the twist that trips people up: not everything that resembles false is falsy. The smallest, sneakiest trap is the Boolean object.

Primitive booleans versus Boolean objects

In JavaScript, there are two ways to represent booleans:

• Primitive boolean values: true and false

• Boolean objects: new Boolean(true) or new Boolean(false)

This distinction matters a lot in conditional tests. Primitive booleans are the usual, straightforward true or false. They’re the ones you expect in an if (flag) { … } check.

Boolean objects, created with new Boolean(...), are objects. And in JavaScript, all objects are truthy—regardless of what’s inside. That means new Boolean(false) is not falsy. It’s an object, and objects are truthy when evaluated in a Boolean context.

Let that sink in for a moment: even if new Boolean(false) contains the value false inside, the object itself is treated as true in an if statement. It’s a classic gotcha, and it’s not just a quirky syntax thing—it’s a fundamental behavior.

Putting it into a Salesforce-friendly frame

If you’re building UI logic for Salesforce with JavaScript (particularly in Lightning Web Components), you’ll often be dealing with data from servers, user input, or component state. You want robust guards like:

• if (record) { … } to verify you actually have a record

• if (userInput) { … } to proceed only when the user has typed something meaningful

• if (options?.length) { … } to ensure there’s something to work with

Knowing the nuance between primitive booleans and Boolean objects helps you write safer checks. You don’t want to accidentally treat a value as truthy because you wrapped it in a Boolean object, only to trip over a scenario where you expected a primitive false.

A few practical examples you’ll likely encounter

1. Checking a flag stored as a primitive vs an object

• Primitive: let isReady = false;

if (isReady) { console.log('Ready!'); } // nothing happens

• Boolean object: let isReadyObj = new Boolean(false);

if (isReadyObj) { console.log('Ready!'); } // this prints "Ready!" because isReadyObj is truthy

A quick takeaway: prefer primitive booleans for simple flags. If you must work with a Boolean object for some reason, explicitly extract its primitive value with isReadyObj.valueOf() or simply String(isReadyObj) to inspect what’s inside when needed.

2. Validating optional user input

• const input = document.querySelector('#name')?.value;

if (input) { console.log('Nice to meet you, ' + input); } else { console.log('What’s your name?'); }

Here, an empty string '' is falsy, so you’ll naturally get the prompt in the else branch. If input could never be undefined, you’re good. If it could be an empty string but you still want to treat it as meaningful, you’ll need a different check (length > 0) or a trim: if (input && input.trim().length).

3. Dealing with data from Salesforce APIs

When you fetch records, the data may come back as objects with nested fields. You might be tempted to do if (record.field) to decide whether to render something. The safe path is to be explicit:

• if (record?.field != null) { … } // true if field exists and isn’t null or undefined

This avoids accidentally treating an empty string or zero as a meaningful value, depending on the field’s nature.

Common pitfalls to watch for

• Using new Boolean(false) in conditional tests: it will trip you up. It’s truthy, so if (new Boolean(false)) will be true and your code might run the “truthy” branch unexpectedly.

• Treating any object as falsy: if you’ve stored data in an object wrapper, remember the object itself is truthy. You may need to inspect a specific property instead.

• Confusing null, undefined, and empty string: they’re all falsy, but they’re not interchangeable. If you need to distinguish between missing data and an empty field, you’ll want to check explicitly for null/undefined vs ''. A common pattern is if (value == null) to catch both null and undefined, and then separately handle the empty string.

Thinking in real-world UI terms

Think of truthiness as your component’s way of saying, “Do I have enough to show this piece of UI?” If you render a dropdown only when there are options, you’ll want to check that there are options and that the array length is positive. If you’re rendering a message when a user hasn’t provided input, you’ll check for a non-empty string.

The beauty and the trap of the JavaScript truthy/falsy landscape is that it’s both elegant and a little slippery. It invites concise code, but it also begs that you be precise about what you’re testing. In Salesforce-heavy apps, where data sources vary and UI states flip with user interactions, these distinctions matter more than you might expect.

A few practical patterns to keep handy

• Prefer explicit checks when the meaning of a value matters:

• Use if (value != null) to verify a value is neither null nor undefined.

• Use if (Array.isArray(items) && items.length > 0) to ensure we actually have items to display.

• Use if (typeof value === 'string' && value.trim().length > 0) to ensure there’s meaningful text.

• When you want a default fallback, use nullish coalescing:

• const name = user?.name ?? 'Guest';

• This means: if user.name is null or undefined, use 'Guest'. It won’t mistake an empty string for missing data, though—so adjust if you need to treat '' as “no name.”

• For booleans, keep it simple:

• const isEnabled = Boolean(flag); // converts primitives to true/false cleanly

• Avoid new Boolean(...) in conditionals; extract the primitive via valueOf() if you must.

A small digression that sometimes helps: the mental model

If you’ve ever stood in front of a vending machine and pressed a button expecting a snack, you know how the machine’s “truthiness” works in practice. It’s waiting for a valid input, and if it sees nothing, it won’t spit out a treat. In code, that “valid input” is what your condition checks. But if you hand the machine a “fake” credit card—an object with a false inside—it still counts as input because the object exists. The JavaScript engine doesn’t just peek inside; it looks at the whole thing and decides truthy or falsy from the outside. That’s the subtle, almost philosophical part of the language—and also the bit that trips beginners most easily.

Real-world debugging tips

• Console.log when in doubt. A quick log of typeof value, and whether value === null or value === undefined, can save headaches.

• If you’re dealing with API data, guard with optional chaining and explicit checks:

• if (record?.field != null) { … }

• if (Array.isArray(record?.items) && record.items.length) { … }

• Create small utility helpers if you find yourself repeating patterns:

• const isNonEmptyString = (str) => typeof str === 'string' && str.trim().length > 0;

• const hasValue = (v) => v != null && !(typeof v === 'string' && v.trim().length === 0);

Bringing it back to the everyday Salesforce dev rhythm

In the Salesforce ecosystem, you’re often juggling data from Salesforce objects, user preferences, and UI state. Truthiness isn’t just a nerdy footnote—it’s how your components decide what to show, what to hide, and when to fetch more data. Keeping a clear line between primitive booleans and Boolean objects helps you predict behavior, streamline logic, and build interfaces that feel both fast and reliable.

If you’re ever tempted to reach for a quick boolean constructor in a tight spot, pause for a second and ask: am I testing the value or the object? If you’ll be testing the value, a primitive will keep your tests honest. If you need to wrap a value in a Boolean for some reason, remember the object itself will still be truthy.

The bottom line

Truthiness is a core, practical concept in JavaScript. The simple truth that new Boolean(false) isn’t falsy can feel counterintuitive at first, but once you internalize it, your code becomes more predictable. In the context of Salesforce JavaScript development, this awareness translates into cleaner guards, safer data handling, and UI logic that behaves the way users expect.

So next time you’re wiring up a component or validating a field, pause and think about what your condition is really checking. Is it the presence of something, the absence of nothing, or the state of an actual primitive? A small moment of clarifying thought can save you a lot of head-scratching later—and keep your applications feeling crisp, responsive, and human-friendly.