ES5，ES（原名ES6）和TypeScript之间有什么不同？我们应该学习和使用哪一个？

首先，让我们为讨论这些建立一个基础。TypeScript是JavaScript的超集。ES是ES5的改进。知道关系可以让我们更容易学习他们。

我们想要理解他们之间的差异，首先我们就必须理解他们为什么存在。我们从ES5开始。

我们大多数人已经用了ES5好多年了。函数式编程在它这儿最棒，或者说最糟糕，这要取决于你如何看待它了。我个人喜爱用ES5编程。所有的现代浏览器都对它进行了支持。它极其灵活，但这也会产生很多能将应用推到坑里的因素。作用于、闭包、IIFE以及良好的防御式逻辑，这些对于确保我们的ES5代码不翻船都是必要的。尽管如此，其灵活性还是我们要依靠的一份力量。

这份图表展示了当前浏览器对于ES5的兼容程度。

也许ES5给我们带来的最大的问题就是在开发时定位问题的困难。ES5因其复杂性而缺少工具，充其量就是有工具能解析如何检查ES5的某些关键点。我们想要知道的是在另外一个文件中的对象包含了哪些属性,一个函数中的一个无效参数可能是什么,或者让我们知道在什么时候我们在一个不正常的作用域里面使用了一个变量。ES5让这些事情对于开发者和工具而言都困难了起来。

ES是从ES5的一个巨大飞跃。它给JavaScript增加了大量的功能特性。这些功能特性解决一些问题，这些问题曾使得ES5编程成为一项挑战。它们是可选的，因此我们可以在ES中继续有效的使用ES5(包括函数)。

这里所见是LukeHoban提供的ES的一些功能特性的参考。完整的列表可以在这份文档中查看。–arrows–classes-增强的对象文本–模板字符串–析构–default+rest+spread–let+const–迭代器+for..of–generators–unicode–模块–模块加载器–map+set+weakmap+weakset–代理–符号–内置插件式的可子类化–承诺–math+number+string+array+对象API–二进制和八进制文本–反射api–尾调用

这是对于ES5的一个巨大飞跃，而现代的浏览器都在争先实现所有的这些功能特性。这份图表展示了浏览器当前对于ES的兼容程度。

Node.js是针对V8引擎的现代版本而构建的。根据其文档来看，Node已经对ES的许多东西进行了实现。

Node4.x给自己打上了LTS标签，定位于长期支持的版本。LTS标签显示了他们的产品发布规律。所有偶数的主版本专注于稳定性和安全性。所有奇数的主版本(例如5.x)则归入短期支持(STS)的版本,专注于积极地拓展和更高频率的更新。简言之，我的建议是仍将node4用于生产环境的开发中，而将node5用于研究可能会在未来的LTS版本中存在的功能特性。你可以读一读这里的《node版本官方指南》。

回到ES,现在我们已经拥有了数量惊人的功能可以选择用来编写代码。

我们也许想要知道谁可能会对ES感兴趣，还有谁并不感兴趣。许多的ES5都深谙这门语言的利弊。在JavaScript领域混迹了十多年以后，我们可能会感觉ES5用起来非常舒适。如果没有明白其中的价值，一旦我们已经掌握了一门语言，要找个理由跳转到一个新的版本就可能有点困难了。我们会得到什么？我们要解决什么问题呢?这就是我们自然而然会生出的想法。一旦我们认定迁移到ES有利可图,那么就会做出迁移的决定。

也有许多ES5开发者都等不及要使用ES了。关键是很多曾今使用ES5的人已经在用到ES了，而更多的人则仍然在决定中踯躅不前。

