Sometimes it might even appear in blog posts that some new syntax is TypeScript specific (e.g. optional chaining), whereas it's actually just syntax coming from an ECMAScript proposal that often has already been supported by both Chrome and Babel for quite some time.
As a matter of fact, nearly all the syntax that is TypeScript specific does "not" allow you to actually program anything at runtime (e.g. interfaces, type annotations and conditional types), but solely exists to assist the static type checker of TypeScript at compile time. Exceptions to this rule are the syntactic sugar from the early days of TypeScript, being enums, constructor parameter properties and decorators.
In my opinion TypeScript is best to be seen as a static type checker. And the TypeScript specific syntax extensions are nothing more than a means to end.
let foo = 42; // foo is now a number foo = "bar"; // foo is now a string foo = true; // foo is now a boolean
- variables are not directly associated to any value type
- variables can be assigned (and re-assigned) values of all types
- class field
- return value
Statically typed TypeScript
In TypeScript everything that ‘holds a value’ has an associated type. And whenever a value is assigned with an incorrect type, TypeScript will prohibit this through a compiler error.
Let’s assume that we intended the variable
foo to be a
number, then in
TypeScript we can add a type annotation to specify that:
let foo: number = 42;
In that case TypeScript will give compilation errors on lines 2 and 3:
foo = "bar"; // ~~~ TS2322: Type 'string' is not assignable to type 'number'. foo = true; // ~~~ TS2322: Type 'boolean' is not assignable to type 'number'.
But in this case we did not need to explicitly specify the
number type, since
TypeScript can infer in based on the assigned initial value of
let foo = 42; // %inferred-type: number
How to best describe TypeScript
Traditionally TypeScript was often described as
easily demonstrated by the fact that converting code to TypeScript takes nothing
more than changing the file extension from
In order to better describe what TypeScript is, the typescriptlang.org website no longer describes TypeScript as being superset, but nowadays instead describes it as:
Although the description above of TypeScript is much better, in my opinion it's still lacking since it still fails to describe the actual purpose of TypeScript. Therefore, I personally much more prefer the description of TypeScript made by Tero Parviainen in its blog post about Angular 2:
It doesn't really make sense to compare it to other languages.
In order to better understand TypeScript, I decided to start searching for a better matching analogy than being "typed superset" or a "fastened seat belt".
Without being an expert on the matter, it appeared to me that the ancient Chinese philosophy of Yin and Yang might be a matching analogy. And after a quick search, I found the following tweet that seems to confirm it:
Looking at Wikipedia, Yin-Yang is being described as follows:
…, yin and yang is a concept of dualism, describing how seemingly opposite or contrary forces may actually be complementary, interconnected, …
The dualism of Yin-Yang is also applicable when developing in TypeScript:
TypeScript relate to each other while using TypeScript.
But even though I personally develop fulltime using TypeScript, I prefer seeing
Run-time vs compile-time
- TypeScript: checks types at compile-time
Basically, TypeScript is nothing more than an advanced type checker.
Besides some syntactic sugar from its early days (e.g. enums), the TypeScript syntax extensions will be completely removed (type erasure) at compile time.
Therefore, it will have no runtime impact whatsoever.
Differences in how they are typed
- TypeScript: statically typed
(and all other things that ‘holds a value’) does not have a type associated with
ECMAScript proposals support
- TypeScript: late support for ECMAScript proposal (stage 3 / 4)
Typically, new ECMAScript proposals are introduced once they reach stage 3 or 4, but sometimes new features are forgotten and only added to TypeScript after an issue is being logged.
Transpilation of modern / future ECMAScript syntax
- TypeScript: handled by either the TypeScript compiler or Babel.js
Intrinsic (built-in) objects
- TypeScript: adds typings for built-in (intrinsic) objects
(intrinsic) objects like
NOTE: TypeScript does however offer a few built-in mapped types, but these do not have impact at runtime due to type erasure (explained later in this blog post)
Area of innovation
- TypeScript: innovates in the type space
Type System of TypeScript
As mentioned before, TypeScript is basically nothing more than a compile-time
However, for the type checker to function it needs to have access to the type related information of the code that needs to be checked.
…, a type system is a logical system comprising a set of rules that assigns a property called a type to the various constructs of a computer program, such as variables, expressions, functions or modules.
The aim of the Type System of TypeScript is to model the runtime behaviour of
const x = 4 + "2"; // evaluates to ‘42’ const y = "4" + 2; // evaluates to ‘42’
However, to prevent bugs (to some degree), TypeScript does prohibit some quirky
const x = null + 42; // evaluates to 42 in JS // ~~~~~~~~~ TS2365: Operator '+' cannot be applied to types 'null' and '42'. const y =  + 42; // evaluates to ‘42’ in JS // ~~~~~~~ TS2365: Operator '+' cannot be applied to types 'undefined' and 'number'. alert("foo", "bar"); // alerts ‘foo’ in JS // ~~~~~ TS2554: Expected 0-1 arguments, but got 2.
It is an explicit design choice of TypeScript to have zero impact at runtime.
Therefore, type checking is only done at compile time.
To have zero impact in bundle size, TypeScript performs Type erasure during
compilation and removes all type information during compilation.
Personally, I find the best illustration of Type erasure, to be the TypeScript support of Babel.js that basically does nothing more than removing all TypeScript specific syntax from your code.
A hopefully changed perspective on TypeScript
Now that this blog post is nearly coming to an end, I hope to have changed your
Even though the TypeScript syntax extensions might make your code a bit more
verbose, they also make the types explicit in your code.
Whereas otherwise the types that exist at runtime would only exist implicitly in the code or as, most likely outdated, documentation.
TS Yin-Yang: to be continued…
I'm really interested to hear if you found this blog post useful and / or if you would like to read more TS Yin-Yang blog posts in the future. You can reach me on Twitter at @EmilVanGalen.
But for now… let’s just say… to be continued.
(In Dutch) Online Divotion lunch sessie over TS Yin-Yang
Op woensdag 3 maart organiseert Divotion de digitale lunchsessie: TypeScript Yin-Yang van 12:00u tot 13:30u.
Meer informatie over het programma en hoe aan te melden is hier te vinden.