Why TypeScript Isn't the Answer
Fixes the Wrong Problem
Who Maintains Type Definitions?
== is still there and still has the shorter more natural syntax than the strict equality operator
===. There is still the strangeness of semicolon insertion. In some cases, the additional features actually make it more likely a developer will adopt the wrong mental model of the language semantics and walk right into a mine. Classes make the unchanged behaviour of the
this keyword more confusing. For example, in a class like
Greeter from the TypeScript playground, the use of
this is confusing:
One can’t help but feel the
this keyword in the methods of
Greeter should always reference a
Greeter instance. However, the semantics of
The above code displays “Hello, undefined” instead of the naively expected “Hello, world”.
A commenter (alleycat5 on Reddit) pointed out that TypeScript partially addresses issues with
== because it will produce type errors for comparisons with
== when it has type information.
However, if either variable has type
any it will not produce an error and continues to evaluate loose equality. For those not familiar with TypeScript,
any is a special type that can be either an object or a primitive like a number etc.
Not the Answer
This article is Part 2 in a 6-Part Series.
- Part 2 - This Article
- Part 3 - Why Dart Isn't the Answer
- Part 4 - Why CoffeeScript Isn't the Answer
- Part 6 - What I Think CoffeeScript Should Have Been