fact-check

• Before publishing a new concept page
• After significant edits to existing content
• When reviewing community contributions
• When updating pages with new JavaScript features
• Periodic accuracy audits of existing content

• Incorrect JavaScript behavior claims
• Outdated information (pre-ES6 patterns presented as current)
• Code examples that don't produce stated outputs
• Broken or misleading external resource links
• Common misconceptions stated as fact
• Browser-specific behavior presented as universal
• Inaccurate API descriptions

---

Follow these five phases in order for a complete fact check.

Phase 1: Code Example Verification

Every code example in the concept page must be verified for accuracy.

#### Step-by-Step Process

1. Identify all code blocks in the document
2. For each code block:

- Read the code and any output comments (e.g., // "string")

- Mentally execute the code or test in a JavaScript environment

- Verify the output matches what's stated in comments

- Check that variable names and logic are correct

1. For "wrong" examples (marked with ❌):

- Verify they actually produce the wrong/unexpected behavior

- Confirm the explanation of why it's wrong is accurate

1. For "correct" examples (marked with ✓):

- Verify they work as stated

- Confirm they follow current best practices

1. Run project tests:

```bash

# Run all tests

npm test

# Run tests for a specific concept

npm test -- tests/fundamentals/call-stack/

npm test -- tests/fundamentals/primitive-types/

```

1. Check test coverage:

- Look in /tests/{category}/{concept-name}/

- Verify tests exist for major code examples

- Flag examples without test coverage

#### Code Verification Checklist

| Check | How to Verify |

|-------|---------------|

| console.log outputs match comments | Run code or trace mentally |

| Variables are correctly named/used | Read through logic |

| Functions return expected values | Trace execution |

| Async code resolves in stated order | Understand event loop |

| Error examples actually throw | Test in try/catch |

| Array/object methods return correct types | Check MDN |

| typeof results are accurate | Test common cases |

| Strict mode behavior noted if relevant | Check if example depends on it |

#### Common Output Mistakes to Catch

```javascript

// Watch for these common mistakes:

// 1. typeof null

typeof null // "object" (not "null"!)

// 2. Array methods that return new arrays vs mutate

const arr = [1, 2, 3]

arr.push(4) // Returns 4 (length), not the array!

arr.map(x => x*2) // Returns NEW array, doesn't mutate

// 3. Promise resolution order

Promise.resolve().then(() => console.log('micro'))

setTimeout(() => console.log('macro'), 0)

console.log('sync')

// Output: sync, micro, macro (NOT sync, macro, micro)

// 4. Comparison results

[] == false // true

[] === false // false

![] // false (empty array is truthy!)

// 5. this binding

const obj = {

name: 'Alice',

greet: () => console.log(this.name) // undefined! Arrow has no this

}

```

---

Phase 2: MDN Documentation Verification

All claims about JavaScript APIs, methods, and behavior should align with MDN documentation.

#### Step-by-Step Process

1. Check all MDN links:

- Click each MDN link in the document

- Verify the link returns 200 (not 404)

- Confirm the linked page matches what's being referenced

1. Verify API descriptions:

- Compare method signatures with MDN

- Check parameter names and types

- Verify return types

- Confirm edge case behavior

1. Check for deprecated APIs:

- Look for deprecation warnings on MDN

- Flag any deprecated methods being taught as current

1. Verify browser compatibility claims:

- Cross-reference with MDN compatibility tables

- Check Can I Use for broader support data

#### MDN Link Patterns

| Content Type | MDN URL Pattern |

|--------------|-----------------|

| Web APIs | https://developer.mozilla.org/en-US/docs/Web/API/{APIName} |

| Global Objects | https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/{Object} |

| Statements | https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/{Statement} |

| Operators | https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/{Operator} |

| HTTP | https://developer.mozilla.org/en-US/docs/Web/HTTP |

#### What to Verify Against MDN

| Claim Type | What to Check |

|------------|---------------|

| Method signature | Parameters, optional params, return type |

| Return value | Exact type and possible values |

| Side effects | Does it mutate? What does it affect? |

| Exceptions | What errors can it throw? |

| Browser support | Compatibility tables |

| Deprecation status | Any deprecation warnings? |

---

Phase 3: ECMAScript Specification Compliance

For nuanced JavaScript behavior, verify against the ECMAScript specification.

#### When to Check the Spec

• Edge cases and unusual behavior
• Claims about "how JavaScript works internally"
• Type coercion rules
• Operator precedence
• Execution order guarantees
• Claims using words like "always", "never", "guaranteed"

#### How to Navigate the Spec

The ECMAScript specification is at: https://tc39.es/ecma262/

| Concept | Spec Section |

|---------|--------------|

| Type coercion | Abstract Operations (7.1) |

| Equality | Abstract Equality Comparison (7.2.14), Strict Equality (7.2.15) |

| typeof | The typeof Operator (13.5.3) |

| Objects | Ordinary and Exotic Objects' Behaviours (10) |

| Functions | ECMAScript Function Objects (10.2) |

| this binding | ResolveThisBinding (9.4.4) |

| Promises | Promise Objects (27.2) |

| Iteration | Iteration (27.1) |

#### Spec Verification Examples

```javascript

// Claim: "typeof null returns 'object' due to a bug"

// Spec says: typeof null → "object" (Table 41)

// Historical context: This is a known quirk from JS 1.0

// Verdict: ✓ Correct, though calling it a "bug" is slightly informal

// Claim: "Promises always resolve asynchronously"

// Spec says: Promise reaction jobs are enqueued (27.2.1.3.2)

// Verdict: ✓ Correct - even resolved promises schedule microtasks

// Claim: "=== is faster than =="

// Spec says: Nothing about performance

// Verdict: ⚠️ Needs nuance - this is implementation-dependent

```

---

Phase 4: External Resource Verification

All external links (articles, videos, courses) must be verified.

#### Step-by-Step Process

1. Check link accessibility:

- Click each external link

- Verify it loads (not 404, not paywalled)

- Note any redirects to different URLs

1. Verify content accuracy:

- Skim the resource for obvious errors

- Check it's JavaScript-focused (not C#, Python, Java)

- Verify it's not teaching anti-patterns

1. Check publication date:

- For time-sensitive topics (async, modules, etc.), prefer recent content

- Flag resources from before 2015 for ES6+ topics

1. Verify description accuracy:

- Does our description match what the resource actually covers?

- Is the description specific (not generic)?

#### External Resource Checklist

| Check | Pass Criteria |

|-------|---------------|

| Link works | Returns 200, content loads |

| Not paywalled | Free to access (or clearly marked) |

| JavaScript-focused | Not primarily about other languages |

| Not outdated | Post-2015 for modern JS topics |

| Accurate description | Our description matches actual content |

| No anti-patterns | Doesn't teach bad practices |

| Reputable source | From known/trusted creators |

#### Red Flags in External Resources

• Uses var everywhere for ES6+ topics
• Uses callbacks for content about Promises/async
• Teaches jQuery as modern DOM manipulation
• Contains factual errors about JavaScript
• Video is >2 hours without timestamp links
• Content is primarily about another language
• Uses deprecated APIs without noting deprecation

---

Phase 5: Technical Claims Audit

Review all prose claims about JavaScript behavior.

#### Claims That Need Verification

| Claim Type | How to Verify |

|------------|---------------|

| Performance claims | Need benchmarks or caveats |

| Browser behavior | Specify which browsers, check MDN |

| Historical claims | Verify dates/versions |

| "Always" or "never" statements | Check for exceptions |

| Comparisons (X vs Y) | Verify both sides accurately |

#### Red Flags in Technical Claims

• "Always" or "never" without exceptions noted
• Performance claims without benchmarks
• Browser behavior claims without specifying browsers
• Comparisons that oversimplify differences
• Historical claims without dates
• Claims about "how JavaScript works" without spec reference

#### Examples of Claims to Verify

```markdown

❌ "async/await is always better than Promises"

→ Verify: Not always - Promise.all() is better for parallel operations

❌ "JavaScript is an interpreted language"

→ Verify: Modern JS engines use JIT compilation

❌ "Objects are passed by reference"

→ Verify: Technically "passed by sharing" - the reference is passed by value

❌ "=== is faster than =="

→ Verify: Implementation-dependent, not guaranteed by spec

✓ "JavaScript is single-threaded"

→ Verify: Correct for the main thread (Web Workers are separate)

✓ "Promises always resolve asynchronously"

→ Verify: Correct per ECMAScript spec

```

---

Watch for these misconceptions being stated as fact.

Type System Misconceptions

| Misconception | Reality | How to Verify |

|---------------|---------|---------------|

| typeof null === "object" is intentional | It's a bug from JS 1.0 that can't be fixed for compatibility | Historical context, TC39 discussions |

| JavaScript has no types | JS is dynamically typed, not untyped | ECMAScript spec defines types |

| == is always wrong | == null checks both null and undefined, has valid uses | Many style guides allow this pattern |

| NaN === NaN is false "by mistake" | It's intentional per IEEE 754 floating point spec | IEEE 754 standard |

Function Misconceptions

| Misconception | Reality | How to Verify |

|---------------|---------|---------------|

| Arrow functions are just shorter syntax | They have no this, arguments, super, or new.target | MDN, ECMAScript spec |

| var is hoisted to function scope with its value | Only declaration is hoisted, not initialization | Code test, MDN |

| Closures are a special opt-in feature | All functions in JS are closures | ECMAScript spec |

| IIFEs are obsolete | Still useful for one-time initialization | Modern codebases still use them |

Async Misconceptions

| Misconception | Reality | How to Verify |

|---------------|---------|---------------|

| Promises run in parallel | JS is single-threaded; Promises are async, not parallel | Event loop explanation |

| async/await is different from Promises | It's syntactic sugar over Promises | MDN, can await any thenable |

| setTimeout(fn, 0) runs immediately | Runs after current execution + microtasks | Event loop, code test |

| await pauses the entire program | Only pauses the async function, not the event loop | Code test |

Object Misconceptions

| Misconception | Reality | How to Verify |

|---------------|---------|---------------|

| Objects are "passed by reference" | References are passed by value ("pass by sharing") | Reassignment test |

| const makes objects immutable | const prevents reassignment, not mutation | Code test |

| Everything in JavaScript is an object | Primitives are not objects (though they have wrappers) | typeof tests, MDN |

| Object.freeze() creates deep immutability | It's shallow - nested objects can still be mutated | Code test |

Performance Misconceptions

| Misconception | Reality | How to Verify |

|---------------|---------|---------------|

| === is always faster than == | Implementation-dependent, not spec-guaranteed | Benchmarks vary |

| for loops are faster than forEach | Modern engines optimize both; depends on use case | Benchmark |

| Arrow functions are faster | No performance difference, just different behavior | Benchmark |

| Avoiding DOM manipulation is always faster | Sometimes batch mutations are slower than individual | Depends on browser, use case |

---

Running the project's test suite is a key part of fact-checking.

Test Commands

```bash

# Run all tests

npm test

# Run tests in watch mode

npm run test:watch

# Run tests with coverage

npm run test:coverage

# Run tests for specific concept

npm test -- tests/fundamentals/call-stack/

npm test -- tests/fundamentals/primitive-types/

npm test -- tests/fundamentals/value-reference-types/

npm test -- tests/fundamentals/type-coercion/

npm test -- tests/fundamentals/equality-operators/

npm test -- tests/fundamentals/scope-and-closures/

```

Test Directory Structure

```

tests/

├── fundamentals/ # Concepts 1-6

│ ├── call-stack/

│ ├── primitive-types/

│ ├── value-reference-types/

│ ├── type-coercion/

│ ├── equality-operators/

│ └── scope-and-closures/

├── functions-execution/ # Concepts 7-8

│ ├── event-loop/

│ └── iife-modules/

└── web-platform/ # Concepts 9-10

├── dom/

└── http-fetch/

```

When Tests Are Missing

If a concept doesn't have tests:

1. Flag this in the report as "needs test coverage"
2. Manually verify code examples are correct
3. Consider adding tests as a follow-up task

---

Primary Sources

| Resource | URL | Use For |

|----------|-----|---------|

| MDN Web Docs | https://developer.mozilla.org | API docs, guides, compatibility |

| ECMAScript Spec | https://tc39.es/ecma262 | Authoritative behavior |

| TC39 Proposals | https://github.com/tc39/proposals | New features, stages |

| Can I Use | https://caniuse.com | Browser compatibility |

| Node.js Docs | https://nodejs.org/docs | Node-specific APIs |

| V8 Blog | https://v8.dev/blog | Engine internals |

Project Resources

| Resource | Path | Use For |

|----------|------|---------|

| Test Suite | /tests/ | Verify code examples |

| Concept Pages | /docs/concepts/ | Current content |

| Run Tests | npm test | Execute all tests |

---

Use this template to document your findings.

```markdown

# Fact Check Report: [Concept Name]

File: /docs/concepts/[slug].mdx

Date: YYYY-MM-DD

Reviewer: [Name/Claude]

Overall Status: ✅ Verified | ⚠️ Minor Issues | ❌ Major Issues

---

[2-3 sentence summary of findings. State whether the page is accurate overall and highlight any critical issues.]

Tests Run: Yes/No

Test Results: X passing, Y failing

External Links Checked: X/Y valid

---

| # | Description | Line | Status | Notes |

|---|-------------|------|--------|-------|

| 1 | [Brief description] | XX | ✅/⚠️/❌ | [Notes] |

| 2 | [Brief description] | XX | ✅/⚠️/❌ | [Notes] |

| 3 | [Brief description] | XX | ✅/⚠️/❌ | [Notes] |

Code Issues Found

#### Issue 1: [Title]

Location: Line XX

Severity: Critical/Major/Minor

Current Code:

```javascript

// The problematic code

```

Problem: [Explanation of what's wrong]

Correct Code:

```javascript

// The corrected code

```

---

| Claim | Location | Source | Status | Notes |

|-------|----------|--------|--------|-------|

| [Claim made] | Line XX | MDN/Spec | ✅/⚠️/❌ | [Notes] |

MDN Link Status

| Link Text | URL | Status |

|-----------|-----|--------|

| [Text] | [URL] | ✅ 200 / ❌ 404 |

Specification Discrepancies

[If any claims don't match the ECMAScript spec, detail them here]

---

| Resource | Type | Link | Content | Notes |

|----------|------|------|---------|-------|

| [Title] | Article/Video | ✅/❌ | ✅/⚠️/❌ | [Notes] |

Broken Links

1. Line XX: [URL] - 404 Not Found
2. Line YY: [URL] - Domain expired

Content Concerns

1. [Resource name]: [Concern - e.g., outdated, wrong language, anti-patterns]

Description Accuracy

| Resource | Description Accurate? | Notes |

|----------|----------------------|-------|

| [Title] | ✅/❌ | [Notes] |

---

| Claim | Location | Verdict | Notes |

|-------|----------|---------|-------|

| "[Claim]" | Line XX | ✅/⚠️/❌ | [Notes] |

Claims Needing Revision

1. Line XX: "[Current claim]"

- Issue: [What's wrong]

- Suggested: "[Revised claim]"

---

Test File: /tests/[category]/[concept]/[concept].test.js

Tests Run: XX

Passing: XX

Failing: XX

Failing Tests

| Test Name | Expected | Actual | Related Doc Line |

|-----------|----------|--------|------------------|

| [Test] | [Expected] | [Actual] | Line XX |

Coverage Gaps

Examples in documentation without corresponding tests:

• [ ] Line XX: [Description of untested example]
• [ ] Line YY: [Description of untested example]

---

Critical (Must Fix Before Publishing)

1. [Issue title]

- Location: Line XX

- Problem: [Description]

- Fix: [How to fix]

Major (Should Fix)

1. [Issue title]

- Location: Line XX

- Problem: [Description]

- Fix: [How to fix]

Minor (Nice to Have)

1. [Issue title]

- Location: Line XX

- Suggestion: [Improvement]

---

1. [Priority 1]: [Specific actionable recommendation]
2. [Priority 2]: [Specific actionable recommendation]
3. [Priority 3]: [Specific actionable recommendation]

---

• [ ] All code examples verified for correct output
• [ ] All MDN links checked and valid
• [ ] API descriptions match MDN documentation
• [ ] ECMAScript compliance verified (if applicable)
• [ ] All external resource links accessible
• [ ] Resource descriptions accurately represent content
• [ ] No common JavaScript misconceptions found
• [ ] Technical claims are accurate and nuanced
• [ ] Project tests run and reviewed
• [ ] Report complete and ready for handoff

---

Verified by: [Name/Claude]

Date: YYYY-MM-DD

Recommendation: ✅ Ready to publish | ⚠️ Fix issues first | ❌ Major revision needed

```

---

```bash

# Run all tests

npm test

# Run specific concept tests

npm test -- tests/fundamentals/call-stack/

# Check for broken links (if you have a link checker)

# Install: npm install -g broken-link-checker

# Run: blc https://developer.mozilla.org/... -ro

# Quick JavaScript REPL for testing

node

> typeof null

'object'

> [1,2,3].map(x => x * 2)

[ 2, 4, 6 ]

```

---

When fact-checking a concept page:

1. Run tests first — npm test catches code errors automatically
2. Verify every code example — Output comments must match reality
3. Check all MDN links — Broken links and incorrect descriptions hurt credibility
4. Verify external resources — Must be accessible, accurate, and JavaScript-focused
5. Audit technical claims — Watch for misconceptions and unsupported statements
6. Document everything — Use the report template for consistent, thorough reviews

Remember: Our readers trust us to teach them correct JavaScript. A single piece of misinformation can create confusion that takes years to unlearn. Take fact-checking seriously.