Why Typescript Is Not Answer

TypeScript, a superset of JavaScript is an Open Source project from Microsoft and the language “is a typed superset of JavaScript that compiles to plain JavaScript”. It frames on JavaScript by adding classes, interfaces, modules and optional type declarations and on compiling, these type declarations are erased, and ECMAScript 3 compatible code is generated.

Fixes the Wrong Problem
TypeScript upgrade JavaScript with types, classes and interfaces. The complication with JavaScript is not that it is a dynamically typed prototype based object-oriented language without classes. It is actually JavaScript’s strength. The problem is that it is a disorganized language, filled with many hidden land mines awaiting the inexperienced developer.

Who Control Type Definitions?
TypeScript adds elective type declarations, but when collaborate with existing JavaScript libraries there are no type declarations and a lot of TypeScript’s benefits evanish. To compromise with that, TypeScript supports type definition files. These are hand recorded files that equip the missing type declarations for an existing JavaScript library. Having good type definition files for the JavaScript libraries you want to use is an extensive part of having a good TypeScript involvement. Microsoft points to the Definitely Typed project as the source of type definitions for attractive JavaScript libraries. However, what happens when the library you want to use is not popular enough or is too new? what if there are type definitions, but not for the correct version of the library you need to use? How can you be sure the definitions are correct? They are just one more source of possible development issues. Any such library add-ons are restrained to be an additional source of headaches if they are not maintained by the library author.

Still JavaScript
The real complication with TypeScript is accommodate in the statement that it is a “superset of JavaScript.” Which means that all legal JavaScript programs are also legal typescript programs. TypeScript doesn’t fix anything in JavaScript apart from some things that were fixed in ECMA Script 5. So, for example, the non-strict equality operator == is still there and has the more logical syntax than the strict equality operator ===. There is still the unfamiliarity of semicolon insertion. In some cases, the supplementary features actually make it more likely a developer will endorse the wrong psychological model of the language semantics and walk right into a mine. Classes makes more complicated behaviour of "this" keyword. For example,

class Greeter {
	greeting: string;
	constructor(message: string) {
		this.greeting = message;
	}
	greet() {
		return "Hello, " + this.greeting;
	}
}
        

The "this" keyword in the methods of "Greeter" should always mention a Greeter instance. However, the definition of this are unchanged from JavaScript:

var greeter = new Greeter("world");
var unbound = greeter.greet;
alert(unbound());
        

The above code displays “Hello, undefined” instead of expected “Hello, world”.

Update
TypeScript somewhat addresses concern with == as it will produce type errors for comparisons with == when it has type info.

var a = "ssdf";
var b = 5;
alert(a==b); // "Operator '==' cannot be applied to types 'string' and 'number'."

However, if either variable has type Object or any it will not show an error and go on to evaluate loose coordination.

Not the Answer
I conclude that TypeScript is not the answer or may be it is more accurate to say it is the answer to a different issue. My prediction is that after some time people will come to know TypeScript does not ignore the JS minefield and only makes it more confusing by providing the illusion of security. I suppose TypeScript will turn into a tool along with web development roadside used by a corner of developers.