JavaScript Concept Fact Checker

Skill: JavaScript Fact Checker

Use this skill to verify the technical accuracy of concept documentation pages for the 33 JavaScript Concepts project. This ensures we're not spreading misinformation about JavaScript.

When to Use

• 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

What We're Protecting Against

• 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

Fact-Checking Methodology

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

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

   • Verify they actually produce the wrong/unexpected behavior
   • Confirm the explanation of why it's wrong is accurate

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

   • Verify they work as stated
   • Confirm they follow current best practices

5. Run project tests:

   # Run all tests
   npm test
   
   # Run tests for a specific concept
   npm test -- tests/fundamentals/call-stack/
   npm test -- tests/fundamentals/primitive-types/

6. Check test coverage:

   • Look in /tests/{category}/{concept-name}/
   • Verify tests exist for major code examples
   • Flag examples without test coverage

Code Verification Checklist

Common Output Mistakes to Catch

// 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

2. Verify API descriptions:

   • Compare method signatures with MDN
   • Check parameter names and types
   • Verify return types
   • Confirm edge case behavior

3. Check for deprecated APIs:

   • Look for deprecation warnings on MDN
   • Flag any deprecated methods being taught as current

4. Verify browser compatibility claims:

   • Cross-reference with MDN compatibility tables
   • Check Can I Use for broader support data

MDN Link Patterns

What to Verify Against MDN

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/

Spec Verification Examples

// 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

2. 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

3. Check publication date:

   • For time-sensitive topics (async, modules, etc.), prefer recent content
   • Flag resources from before 2015 for ES6+ topics

4. Verify description accuracy:

   • Does our description match what the resource actually covers?
   • Is the description specific (not generic)?

External Resource Checklist

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

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

❌ "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

Common JavaScript Misconceptions

Watch for these misconceptions being stated as fact.

Type System Misconceptions

Function Misconceptions