The problem first, the tool second
We finished Part 2 with a full, working vanilla app. Now — Part 3, and its hinge: the problem first, the tool second.
The problem. Your working code is quietly full of latent bugs. Let's point the TypeScript compiler at it and see what it rejects — these are real lines from our vanilla code:
const src = pic.hdurl;
// → TS2551: Property 'hdurl' does not exist on type 'Apod'.
// Property 'hdurl' does not exist on type 'ApodVideo'.
const credit = `© ${pic.copyright.trim()}`;
// → TS18048: 'pic.copyright' is possibly 'undefined'.
Both lines ran fine in the vanilla app. But only because someone remembered to write the guards: pic.hdurl || pic.url (because videos have no hdurl) and if (pic.copyright) (because public-domain images have no owner). Nothing enforced it. Skip the guard and the app breaks the day APOD returns a video, or an image with no copyright. That's lesson 6's media_type bug and lesson 14's detail.js optional fields — now caught automatically.
That's the pitch: TypeScript doesn't make you a better programmer — it turns "I forgot a guard" from a runtime crash into a compile error you can't ignore.
Then — the tool. TypeScript can't run in a browser: the browser doesn't understand .ts. The types have to be stripped out (compiled to .js) before running — and that needs a compiler (tsc) and a bundler (Vite), which need Node and npm. That's why the tooling appears here and nowhere earlier.
And that's the answer to lesson 1. There we said: "JavaScript needs no build step." That was true — and 14 lessons proved it. What changed? We added types, and types are a language addition the browser doesn't understand. The tooling isn't ceremony; it's the price of the types, paid once you've decided they're worth it.