Why would anyone add rules to JavaScript on purpose?

The full story

The episode's narration, word for word. Numbers link to the sources below; timestamps play that moment.

The question 0:00

Last time, we saw Deno run a language called TypeScript, straight out of the box ¹. TypeScript is JavaScript with extra rules ². Rules usually slow you down, and JavaScript is famously relaxed about what you can write ³. Yet millions of programmers now choose those rules on purpose ^4,5. So what do the rules actually do, and why would anyone want them?

A very specific problem 0:26

On the first of October 2012, Microsoft announced a new programming language ^6,7. Its launch post said it solved a very specific problem: getting JavaScript development to scale ⁶. JavaScript had been designed for small scripts on web pages, but people were now writing applications of unprecedented size with it ⁶. Some teams, including some inside Microsoft, were already bolting on extra tools to check their code ⁶.

The man from Turbo Pascal 0:56

The language was TypeScript. Its best-known designer is Anders Hejlsberg, working with colleagues including Luke Hoban ^7,8,9. Hejlsberg is a Danish engineer who built Turbo Pascal, a famously fast compiler released in 1983 ^10,11. He then led the design of Delphi, joined Microsoft in 1996, and became the lead architect of C sharp ¹⁰. Both Pascal and C sharp check most of their rules before a program runs ^12,13. So what are those rules about?

What's a type? 1:32

A type is simply what kind of value something is ¹⁴. A number. A piece of text, which programmers call a string. True or false. Some operations only make sense for some types ¹⁴. You can turn text into capital letters, but you can't do that to the number forty-two. Think of a type as the label on a jar, saying what's inside. The question is when anyone reads the label.

Finding out the hard way 2:02

JavaScript is a dynamic language: any variable can hold any type, and the types are only checked as each line runs ³. Here's a real example, run for this episode. A function shouts whatever words it's given, in capitals, and we hand it the number forty-two by mistake. JavaScript happily starts the program and prints "starting". Only when it reaches that line does it stop, with a type error saying the upper-case operation isn't available ¹⁴. If that line only runs on Tuesdays, you find out on a Tuesday.

Checking first 2:40

Now add one small label: words, colon, string ¹⁵. That's a type annotation, a note saying this function expects text ¹⁵. Run the TypeScript checker, and it reads the whole file without running a single line ^14,1. It reports that a number can't go where a string is expected, and points at the forty-two. That's static type checking: static means by reading the code, before it runs ¹⁶. Dynamic means while it runs ¹⁶.

The launch-day bug 3:12

Microsoft's own launch post made the same point ⁶. Its example had a bug the author admitted he hadn't caught while writing, "due to the dynamic nature of JavaScript" ⁶. One type annotation, and the compiler flagged it before the code ever ran ⁶. Not everyone was sold. One reader asked, the same day, what the point was of enforcing types if the JavaScript it produced didn't check them ⁶. That turns out to be the key question, and we'll come back to it.

The quiet bug 3:44

A crash is the lucky case. JavaScript often doesn't crash at all ¹⁴. Here's a real TypeScript file that makes a gig poster from a band name and a ticket price. Look closely: the line that builds the poster asks for "prise", spelled wrong. Node will run TypeScript files, but it doesn't check them ¹⁷. So it runs, finishes without complaint, and prints: tickets, dollar sign, undefined ¹⁷. In JavaScript, asking for something that isn't there just gives you the value undefined ¹⁴.

Did you mean price? 4:20

Now run the checker on the same file ¹. It knows that a gig has a band and a price, because the first line says so ¹⁵. So it stops on that line and says: property "prise" does not exist on type Gig, did you mean "price"? Fix the spelling, the check passes, and the poster says twenty-five dollars. Nobody had to spot it on a live website first.

How many bugs, really? 4:47

So how much does this matter in real projects? In 2017, researchers from University College London and Microsoft Research tested it ¹⁶. They took four hundred real bugs that had been fixed in public JavaScript projects on GitHub ¹⁶. For each one, they went back to the code just before the fix, added type labels by hand, and asked whether a checker would have complained ¹⁶. TypeScript flagged sixty of the four hundred, fifteen percent ¹⁶. The authors call that conservative, because these were bugs that had already slipped past testing and review ¹⁶.

And the other eighty-five 5:25

Turn that around, and most of the bugs weren't type mistakes at all ¹⁶. The study's biggest group was code that did the wrong thing correctly: it followed the rules, it just didn't do what it was supposed to ¹⁶. Here's where the jar labels break as an analogy. A checker can confirm the labels match. It can't tell you whether you put the right thing in the jar. So types catch one kind of mistake, and they don't replace testing ¹⁶.

Start with what you have 5:54

Here's the clever part of Microsoft's design. TypeScript is a superset of JavaScript: JavaScript's syntax is already legal TypeScript ^2,6. So you can start with the JavaScript you already have and add labels one at a time, wherever they help most ⁶. Often you don't write them at all, because the checker works types out for itself ¹⁵. And there's an escape hatch, a type called "any", which switches checking off for that value ¹⁵.

Rules that vanish 6:23

Now back to that launch-day question. When TypeScript has finished checking, it erases the types ². What's left is plain JavaScript, with no type information at all ². Node's own type stripper shows it literally: it replaces the type labels with blank spaces and changes nothing else ¹⁷. Run what's left, and you get exactly the same output. By design, TypeScript never changes how your program behaves, and adds no run-time cost ^14,18.

The inspector goes home 6:56

So the reader's point was right, and it was deliberate¹⁸. The checking all happens before the program runs ^14,2. Think of a building inspector who checks the plans, signs off, and goes home before anyone moves in. Data arriving later, from a form or another computer, isn't checked by TypeScript at all ^2,18. And the team chose not to make the checker airtight, aiming for a balance between correctness and getting work done ¹⁸.

