1. Потому что одной из целей при создании TypeScript была именно читабельность выходного JS-кода. Цитата из
TypeScript Design Goals:
Goals
...
4. Emit clean, idiomatic, recognizable JavaScript code.
...
Non-goals
2. Aggressively optimize the runtime performance of programs. Instead, emit idiomatic JavaScript code that plays well with the performance characteristics of runtime platforms.
2. Потому что TypeScript прежде всего - это строгая типизация (а также сокрытие и прочие связанные вещи). Поэтому бОльшая часть рантайм-проверок не нужна в коде, генерируемом TS - компилятор всё проверяет при сборке. Сравним результаты компиляции следующих фрагментов кода Бабелем и tsc:
фрагмент на ES6:
class Foo {
constructor(a, b) {
this.a = a;
this.b = b;
}
bar() {
return this.a + this.b;
}
}
фрагмент на TS:
class Foo {
private a: number;
private b: number;
constructor(a, b) {
this.a = a;
this.b = b;
}
bar() {
return this.a + this.b;
}
}
Как вы можете заметить, TS генерирует только самое необходимое, в то время как Бабель в дефолтных настройках генерирует хелперы вроде
_createClass
и
_classCallCheck
, которые определены достаточно нетривиально. Зачем он это делает? Затем, что Бабель генерирует код, "безопасный" в райнтайме. Он не рассчитывает на то, что какие-либо проверки будут выполняться при компиляции. Например, в хелпере _classCallCheck проверяется, что конструктор не был вызван, как обычная функция.
TS считает такие проверки избыточными - его разработчики считают, что все они должны происходить именно при компиляции. Дополнительных проверок для вызывающего кода не производится.