Question

如何评价TypeScript接口的扩展，自动混合的特性

Answer 1

　　从 Coffee 的使用之广泛来看，TypeScript 必然也是一个很有意义的项目。
　　与 CoffeeScript 相比，它们在「解决 JavaScript 糟粕」、「提高可读性」等目标上相似，并且都是以预编译的方式工作。不过，TypeScript 有一些先天的优势：
　　高度兼容原生脚本语法（甚至可以混着写）
　　对语法的破坏性较少，即使没接触过的人，也能很快上手，初次阅读也没有什么障碍
　　如名字所述，它讲究基于接口的强类型，因此非常适合原本的服务器开发者使用
　　提供了大量编辑器的集成，有现有大量库的 .ts 元文件可用
　　这是一个好玩而有用的工具，由于它是对脚本的预创建过程，并不给项目造成什么大的改动（除了一些新增的 .ts 文件）。
　　不过，要在项目中大量推广，还需要有项目成员的配合使用（在脚本文件的相互引用时，最好至少有 .ts 元文件），这可能存在一定的阻力。
　　在不少开源项目中，已经见到很多人在应用 TypeScript 了。

Answer 2

用了几个月的 TS 写前端。
TS 在 1.4 前是残废。1.4 引入的 union types 和 type alias 算是非常重要的。没有这两个特性，TypeScript 能提供的编译期类型检查甚至还不如 JSDoc 的 type annotation 来得好用。尤其是没有 type alias ，定义一个 callback 都要用 interface，实在蛋疼。
后来用 TS 写一个新的项目，把写的 TS 编译成 JS 放到线上后，其他人纷纷表示不会 TS，修 bug 和加特性时直接在编译出的 JS 的基础上改了。后来把变更一点点加回 TS 源文件的时候，不得不 diff 一下 JS 文件的变化，一行一行地在 TS 里对应着改，实在令人唏嘘。
其实对来说 TypeScript 令人不悦的一点是，官方明确指出，TS 不会提供任何 run-time type information 有关的特性。然而 TS 的工作场合就常常涉及把服务器返回的 JSON 转成 JS objects、把 cookie 转成 JS objects 之类的事情，没有 run-time type information 的支持，实在是最大最大的硬伤。运行时无类型信息这一点更是使得很多东西不得不在 run-time 手动去 cast，这使得编译期带来的类型安全保障荡然无存。这几点可参见评论里补充的例子。
如果有 TypeScript 的超集或是扩展能够提供 run-time type information ，那想必是非常开心的。