Rules as a tool 7:25

Microsoft's pitch in 2012 wasn't only about catching bugs ⁶. Once the code says what everything is, an editor can help: type a name and a dot, and it lists what's inside, or rename something everywhere at once ⁶. That mattered for large teams, where the types act as agreements between people's code ⁶. Version one came out in April 2014, when some TypeScript projects were already over half a million lines ¹⁹.

The case against 7:55

Fair's fair: the rules cost something. Browsers can't run TypeScript as written, so the types have to be stripped out somewhere along the way, and checking is a separate step ^14,17,1. There's more to write and more to learn ¹⁵. And the 2017 study's authors set out the other side's case: dynamic typing suits quick experiments, where you just want something working ¹⁶.

One library says no 8:20

Some well-known programmers have gone the other way. In September 2023, David Heinemeier Hansson, creator of Ruby on Rails, removed TypeScript from a JavaScript library called Turbo ²⁰. He wrote that its "type gymnastics" added "ever so little joy", and that things that should be easy become hard, and things that are hard become "any" ²⁰. He also granted that, by all accounts, TypeScript has been a big success for Microsoft, and that plenty of people love it ²⁰. It's a real trade-off, not a right answer.

Where it stands 8:58

In Stack Overflow's 2025 survey, 43.6 percent of those who answered had done extensive work in TypeScript in the past year, against sixty-six percent for JavaScript ⁴. That's people who answer Stack Overflow surveys, not every programmer. GitHub counts differently: by monthly contributors, TypeScript became its most used language in August 2025, overtaking Python and JavaScript ⁵. GitHub notes that other rankings still put those two higher ⁵.

Faster, in Go 9:32

The TypeScript checker was itself written in TypeScript, until this year ⁷. In March 2025, Hejlsberg announced a rewrite in a language called Go ⁸. In his early tests, checking the code of Microsoft's VS Code editor took seven and a half seconds instead of about seventy-eight ⁸. TypeScript seven shipped in July 2026, and Microsoft says full builds are typically eight to twelve times faster ²¹. That's the checker getting faster, not your program¹⁸.

Types in JavaScript itself? 10:07

Could JavaScript simply grow types of its own? There's a proposal at TC39, the committee behind JavaScript, to let ordinary JavaScript files carry type labels that engines would ignore, like comments ²². It reached Stage 1, meaning the committee thinks it's worth exploring, in March 2022, and it's still there ²². Meanwhile Node and Deno already run TypeScript files by stripping out the types, and leave the checking to you ^17,1.

Why choose the rules 10:38

So why add rules on purpose? Because a checker reads all your code before any of it runs, catching a share of mistakes before they ever reach anyone else ^14,16. Because the labels help editors, and the people who read your code next ^6,16. And because the rules disappear before the program runs, so they cost nothing there ^2,18. GitHub says nearly every major front-end framework, the toolkits for building websites, now starts new projects in TypeScript by default ⁵. So why do so many websites use a framework?

Sources

Every factual claim in the episode is tied to one of these. Spotted an error? Tell us.

1. Deno documentation, "TypeScript support" — docs.deno.com
2. TypeScript Handbook, "TypeScript for the New Programmer" — typescriptlang.org
3. MDN Web Docs, "JavaScript data types and data structures" — developer.mozilla.org
4. Stack Overflow Developer Survey 2025, Technology — survey.stackoverflow.co
5. GitHub Blog, "Octoverse: A new developer joins GitHub every second as AI leads… — github.blog
6. S. Somasegar, "TypeScript: JavaScript Development at Application Scale", Microsoft, 1… — learn.microsoft.com
7. Wikipedia, "TypeScript" (accessed 7 October 2026) — en.wikipedia.org
8. Anders Hejlsberg, "A 10x Faster TypeScript", TypeScript blog, 11 March 2025 — devblogs.microsoft.com
9. Don Syme, "The Early History of F#", Proc. ACM Program. Lang. 4, HOPL, Article 75,… — fsharp.org
10. Wikipedia, "Anders Hejlsberg" (accessed 7 October 2026) — en.wikipedia.org
11. Wikipedia, "Turbo Pascal" (accessed 7 October 2026) — en.wikipedia.org
12. Wikipedia, "Pascal (programming language)" (accessed 7 October 2026; infobox typing… — en.wikipedia.org
13. Wikipedia, "C Sharp (programming language)" (accessed 7 October 2026; infobox typing… — en.wikipedia.org
14. TypeScript Handbook, "The Basics" — typescriptlang.org
15. TypeScript Handbook, "Everyday Types" — typescriptlang.org
16. Zheng Gao, Christian Bird and Earl T. Barr, "To Type or Not to Type: Quantifying… — earlbarr.com
17. Node.js API documentation, "Modules: TypeScript" (type stripping) — nodejs.org
18. TypeScript wiki, "TypeScript Design Goals" — github.com
19. Jonathan Turner, "Announcing TypeScript 1.0", TypeScript blog, 2 April 2014 — devblogs.microsoft.com
20. David Heinemeier Hansson, "Turbo 8 is dropping TypeScript", 6 September 2023 — world.hey.com
21. Daniel Rosenwasser, "Announcing TypeScript 7.0", TypeScript blog, 8 July 2026 — devblogs.microsoft.com
22. TC39, "ECMAScript proposal: Type Annotations" (README and stage-1 proposal list) — github.com

Researched and scripted with AI assistance, fact-checked claim by claim, with synthetic narration and diagrams drawn in code. How we make episodes.