JavaScript conditionals let code decide between paths based on boolean conditions
Use if/else for ranges or complex logic; switch for exact multi-way branching
Ternary operator produces a value — use it for simple inline decisions
Switch uses strict equality (===) and requires break to avoid fall-through
Performance: switch can use jump tables in V8, but negligible for under ~10 cases
Production insight: one missing break in switch silently runs unintended code — always pair case with break
Biggest mistake: using = instead of === inside if — it assigns the value and the condition always passes
Plain-English First
Imagine you're a bouncer at a club. You check someone's ID — if they're over 18, they get in; if not, they're turned away. That decision-making process is exactly what a conditional does in JavaScript. It lets your program ask a question, check whether the answer is true or false, and then choose what to do next. Without conditionals, your code would do the same thing every single time, no matter what — like a vending machine that gives you the same snack regardless of which button you press.
Every useful program on the planet makes decisions. When you log into Netflix, the app checks whether your password is correct. When you add items to a shopping cart, the site checks whether you have enough credit. When a game character takes damage, the engine checks whether their health has hit zero. None of that is magic — it's all conditionals, and JavaScript gives you a clean, powerful way to write them.
Before conditionals existed in programming, code ran top-to-bottom like reading a book — line 1, line 2, line 3, done. That's fine for a calculator that always adds two numbers, but useless for anything interactive. Conditionals solve the 'what if?' problem. They let your code branch — choosing path A when something is true, and path B when it's not, just like a fork in a road.
By the end of this article you'll be able to write if/else statements, chain multiple conditions with else if, use the ternary operator as a shortcut, and pick the right tool with a switch statement. You'll also know the two most common mistakes beginners make — and exactly how to avoid them.
The if Statement — Teaching Your Code to Ask a Question
The if statement is the most fundamental conditional in JavaScript. Think of it as a gatekeeper. You hand it a question — technically called a condition — and it evaluates whether that condition is true or false. If it's true, the code inside the curly braces runs. If it's false, JavaScript skips the whole block entirely and moves on.
The condition always lives inside parentheses after the word if. That condition must evaluate to a boolean — meaning it must boil down to either true or false. You'll often see comparison operators here: == checks equality, > checks greater than, < checks less than, and so on.
One important detail: the curly braces {} are your 'block'. Everything inside them belongs to that if statement. Keep them — even when you only have one line of code inside. Skipping braces is technically allowed but causes bugs that are notoriously hard to find, and every senior dev has a horror story about it.
checkPlayerHealth.jsJAVASCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// A simple game scenario — checking if the player is still alive
const playerHealth = 45; // The player's current health points
const minimumHealth = 0; // Health at or below this means game over// The 'if' keyword starts the conditional.// The condition (playerHealth > minimumHealth) is evaluated — is 45 > 0? YES, so it's true.// Because it's true, the code inside the curly braces runs.if (playerHealth > minimumHealth) {
console.log("Player is alive. Keep fighting!");
// This line also runs because it's inside the same block
console.log("Current health: " + playerHealth);
}
// This line is OUTSIDE the if block — it always runs, no matter what
console.log("Game loop continues...");
// Now let's see what happens when the condition is FALSEconst secondPlayerHealth = 0;
if (secondPlayerHealth > minimumHealth) {
// 0 > 0 is FALSE — so JavaScript skips everything in here
console.log("This will NOT print because the condition is false.");
}
console.log("Second player check complete.");
Output
Player is alive. Keep fighting!
Current health: 45
Game loop continues...
Second player check complete.
Watch Out: = vs == vs ===
A single = is assignment (you're storing a value). A double == is a loose equality check. A triple === is a strict equality check — it checks both value AND type. Use === almost always. Writing if (score = 10) instead of if (score === 10) is one of the most common beginner bugs — it assigns 10 to score instead of comparing, and the condition always evaluates to true.
Production Insight
Accidental assignment is the #1 conditional bug in production code reviews.
It's completely silent — no error, no warning unless you run a linter.
Rule: always enable the ESLint rule 'no-cond-assign' to catch it automatically.
Key Takeaway
Always use === and always use braces.
Never skip braces for single-line bodies.
A missing brace can silently attach code to the wrong condition.
When to Use a Plain if Block
IfOnly one branch to run when true, nothing when false
→
UseUse a single if block with braces
IfBoth branches necessary
→
UseUse if/else, not two separate if blocks
IfMultiple mutually exclusive conditions
→
UseUse if/else if/else chain
if / else and else if — Handling Multiple Outcomes
An if statement alone handles one outcome: 'do this IF the condition is true, otherwise do nothing.' But real programs almost always need to handle what happens when the condition is false too. That's where else comes in.
Think of else as the 'otherwise' clause in plain English. 'If the traffic light is green, drive — otherwise, stop.' The else block catches every case that wasn't true.
But what if you have more than two possible outcomes? What if a traffic light can be green, yellow, or red? That's where else if shines. You can chain as many else if blocks as you need, and JavaScript will evaluate them one by one from top to bottom, stopping as soon as it finds the first true condition. This 'top-down, first match wins' behaviour is critical to understand — order matters.
Always end an if / else if chain with a plain else as your safety net. It catches any case you didn't explicitly predict, which prevents silent failures in your code.
gradeCalculator.jsJAVASCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// Converting a numeric exam score into a letter grade// This is a perfect use case for if / else if / else — multiple distinct outcomes
const examScore = 74; // The student's score out of 100if (examScore >= 90) {
// Is 74 >= 90? No. JavaScript skips this block and checks the next condition.
console.log("Grade: A — Excellent work!");
} elseif (examScore >= 80) {
// Is 74 >= 80? No. Skip and check next.
console.log("Grade: B — Great job!");
} elseif (examScore >= 70) {
// Is 74 >= 70? YES. JavaScript runs this block and stops checking the rest.
console.log("Grade: C — Good effort, room to grow.");
} elseif (examScore >= 60) {
// This never even gets evaluated because the block above already matched
console.log("Grade: D — Consider reviewing the material.");
} else {
// This is the safety net — catches any score below 60
console.log("Grade: F — Please see your instructor.");
}
// Demonstrating the 'top-down, first match wins' ruleconst bonusScore = 95;
console.log("\n--- Bonus Score Check ---");
if (bonusScore >= 70) {
// Is 95 >= 70? YES — this matches FIRST, so everything below is ignored
console.log("Passed! (Matched the >= 70 condition)");
} elseif (bonusScore >= 90) {
// This would also be true, but JavaScript never gets here
console.log("This will NEVER print, even though 95 >= 90 is true.");
}
Output
Grade: C — Good effort, room to grow.
--- Bonus Score Check ---
Passed! (Matched the >= 70 condition)
Pro Tip: Order Your Conditions from Most Specific to Least Specific
Always write your most restrictive condition first. In the grade example, >= 90 comes before >= 70 — because 90 also satisfies >= 70. If you flipped them, every score above 70 would match the first condition and the A grade would never be reachable. This is the single most common logic bug in if/else if chains.
Production Insight
A misordered else-if chain hides dead branches that never execute.
Code reviewers often miss it because the logic looks correct at a glance.
Rule: write the most restrictive condition first, then progressively less restrictive.
Key Takeaway
Order from most specific to least specific.
Always include a final else to catch unexpected values.
A missing else can leave your program in an unknown state.
IfChecking one variable against many exact constants
→
UseUse switch — cleaner and faster
IfYou need to return a value inline
→
UseUse ternary or if/else wrapped in a function
The Ternary Operator — A One-Line Shortcut for Simple Choices
Sometimes your if/else logic is so simple — 'if this is true, use value A, otherwise use value B' — that writing four lines of code for it feels like overkill. JavaScript gives you the ternary operator as a concise alternative for exactly these situations.
The word 'ternary' just means it takes three parts: the condition, the value if true, and the value if false. The syntax is: condition ? valueIfTrue : valueIfFalse. Read the ? as 'then' and the : as 'otherwise', and it reads almost like plain English.
The ternary operator is especially powerful when you're assigning a value to a variable based on a condition, or when you're embedding a decision directly inside a string or function call. However, resist the urge to chain multiple ternary operators together — it becomes unreadable fast. If your logic has more than two outcomes, stick with if/else if. Ternary is a scalpel, not a Swiss Army knife.
membershipDiscount.jsJAVASCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// Scenario: An e-commerce site applies a discount for premium members
const isPremiumMember = true; // Whether the user has a paid membership
const cartTotal = 120; // The total cost of items in the cart// THE LONG WAY using if/elselet discountPercentageLong;
if (isPremiumMember) {
discountPercentageLong = 20; // 20% off for premium members
} else {
discountPercentageLong = 5; // 5% off for everyone else
}
console.log("Long way discount: " + discountPercentageLong + "%");
// THE SHORT WAY using the ternary operator// Read as: 'isPremiumMember? Then 20, Otherwise 5'const discountPercentage = isPremiumMember ? 20 : 5;
console.log("Ternary discount: " + discountPercentage + "%");
// Ternary is great for embedding decisions directly in a stringconst discountedTotal = cartTotal - (cartTotal * discountPercentage / 100);
console.log(
"Welcome, " + (isPremiumMember ? "Premium Member" : "Guest") +
"! Your total after discount: $" + discountedTotal
);
// Example of what NOT to do — nested ternaries are hard to read// Don't write this:// const label = score >= 90 ? 'A' : score >= 80 ? 'B' : score >= 70 ? 'C' : 'F';// Use if/else if instead when you have more than 2 outcomes
Output
Long way discount: 20%
Ternary discount: 20%
Welcome, Premium Member! Your total after discount: $96
Interview Gold: Why Use Ternary Over if/else?
Interviewers love asking this. The right answer isn't 'because it's shorter' — it's 'because a ternary is an expression that produces a value, while an if/else is a statement that doesn't.' That means you can use a ternary directly inside a variable assignment, a function argument, or a template literal. You can't do that with an if/else block.
Production Insight
Nested ternaries are a readability nightmare in code reviews.
They also break debugging — you can't put a breakpoint inside one branch.
Rule: if your ternary has more than one ? or chained, convert to if/else.
Key Takeaway
Ternaries are expressions — use them for inline value selection.
Never nest ternaries; use if/else if instead.
Always parenthesise the entire ternary and branch values when mixing operators.
The switch Statement — Clean Multi-Way Branching
Imagine you're writing code to handle the day of the week — seven possible values, seven different outcomes. You could write seven else if blocks, but it would look like a wall of repeated code. The switch statement is built for exactly this scenario: when you're checking one variable against many specific, fixed values.
Switch takes a single expression, evaluates it once, then jumps directly to the case that matches it. It's faster to read and much cleaner when you have four or more possible values to check against. Each case ends with a break statement — this is JavaScript's signal to stop executing and jump out of the switch block.
If you forget break, JavaScript will 'fall through' — it'll keep running every case below the matching one until it hits a break or the end of the switch. This is a notorious source of bugs for beginners but is occasionally used intentionally by experienced developers when multiple cases should share the same logic. The default case at the bottom is like else — it catches anything that didn't match.
coffeeOrderRouter.jsJAVASCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
// A coffee shop order system — routing to the correct preparation method// Perfect use of switch: one variable, multiple specific values to check
const customerOrder = "latte"; // The drink the customer orderedswitch (customerOrder) {
case"espresso":
// Does customerOrder === 'espresso'? No. Skip.
console.log("Pulling a double shot of espresso.");
break; // Stop here — don't run any other casescase"latte":
// Does customerOrder === 'latte'? YES. Run this block.
console.log("Pulling espresso shot and steaming milk for a latte.");
break; // Without this 'break', JavaScript would fall through to 'cappuccino'!case"cappuccino":
console.log("Pulling espresso shot and adding thick foam for a cappuccino.");
break;
case"americano":
console.log("Pulling espresso shot and adding hot water.");
break;
default:
// Catches anything that didn't match any case above
console.log("Sorry, we don't have '" + customerOrder + "' on the menu.");
break; // Good habit to include break in default too
}
// INTENTIONAL FALL-THROUGH — multiple cases sharing the same logic// Both 'mocha' and 'hot chocolate' need the chocolate syrup stepconst warmDrink = "mocha";
console.log("\n--- Warm Drink Prep ---");
switch (warmDrink) {
case"mocha":
// No break here — falls through to 'hot chocolate' on purposecase"hot chocolate":
console.log("Adding chocolate syrup to " + warmDrink + ".");
break;
default:
console.log("No chocolate needed for this drink.");
}
Output
Pulling espresso shot and steaming milk for a latte.
--- Warm Drink Prep ---
Adding chocolate syrup to mocha.
Watch Out: switch Uses Strict Equality (===)
Switch compares cases using strict equality — it checks both value and type. So if your variable holds the number 1 and your case says case '1':, it will NOT match because one is a number and the other is a string. Always make sure the type of your switch expression matches the type in your case labels.
Production Insight
Forgetting break is the most common switch bug in production.
It's hard to spot because the code seems fine at a glance.
Rule: always pair case and break — write them together before filling the logic. Use ESLint no-fallthrough.
Key Takeaway
Use switch for exact multi-way branching.
Always include break (or return) unless you intentionally want fall-through.
Always include a default case to catch unexpected values.
Truthy, Falsy, and Logical Operators — The Hidden Decision-Makers
Every conditional ultimately depends on a boolean — true or false. But JavaScript doesn't require a strict boolean in an if condition. It coerces the value to a boolean automatically using a set of rules: a value is 'truthy' if it coerces to true, and 'falsy' if it coerces to false. The falsy list is short: false, 0, '' (empty string), null, undefined, NaN. Everything else — objects, arrays, non-empty strings, numbers other than 0 — is truthy.
This matters because you'll often see code like if (user) or if (items.length). That's idiomatic and safe, but only when you know the value can't be 0 or empty string legitimately. If you inadvertently pass 0 where you expected a non-empty string, the condition turns false unexpectedly.
Logical operators (&&, ||, !) also participate in conditionals in a special way: they short-circuit. The && operator returns the first falsy operand or the last operand; || returns the first truthy operand or the last. This allows patterns like const name = userInput || 'default'; but also causes bugs when you assume the result is always a boolean. The ! operator explicitly negates and always returns a boolean.
truthyFalsy.jsJAVASCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// Demonstrating truthy/falsy coercions and logical short-circuiting// What passes an if condition?if ({}) console.log("Empty object is truthy"); // printsif ([]) console.log("Empty array is truthy"); // printsif ("false") console.log("String 'false' is truthy"); // printsif (0) console.log("Zero is falsy"); // won't printif (undefined) console.log("undefined is falsy"); // won't print// The common trap: checking array lengthconst items = [];
if (items.length) {
console.log("We have items"); // 0 is falsy — won't run
} else {
console.log("No items"); // runs
}
// Logical OR for default valuesconst userName = '';
const displayName = userName || 'Guest';
console.log('Display name:', displayName); // Guest — empty string is falsy// BUT: if userName could be an empty string meaning legit empty,// this would incorrectly default. Use ?? (nullish coalescing) instead.const realName = userName ?? 'Guest';
console.log('Real name:', realName); // '' (empty string) – not overridden// Logical AND for conditional executionconst isLoggedIn = true;
isLoggedIn && console.log("User is logged in"); // prints// Reminder: && and || don't return booleans — they return operand valuesconst value = (false && 42) || 100;
console.log('Value:', value); // 100, not true
Output
Empty object is truthy
Empty array is truthy
String 'false' is truthy
No items
Display name: Guest
Real name:
User is logged in
Value: 100
Mental Model: Falsy Values Are the Exception
false, 0, '' (empty string), null, undefined, NaN — that's the entire list.
If it's not one of those six, the condition is true.
Objects and arrays are always truthy, even empty ones.
The number 0 is falsy, but the string '0' is truthy — catches many by surprise.
Production Insight
Using if (user) without checking for 0 or empty string can cause silent skips.
For example, if (score) skips when score is 0, which may be a valid score.
Rule: be explicit when 0 or empty string are valid inputs — use score !== undefined instead.
Key Takeaway
Know the six falsy values by heart.
Prefer explicit comparisons (===) unless you understand the coercion.
Use ?? (nullish coalescing) instead of || when 0 or '' are valid values.
● Production incidentPOST-MORTEMseverity: high
The Ternary That Overcharged Customers by $400K
Symptom
Premium members were being charged full price – the 20% discount was not being applied. Customer support tickets spiked by 300% in two hours.
Assumption
The developer assumed the ternary operator had the same precedence as a regular if/else, and that the discount calculation would follow the expected order of operations.
Root cause
The line const total = isPremium ? 0.8 base quantity : base quantity; was evaluated as (0.8 base) quantity for premium, but a misplaced parenthesis in production (typo: 0.8 (base * quantity) was missing) actually changed the multiplication order due to missing parentheses around the false branch expression — resulting in no discount at all.
Fix
Rewrote the ternary with explicit parentheses: const total = isPremium ? (0.8 base quantity) : (base * quantity); and added unit tests that compare ternary outputs against equivalent if/else blocks.
Key lesson
Always parenthesise ternary branches when mixing operators — operator precedence is not intuitive.
Test ternary logic with both conditions to confirm branches produce expected results.
Use linter rules that flag complex ternaries and prefer if/else for anything beyond a single variable assignment.
Production debug guideQuick symptom-to-action reference for common conditional bugs.5 entries
Symptom · 01
Condition always evaluates to true (else block never runs)
→
Fix
Check for single = instead of ===. Also check if you're using a non‑boolean truthy/falsy value that always coerces to true.
Symptom · 02
Switch runs code from more than one case
→
Fix
Verify every case has a break statement (or return if inside a function). Also check for unintentional fall‑through.
Symptom · 03
The first else if runs even when a more specific condition should match
→
Fix
Reorder conditions from most restrictive to least restrictive. The first true branch wins.
Symptom · 04
Ternary returns the wrong value for one branch
→
Fix
Parenthesise the entire expression. Check operator precedence — the ternary is low on the order and may interact weirdly with arithmetic.
Symptom · 05
Condition works in the console but not in code
→
Fix
Look for implicit type coercion. Switch uses strict equality (===) – if the variable is a string '5' and the case is 5, it won't match.
★ Conditional Debugging Cheat SheetThree quick commands to diagnose conditional problems in your code.
Accidental assignment (=) in condition−
Immediate action
Look for if (x = y) patterns. The condition will be truthy unless y is 0, null, '', undefined, NaN, or false.
Commands
console.log('x:', x, 'y:', y) just before the if
Run ESLint or similar – rule no-cond-assign catches this
Fix now
Change = to ===, or if you really need assignment, wrap it in extra parentheses and make the intent clear
Switch fall‑through (missing break)+
Immediate action
Check every case block for a break statement or return.
Commands
console.log('entering case', someValue) at the top of each case
Use a linter rule: no-fallthrough in ESLint
Fix now
Add break at the end of each case block. If intentional fall‑through, add a comment explaining it and disable the linter for that line
Ternary branch mismatch due to precedence+
Immediate action
Wrap the entire ternary in parentheses, and each branch value as well.
Replace the ternary with a temporary if/else and compare outputs
Fix now
Add parentheses around the ternary and around each branch expression: const result = (condition) ? (valueA) : (valueB);
Feature
if / else if / else
switch
Ternary Operator
Best used when
Conditions involve ranges or complex logic (e.g. score > 90)
Checking one value against many exact fixed values
Simple two-outcome assignments or expressions
Readability with 2 outcomes
Clear and readable
Overkill — too verbose
Very clean and concise
Readability with 5+ outcomes
Gets messy with many else if blocks
Clean and easy to scan
Avoid — becomes unreadable
Can compare ranges
Yes (e.g. age >= 18)
No — only exact matches
Yes, but gets messy quickly
Returns a value directly
No — it's a statement
No — it's a statement
Yes — it's an expression
Fall-through behaviour
Not possible
Yes — intentional or accidental
Not applicable
Performance on many cases
Checks top to bottom sequentially
Jumps directly to match (faster)
Single evaluation — very fast
Key takeaways
1
A conditional lets your code make a decision
it evaluates a condition to true or false and runs different code depending on the result.
2
Order your else if conditions from most specific to least specific
JavaScript stops at the first match, so a general condition placed too early will shadow the specific ones below it.
3
The ternary operator (condition ? valueA
valueB) is an expression that produces a value, which means you can use it inside assignments and function calls — unlike an if/else statement, which cannot.
4
Always use break in switch cases unless you intentionally want fall-through
missing a single break is one of the hardest bugs to spot because the code looks correct at a glance.
5
Exactly six falsy values exist
false, 0, '' (empty string), null, undefined, NaN. Everything else is truthy. Relying on truthy coercion is idiomatic but can hide bugs when 0 or empty string are valid inputs.
Common mistakes to avoid
4 patterns
×
Using = (assignment) instead of === (strict equality) in a condition
Symptom
The condition always evaluates to true, so the else block never runs. For example, if (userAge = 18) assigns 18 to userAge and then truthy-evaluates to true regardless of the original value.
Fix
Always use === for comparison. Enable ESLint rule 'no-cond-assign' to catch this automatically.
×
Forgetting break in a switch statement
Symptom
Code falls through and runs multiple case blocks unintentionally. For example, matching 'latte' without break also executes the 'cappuccino' block.
Fix
Write break immediately after each case block — before filling in the logic. Use a linter to forbid fall-throughs unless explicitly commented.
×
Putting the most general condition first in an else-if chain
Symptom
Specific branches are unreachable. For example, checking score >= 60 before score >= 90 means a score of 95 always matches the >= 60 case and never reaches A-grade logic.
Fix
Order conditions from most restrictive (highest threshold) to least restrictive (lowest threshold).
×
Assuming switch uses loose equality (==)
Symptom
A case like case '5': never matches when the variable is the number 5 because switch uses strict equality (===).
Fix
Convert the variable to the same type as the case labels before the switch, or use case 5: if the variable is a number.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01JUNIOR
What is the difference between == and === in a JavaScript conditional, a...
Q02SENIOR
When would you choose a switch statement over an if/else if chain? What ...
Q03SENIOR
What does 'fall-through' mean in a switch statement — is it always a bug...
Q04JUNIOR
How does JavaScript determine whether a value is 'truthy' or 'falsy' in ...
Q05SENIOR
Explain short-circuit evaluation in JavaScript logical operators. Give a...
Q01 of 05JUNIOR
What is the difference between == and === in a JavaScript conditional, and which should you use by default?
ANSWER
== performs type coercion before comparison (e.g., 5 == '5' is true). === checks both value and type without coercion (5 === '5' is false). You should always use === unless you have a specific reason to coerce types, because implicit coercion leads to subtle bugs. Interviewers want to see that you understand the coercion rules and that you prefer strict equality for predictable code.
Q02 of 05SENIOR
When would you choose a switch statement over an if/else if chain? What are the trade-offs?
ANSWER
Switch is best when you're comparing a single expression against many exact, fixed values (like enums or discrete constants). It's more readable and can be slightly faster because the engine can jump directly to the matching case using a jump table. Trade-offs: switch cannot handle ranges or complex conditions, the comparison is strict (===), and forgetting break causes fall-through bugs. If/else if is more flexible and safer for ranges or when conditions are complex.
Q03 of 05SENIOR
What does 'fall-through' mean in a switch statement — is it always a bug, or can it be used intentionally? Give an example of each.
ANSWER
Fall-through occurs when a case block does not have a break (or return), so execution continues into the next case's code even if that case's label doesn't match. It's usually a bug: e.g., forgetting break in a day-of-week switch runs multiple days' code. Intentionally: you can group multiple labels that share the same logic, like case 'mocha': case 'hot chocolate': // add chocolate syrup. The key is to always explicitly comment intentional fall-throughs and use a linter to flag accidental ones.
Q04 of 05JUNIOR
How does JavaScript determine whether a value is 'truthy' or 'falsy' in an if condition? Name the exact list of falsy values.
ANSWER
JavaScript coerces the condition to a boolean. Only six values are falsy: false, 0, '' (empty string), null, undefined, and NaN. Everything else — including empty arrays, empty objects, and the string 'false' — is truthy. This matters because if (array.length) will skip when length is 0, which may be a bug if 0 is a valid state.
Q05 of 05SENIOR
Explain short-circuit evaluation in JavaScript logical operators. Give a real-world use case and a potential pitfall.
ANSWER
With &&, evaluation stops at the first falsy operand; with ||, it stops at the first truthy operand. Use case: const name = userInput || 'default'; assigns 'default' if userInput is falsy. Pitfall: if userInput is an empty string or 0 (both falsy), you'll get 'default' even when the empty string is legitimate. The nullish coalescing operator (??) fixes this: it only treats null/undefined as absent.
01
What is the difference between == and === in a JavaScript conditional, and which should you use by default?
JUNIOR
02
When would you choose a switch statement over an if/else if chain? What are the trade-offs?
SENIOR
03
What does 'fall-through' mean in a switch statement — is it always a bug, or can it be used intentionally? Give an example of each.
SENIOR
04
How does JavaScript determine whether a value is 'truthy' or 'falsy' in an if condition? Name the exact list of falsy values.
JUNIOR
05
Explain short-circuit evaluation in JavaScript logical operators. Give a real-world use case and a potential pitfall.
SENIOR
FAQ · 5 QUESTIONS
Frequently Asked Questions
01
What is the difference between if/else and switch in JavaScript?
An if/else chain is best when your conditions involve ranges or complex logic like 'is the score greater than 90?'. A switch statement is best when you're checking one single variable against a list of exact fixed values like specific strings or numbers. Switch is cleaner and easier to read when you have four or more specific values to match against.
Was this helpful?
02
Can you use a ternary operator instead of an if/else statement in JavaScript?
Yes, but only for simple two-outcome decisions. The ternary operator (condition ? valueIfTrue : valueIfFalse) is an expression that returns a value, making it ideal for variable assignments and inline use. For anything with more than two outcomes, or when you need to run multiple lines of code per branch, stick with if/else if for readability.
Was this helpful?
03
Why does my if statement always run even when the condition should be false?
The most likely cause is using a single = instead of === inside your condition. Writing if (score = 100) doesn't compare score to 100 — it assigns 100 to score, and since 100 is a truthy value, the condition always evaluates to true. Change it to if (score === 100) to compare the value instead of assigning it.
Was this helpful?
04
What are the falsy values in JavaScript?
There are exactly six falsy values: false, 0, '' (empty string), null, undefined, and NaN. All other values — including empty arrays [], empty objects {}, and the string 'false' — are truthy.
Was this helpful?
05
How do the logical AND (&&) and OR (||) operators work in conditions?
These operators short-circuit. && returns the first falsy operand or the last operand if all are truthy. || returns the first truthy operand or the last if all are falsy. They don't necessarily return a boolean — they return one of the operands. This allows patterns like const name = userInput || 'default', but be aware that if userInput is 0 or '' (both falsy), the default will be used.