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 ，那想必是非常开心的。
可以使用：Google Closure编译器或其他第三方混淆工具
Google Closure编译器仍在使用，并且UglifyJS可以通过节点包管理器在本地运行：npm install -g uglify-js
私有字符串数据：
将字符串值设为私有是另一个问题，而混淆并不会带来太大好处。当然，通过将源打包成乱码，最小的混乱，可以通过 模糊* 性 获得轻便的安全性 。大多数情况下，查看源的是的用户，客户端上的字符串值是供他们使用的，因此通常不需要那种私有字符串值。
如果确实拥有一个不希望用户看到的价值，那么将有两个选择。首先，可以进行某种加密，该加密在页面加载时解密。那可能是最安全的选择之一，但也可能是很多不必要的工作。可能可以对一些字符串值进行base64编码，这会更容易，但是真正想要这些字符串值的人可以轻松地对其进行解码 。加密是真正阻止任何人访问的数据的唯一方法，大多数人发现加密比他们需要的安全性更高。
