Challenge 1: Babel vs. tsc, and Why Projects Split the Two Jobs — Possible Solution ==================================================================== WHAT BABEL DOES ------------------------------ Per this chapter's own example, Babel mechanically rewrites modern JavaScript syntax (arrow functions, optional chaining, nullish coalescing) into an older, behaviorally equivalent form an older browser can run. It has no understanding of TypeScript's own type system at all — per the chapter's own wording, it "can strip type syntax mechanically, but it never actually checks whether the types are used correctly." WHAT TSC DOES ------------------------------ Per this chapter's own example, tsc does two genuinely separate things at once: it TYPE-CHECKS the code (catching real type errors before anything runs), and it STRIPS the type annotations entirely to produce plain JavaScript. Type-checking is tsc's actual core job — not an incidental side effect of stripping syntax the way it might seem. THE REAL DIFFERENCE ------------------------------ Babel's work is purely mechanical syntax transformation, requiring no real understanding of what the code MEANS. tsc's work requires genuinely understanding the code's types well enough to determine whether they're used correctly — a fundamentally more involved kind of analysis than simply recognizing and rewriting syntax patterns. WHY PROJECTS OFTEN SPLIT THE TWO JOBS ------------------------------ Per this chapter's own explanation, full type-checking is comparatively slow, specifically because it requires that deeper kind of analysis rather than simple pattern-based rewriting. Since fast build times matter for developer experience (a theme this course returns to directly in Ch.5/Ch.6), many real projects run tsc ONLY for type-checking — often as a separate CI step or editor integration — while using a faster tool (Babel, or esbuild/SWC from Ch.6) purely for the actual transpilation and bundling that needs to happen quickly, every time a file changes. This lets a project get both genuine type safety AND fast rebuilds, by assigning each job to the tool actually suited for it, rather than making one slower tool do both. WHY THIS WORKS AS AN ANSWER ------------------------------ It states precisely what each tool does using the chapter's own examples, identifies the deeper kind-of-work difference (mechanical rewriting vs. genuine type analysis), and explains the practical motivation (type-checking's own real slowness) behind splitting the two jobs across separate tools.