TypeScript's Story & Ecosystem

TypeScript went from a 2012 Microsoft side project to the default way the industry writes JavaScript — and knowing why it won tells you a lot about how to use it well. This is the short version of the story: the design bet that paid off, how versions ship, and the ecosystem you're joining.

2012: "describe JavaScript as it is"

TypeScript shipped publicly on October 1, 2012, led by Anders Hejlsberg — the language designer behind Turbo Pascal, Delphi, and C#. Microsoft's own teams were drowning in large JavaScript codebases, and the existing escape hatches (Google's Dart, various compile-to-JS languages) all made the same move: replace JavaScript with something else.

Hejlsberg's team made the opposite bet, and it's the reason you're here instead of there:

• A superset, not a replacement. Every JavaScript program is already a valid TypeScript program. Adoption could start with renaming a file.
• Describe JavaScript as it is. Instead of forcing JS into a class-based mold, the type system was built to describe the wild patterns real JS already used — objects compared by shape (structural typing, lesson 5.4), functions passed around freely, values that are "a string or a number."
• Erase and get out of the way. Compile output is clean JavaScript with the types removed — no runtime library, no lock-in. You met this in 1.1; you'll see it in 1.5.

The turning point came in 2015 when Google chose TypeScript for Angular 2. After that: VS Code (itself written in TypeScript), React codebases at scale, and by the late 2010s survey after survey showing most professional JavaScript developers writing TS. Today the top of npm is overwhelmingly typed, and "we don't use TypeScript" is the position that needs defending.

How TypeScript ships

TypeScript versions release roughly quarterly — 5.5, 5.6, 5.7… — each adding checker improvements and new type-system tools. There's no "TypeScript 5 vs TypeScript 4" cliff to worry about; the language evolves in small, steady steps, and code from years ago almost always still compiles.

The playground on these pages runs TypeScript 5.9, the same compiler line you'd install today.

The ecosystem you're joining

Three names you'll meet constantly:

• npm — the package registry TypeScript lives on. The compiler itself is the typescript package; you'll install it per-project in 1.4.
• DefinitelyTyped — a giant community repository of type definitions for JavaScript packages that don't ship their own. When a library is plain JS, npm install -D @types/that-library gives the checker its shape (lesson 9.3 covers how this works).
• The TypeScript Playground — typescriptlang.org/play, the official zero-setup sandbox. Great for sharing bug reproductions and testing ideas; the playgrounds on these pages give you the same run-and-check loop without leaving the lesson.

And the tooling dividend: because the checker understands your whole program, editors built on it (VS Code above all) give you autocomplete, go-to-definition, and safe renames that plain JavaScript simply cannot match. Half of what people call "the TypeScript experience" is really the editor experience the type information unlocks.

Try it — a superset means zero annotations required

This file contains no type annotations at all — it's plain JavaScript, which makes it valid TypeScript. Run it, then try the break-it line: even with zero annotations, the checker inferred everything.

That's the superset bet in one playground: your existing JavaScript knowledge is not a prerequisite to discard — it's the foundation. The type layer starts working the moment you rename .js to .ts, before you write a single annotation.

Next lesson is a fast refresher of exactly the JavaScript this course leans on — then we set up a real workshop and compile something.

Checkpoint ✦

Answer all three to mark this lesson complete