现如今JavaScript开发者有许许多多，而且还有更多人在进入这个领域。我认为现在正考虑学习JavaScript以及那些仍在在学习的人的数量，将会比目前正在使用它的人要少。JavaScript正处在发展之中，而并不是每个人都会有一个成熟的ES5开发背景。许多人都来自于Java和C#已经其它流行的语言和框架。这些的许多都已经拥有了ES最近引入的功能特性，并且用了都好几年了。这使得ES对于他们而言比起ES5来说更容易过渡。而现在也是个好时候，因为许多现代浏览器以及Node都在支持着ES。

因而我们有许多人，都拥有着不同的背景，却都会走上ES(或者更高版本)的迁移之路。

我们如何才可以在还不支持ES的浏览器中运行ES?我们可以使用像Babel这样的工具，用ES编写代码，然后将代码转换成ES5。Babel使得编写ES变得简单(未来的ES以及更高版本也不在话下)，然后仍将代码向下编译成老版本的JavaScript。相当的酷!

TypeScript适合用在哪里呢?甚至于我们是否应该去使用它呢?

首先，我觉得这个名字就有点让人望而却步。TypeScript中的Type这个词表明我们会拥有类型。这些类型是可选的，因此我们并不是非得用上它们不可。不相信我?当你尝试将ES5代码复制到TypeScriptplayground中去的时候。看看，天啦!不需要任何类型!所以我们是不是可以选择性的它Type?Script或者[Type]Script呢?开个玩笑，类型知识TypeScript一块而已。也许更好的名称就是简单的ES+。

让我们回头来回顾一下之前我曾提过的问题，许多开发者在编写JavaScript的时候都会遇到:在开发时识别错误的困难。

如果在编写它们的时候就我们可以识别出作用域问题会如何呢?如果可以在我们的工具中通过红色的下划线识别不匹配的参数会如何呢?如果编辑器和IDE可以告知我们在不正当的使用了别人或者我们自己的代码的时候会告诉我们，会如何呢？这些都是我们通常要依赖工具的地方。

无论我们使用的是Atom,VSCode,VisualStudio,WebStorm,还是SublimeText，我们所要享受的都是其多得有点过剩的固有功能或者可供我们选择的工具扩展，是它们在帮助我们较快的写出更好的代码。这些工具应该（而且能够）对尽早识别出问题起到有所帮助。

当我们编写代码时候，如果能马上找到一个问题的话，就会更加有意思，于是我们就可以就地解决它…或者在早上5点钟被叫醒，因为恰好在那时候触发了我们隐藏的bug而导致业务中断，生产环境爆出问题？5点那个时候我宁愿跟我的家人待在一起??

今天的这些工具在试图帮助我们识别问题，而它们的工作确实令人钦佩。不过如果我们可以给它们更多一点点的帮助会如何呢?如果我们赋予它们跟今天其它像C#和Java这样的语言相同的类型的帮助会如何呢?那这些工具就确实能尽早而且频繁的帮助我们识别出问题来。

这就是TypeScript的用武之地。

TypeScript的价值并不在于编写更少的代码，其价值在于编写更加安全的代码。从长远看来，它能帮助我们利用其工具识别问题并自动填充参数、属性、函数以及更多东西（通常被成为自动补全和智能感知），从而更有效率的编写出代码。

你可以在其playground中体验TypeScript。

我开玩笑说TypeScript应该被叫做ES+,而当我们更近一点观察它的时候，还确实是这样的。

那么TypeScript在ES之外还提供了什么呢?我将专注于三个我所认为增加了最大价值的方面:

类型

接口

未来的ES+特性(比如注解/装饰器以及异步/等待)

TypeScript就是ES机上像这样的一些特性。

类型和接口对于提供那些需要在我们敲写代码的时候就能识别出问题的功能有帮助。有了这些功能特性，编辑器就不需要去猜测我们是否在正常地使用一个函数。错误信息对于工具而言足够明确，足以让它们向我们亮起红灯，那样我们就可以立即对问题进行修复。在某些情况下，这些工具也能在推荐和重构上帮助到我们！

