High precedence
Member access, calls, grouping and unary operations bind tightly.
Platform under construction
Operator Precedence
Operator precedence decides which parts of an expression run first. Parentheses make that decision visible.
1 + 2 * 3; // 7 (1 + 2) * 3; // 9 true || false && false; // true
Operators & Expressions
Do not make readers memorize the whole precedence table.
JavaScript has a formal precedence order. Multiplication runs before addition, member access runs before most operations and assignment runs very late.
Knowing the basics is important, but professional code does not try to show off. If an expression mixes multiple operator families, parentheses make intent clear.
Precedence is not the same as evaluation side effects. Short-circuiting, function calls and assignment can still affect when something runs.
Math order
* and / run before + and -. Parentheses can override this.
Logical order
&& binds tighter than ||. Parentheses help readers.
Low precedence
Assignment and comma happen late and should usually stay obvious.
Examples
Operators are small symbols with big consequences.
Parentheses show intent
const subtotal = itemCount * pricePerItem; const total = subtotal - (subtotal * discountRate); const canSubmit = hasName && (hasPlan || wantsDemo);
Dense expression with hidden order
const canSubmit = hasName && hasPlan || wantsDemo && !isBlocked; // Legal, but readers must decode precedence before understanding intent.
Rules that matter
Make expression intent visible.
JavaScript operators are compact, but compact is not always clear. Convert values before comparing or calculating, use strict checks by default and add parentheses when a future reader would otherwise need to remember a precedence table.
Use parentheses for mixed operators
Especially when combining arithmetic, comparison and logical operators.
Split large expressions
Named intermediate values are often clearer than one clever line.
Remember * before +
Basic math precedence still applies.
Remember && before ||
Logical expressions can surprise readers without grouping.
Do not mix ?? with || or && ungrouped
Use parentheses because JavaScript requires clear grouping there.
Keep assignment separate
Assignment has low precedence and should not be hidden inside big expressions.
Production thinking
Readable expressions prevent silent bugs.
Why does this matter?
Precedence bugs are reading bugs. The code may be valid, but the reader misunderstands what it really means.
Accessibility
Complex conditions often control UI state. If precedence is misunderstood, users can get wrong labels, focus behavior or validation states.
Production note
Production review is faster when expressions explain themselves. Parentheses and named values are cheap clarity.
SEO note
Conditional rendering expressions should be clear enough to trust when they affect headings, links and metadata.
Live code lab
Change the HTML, CSS or JavaScript and run the result.
The preview runs inside an isolated iframe. The JavaScript is placed inside the HTML editor for now, so every example stays together and remains easy to understand.
Mini assignment
Try this now.
- Add 10 - 2 * 3 and then add parentheses around 10 - 2.
- Create a mixed && and || expression, then group it two different ways.
- Try mixing ?? with || and then fix it with parentheses.
Practice assignment
Do this before moving to the next topic.
- Write one arithmetic expression where parentheses change the result.
- Write one logical expression where parentheses change the result.
- Refactor one dense expression into named intermediate values.
Try it yourself
Compare expression grouping
Self-check
Before you continue, prove that you understand Operator Precedence.
Say the answer in plain language. If you can explain the operator behavior, you can debug the expression.
- Can you explain what precedence means?
- Can you explain why * runs before +?
- Can you explain why && and || should often be grouped?
- Can you explain why ?? needs parentheses with || or &&?
- Can you explain when splitting an expression is better than adding more parentheses?
Chapter checkpoint
Operators & Expressions checkpoint
Finish this chapter by turning the lessons into a small practical proof.
Build
Build a small example that combines three lessons from this chapter.
Deliverables
- working code
- short explanation
- self-check answers
Quality checks
- readable code
- clear failure path
- accessibility considered
Review question
Can you explain the important tradeoff without reading from the page?