Rule One: Don't Break JavaScript
The single most important design goal of TypeScript was to be a strict superset of JavaScript. This meant any valid JavaScript code had to be valid TypeScript code. This wasn't just a technical detail; it was the core philosophy. Microsoft, led by C#
designer Anders Hejlsberg, knew that to get millions of JavaScript developers on board, they couldn't force a total rewrite or a completely new way of thinking. The language had to feel like an enhancement, not a replacement. This foundational rule constrained every subsequent design decision. Instead of inventing a whole new language that compiled to JavaScript, they decided to layer features on top of it. This meant avoiding new keywords or syntax that would clash with existing or future JavaScript standards. It had to work with the grain of JavaScript, not against it.
Why the Colon Won the Annotation Game
One of TypeScript's most visible features is its use of a colon to denote a variable's type, like `let name: string;`. This syntax feels natural now, but it was a carefully considered choice. The team needed a way to add type annotations without creating ambiguity for parsers that also had to understand plain JavaScript. If they had used an equals sign, for example, it could be confused with an assignment. The colon-based syntax, `variable: type`, was an elegant solution that was both clear and, crucially, didn't conflict with JavaScript's existing grammar. It allows developers to explicitly state their intent, which in turn enables powerful tooling like autocompletion and error-checking before the code is ever run. This small syntactical choice is a perfect example of TypeScript's pragmatic approach: solve the problem without creating a new one for the JavaScript ecosystem.
It's About the Shape, Not the Name
Another key decision was to use a structural type system rather than a nominal one. In a nominal system, common in languages like Java or C#, two objects are only compatible if they share the same explicit class name or inheritance chain. But JavaScript is famously dynamic. Developers often create objects on the fly that have the right properties but don't share a formal definition. A structural system, often called "duck typing," fits this perfectly. If an object has the same shape—the same properties and methods with the right types—TypeScript considers it compatible, regardless of what it's called. The `interface` keyword is the tool for defining these shapes. This was a pragmatic choice to embrace how JavaScript developers already worked, allowing them to add safety without forcing a rigid, class-based object-oriented model onto a language that thrives on flexibility.
Borrowing from the Classics
While TypeScript was built to serve JavaScript, its designers didn't ignore decades of language design that came before. With Anders Hejlsberg at the helm, it's no surprise that TypeScript borrowed some of the best ideas from C# and other statically-typed languages. Features like generics (using `
