Why TypeScript Exists and What It Runs On
The class of bug types catch before your program ever runs, what the compiler does and pointedly does not do, and where the code you write actually executes.
The class of bug types catch before your program ever runs, what the compiler does and pointedly does not do, and where the code you write actually executes.
A shopping site charges a customer £1,299 for an item priced at
£12.99. The code multiplied a quantity by a price, and the price
had arrived from a form as the text "12.99" rather than as the
number 12.99. Multiplying text by a number is the sort of thing
a computer will happily attempt, and the result was wrong in a
way nobody noticed until the refunds started.
That bug is preventable, and preventing it is what this language is for. By the end of this lesson you will know what a program is, what makes TypeScript different from most languages you may have heard of, and — because it surprises everyone — what actually runs when you run one. No previous programming experience is assumed.
A program is a list of instructions precise enough that a machine can carry them out without asking you anything.
That last part is the difficulty. Ask a colleague to "work out the total", and they will apply judgement — they know a price is a number, that a quantity of zero means no charge, and that something looks wrong if the answer is a hundred times too big. A computer knows none of that. It does exactly what you wrote, very fast, and if what you wrote was wrong it does the wrong thing to every customer.
A programming language is the notation you write those instructions in. It exists because the operations a processor actually performs are far too small and too numerous to write by hand.
Every value a program handles is a kind of thing. 12.99 is a
number. "12.99" is text that happens to contain digits. The
quotes are the difference, and they matter enormously — you can
multiply numbers and you cannot meaningfully multiply text.
A type is the name for a kind of value. Saying that something is a number is a claim, and TypeScript checks your claims before the program runs.
let price: number = 12.99;
let quantity: number = 100;
let total = price * quantity; // 1299: number says what kind of value each name holds. Now try to
break it:
let price: number = "12.99";
// ~~~~~
// Type 'string' is not assignable to type 'number'.That message appears as you type it, in your editor, before you have run anything and before any customer is involved. The opening bug becomes a red underline.
That is the entire proposition. A whole category of mistake — using a value as the wrong kind of thing — is caught by a machine that reads your code rather than by a person reading a bug report.
Here is the part that surprises people, and it explains a great deal later.
TypeScript is a checker and a translator, not a thing that runs programs. Give it your file and it does two jobs:
It checks your claims. Every type you wrote, and many it worked out for itself, are verified for consistency. Anything inconsistent is reported.
It removes the types. The output is the same program with every annotation deleted.
let price: number = 12.99;
let total = price * 100;becomes, roughly:
let price = 12.99;
let total = price * 100;That output is JavaScript — the language that browsers and servers actually execute. TypeScript is the language you write; JavaScript is what runs. Nothing about your types exists while the program is running. They were instructions to the checker, and the checker has finished.
Picture a proofreader rather than a translator. They read your manuscript, mark every inconsistency, and hand back the text with their marks erased. The marks changed what you wrote; they are not in the published book.
You write TypeScript
With type annotations, and many more types the compiler works out for itself.
The compiler checks every claim
Inconsistencies are reported here — in your editor, as you type, before anything has run.
It deletes the types and emits JavaScript
The same program, with every annotation removed.
Node or a browser runs the JavaScript
The checker finished hours ago and is not present. This is where data from forms, files and other services arrives.
That last step has a consequence worth carrying from the very beginning: types cannot protect you from data that arrives while the program runs. Handling that is a real subject, and it has its own lesson later.
Two places, and you will use both.
Where JavaScript began.
Every browser can run it, which is why the buttons and forms on a web page do things.
JavaScript outside a browser.
A program you install on a computer. This is how servers, command-line tools and scripts get written.
This course uses Node, because it needs no web page and shows output directly in a terminal.
Writing types costs a few characters per line. Three things come back.
Mistakes are found where you made them. A wrong value is reported at the line that produced it, not three functions later, in terms of a symptom.
Your editor knows what things are. Type a dot after a name and you get the list of what that value can do — because the editor knows what it is. Misspell one and it says so immediately. This is the benefit people notice first and the one that is hardest to give up.
The types are documentation that cannot go stale. A comment saying "price is a number" may be wrong. A type saying so is checked on every build.
There is a fourth that matters later: changing code becomes safe. Rename something, change what a function returns, and every place that no longer fits is reported at once. In a large program that is the difference between a change you make and one you avoid.
WHAT THINGS ARE
program instructions precise enough to need no judgement
language the notation you write them in
value a piece of data: 12.99, "hello", true
type the name for a kind of value
compiler checks your types, then removes them
JavaScript what the compiled output is, and what runs
Node runs JavaScript outside a browser
browser runs JavaScript for a web page
THE CORE FACT
quotes decide the kind:
12.99 a number - you can do arithmetic with it
"12.99" text - you cannot
let price: number = 12.99; a claim
let price: number = "12.99"; an error, before it runs
WHAT THE COMPILER DOES
1 checks every claim, and everything it inferred
2 deletes the types
3 emits JavaScript
so: types do NOT exist while the program runs
and: they cannot check data that ARRIVES at runtime
(forms, files, other services - a later lesson)
WHAT YOU GET
mistakes reported where you made them
an editor that knows what everything is
documentation that cannot go stale
changes that are safe to make in a large programYou now know what a type is, why claiming one is useful, and the single most misunderstood fact about this language: the compiler checks and then gets out of the way, leaving something else to run your code. Every later lesson rests on those two ideas.
Next is Setting Up and Running Your First File, which takes you from nothing to a running, type-checked program on your own machine — the tools, a real project folder, and what each file that appears is for.
Before you move on, there is nothing to install and one thing
worth doing. Open the TypeScript Playground in a browser, type
let price: number = "12.99"; and watch the error appear under
it. Then remove the quotes and watch it go. Seeing the checker
object while you type, before anything has run, is the whole
idea of this language in about fifteen seconds.