TypeScript有望成为前瞻性的思维。它有助于我们提前商榷未来ECMAScript中出现的功能特性。例如像装饰器(在Angular中有被用到)以及异步/等待(一种可以让C#中的异步编程更加轻松的流行技术)这样的技术。装饰器现在在TypeScript中已经可以使用了，而据《TypeScript路线图》异步/等待很快就会在.0版本中推出。

在TypeScript网站的头版页面顶部，我们找到了这样一条声明:

TypeScript是JavaScript类型化子集，它会被编译成原生的JavaScript。

这是非常重要的。TypeScript并不是一种捷径语言。它不会偏离JavaScript，不会将我们带去另外一个方向。它的目的是让我们可以在今天就能使用到将会在未来的JavaScript版本中出现的功能特性,并提供一个更好且更加安全的体验。

这是一个很棒的选择!学习ES是从ES5的一个很大的进步。一旦你掌握了ES,我敢说从此TypeScript就是只是非常小的一步。因此回头我会建议，一旦你学习了ES,要尝试一下TypeScript并利用好它的工具。

学些ES或者TypeScript会对我的就业产生不良影响吗?当然不会。不过这也并不意味着你不去理解ES5。今天ES5无所不在。不过它终有没落的一天，但还有那么多ES5在那儿，而理解这门语言对于理解ES和TypeScript帮助我们解决了什么毕竟是有好处的。另外我们也能够利用ES5的知识来使用浏览器中的源码映射对问题进行调试。

很长一段时间里我们都不需要什么转译器（transpiler）。Web使用的是JavaScript，而大多数编写ES和ES5的家伙都在用jQuery来处理跨浏览器问题。当ES5到来时，并没有发生太多的变化。多年来从事着Web开发，我们已经拥有了一套稳定的大多数浏览器都能理解的JavaScript功能特性。如果哪里出了问题，我们会使用想es5-shim.js甚至jQuery来处理它们。但时代在变。

Web的步伐现在很快。新的标准不断涌向。像Angular,Rx.js,React,以及Aurelia这样的库在推动这Web向前发展。更多的开发者正在通过web和Node.js进入JavaScript这个领域。

ECMAScript团队现在采纳了一种新的命名方式，以年份作为标识，区分语言的版本。不会有ES6了，现在我们叫它ES。而下一个版本则被指向ES。其意图就是让新的功能特性更加频繁地加入到JavaScript中去。对于所有的浏览器而言，从桌面到移动端都采纳这一套标准，是需要花点时间的。

整个这些意味着什么呢?正当我们拥有了支持ES的浏览器的时候，ES可能就出来了。如果没有其它帮助，而我们又想要在所有的浏览器上都用上新的功能特性，就可能会有点可怕了!除非我们有办法可以利用今天的新的功能特性，并支持我们需要支持的浏览器。

这就是为甚转译器的出现在今天的Web领域如此重要的原因。TypeScript和Babel(转译领域的主要玩家)都在其出现在浏览器之前就已经支持ES了。它们都计划要支持(并且已经在某些情况下这样做了)ES的功能特性。这些工具就是我们如何一边继续向前推进，又不会把我们的客户落下，这个问题的答案。

我们可以使用类似Gulp，Grunt，WebPack，SystemJS和JSPM这些工具反编译成Babel或者TypeScript。很多编辑器直接连接到这些任务为我们的代码进行反编译。现在，很多IDE都支持通过点击一个按钮自动化反编译。我们甚至可以在命令行中使用TypeScript，并可以查看我们的文件并进行反编译。

总之，我们的代码都有很多种方式可以进行反编译。

实际上，在技术上的改变会改变我们在职业上的选择。有时候，技术上发生的改变远远快于我们的吸收速度。这就是为什么工具是重要的，因为它可以帮助我们吸收，就像TypeScript和Babel之于ES（更高版本）。在这个例子中，我们使用技术来跟上技术。这看起来像是一个悖论，但是它的核心就是要我们有效使用时间。