ES5, ES2015 (以前叫做 ES6)和 TypeScript 之间的区别是什么？我们应该学习和使用哪一个？

首先，让我们为讨论这些语言建立一个基础。TypeScript 是 JavaScript 的超集。 ES2015 是 ES5 的演进。这种关系让逐步学习它们变得容易些。

我们想理解它们之间的区别，但首先我们得知道它们是什么以及为什么存在。我们从 ES5 开始。

ES5

ES5 是我们大部分人用了很多年的语言。它的函数式编程特性非常好，或者说非常糟糕，取决于你怎么看它。 我个人喜欢用 ES5 编程。所有现代浏览器都支持它。它极度灵活，却也有着许多会导致应用程序崩溃的因素。为了保证我们的程序在IE5下不偏离正轨，我们需要作用域、闭包、立即执行的函数以及良好的逻辑。 尽管如此，它的灵活性也是我们大多数人依赖的一个优势。

这个 图显示了当前浏览器对 ES5 的兼容性。.

或许 ES5 带给我们的最困难的问题是如何在开发阶段发现问题。ES5 工具很缺乏，因为对工具来说检查 ES5 太复杂了。我们想知道另一个文件里的对象包含哪些属性，函数的无效参数可能是什么，或者让我们知道是否在错误的作用域里使用了变量。ES5 让开发人员和工具做这些事变得困难。

ES6/ES2015 的飞跃

ES2015 是 ES5 的巨大飞跃。它给 JavaScript 增加了非常多的特性。这些特性解决了 ES5 编程的一些挑战性问题。它们是可选的，因为我们依然可以在 ES2015 里使用 ES5 （包括函数）。

这里是 ES2015 的一些特性，见诸 Luke Hoban 的参考文档。完整的列表可以在spec 里找到。 - 箭头函数 - 类型 - 增强的对象字面量 - 模板字符串 - 解构 - 默认参数 + 剩余参数 + 展开 - let + const - iterators + for..of - generators - unicode - modules - module loaders - map + set + weakmap + weakset - proxies - symbols - subclassable built-ins - promises - math + number + string + array + object APIs - binary and octal literals - reflect api - tail calls

这是 ES5 戏剧性的飞跃，现代浏览器也竞相实现所有的特性。这张 图展示了当前浏览器对 ES2015 的兼容性。

Node.js 是基于现代版本的 V8 引擎构建的。Node 已经实现了 ES2015 的很多特性，根据它的文档。

Node 4.x 给自己打上了长期支持 (LTS) 的标签。LTS 标签表明了他们的发布线路。所有的偶数主版本号集中于稳定性和安全性。所有的奇数主版本号（例如 5.x）是短期支持（STS）， 主要集中于活跃的开发和更频繁的更新。简言之， 我建议你产品开发用 node 4， 而未来的特性研究使用 node 5。你可以查看官方的 node 版本指南.

回到 ES2015， 我们现在拥有了难以置信的大量的特性可以在代码里使用。

开发者怎么看 ES2015？

我们可能想知道谁对 ES2015 感兴趣，谁不感兴趣。有很多 ES5 开发者已经很清楚这门语言的利弊了。使用 JavaScript 超过十年了， 我们可能对 ES5 感觉良好了。 一旦我们掌握了一门语言，就很难接受跳跃到新的版本，如果我们看不到价值所在的话。我们获得了什么？我们解决了什么问题？这是很自然的思路。一旦我们确定转向 ES2015 是有价值的，那我们就会决定走这一步。

也有很多 ES5 开发者迫不及待地想用 ES2015 了。关键在于很多用过 ES5 的人已经在用 ES2015 了，而更多的人仍然在考虑是否迁移。

现在已经有很多 JavaScript 开发者了，但将来会更多。我相信现在正考虑学习 JavaScript 的人比正在使用 JavaScript 的人更多。JavaScript 在成长，并不是每个人都有坚实的的 ES5 背景。有些人是从 Java 和 C# 以及其他流行的语言和框架转过来的。他们当中的很多人已经接触过 ES2015 最近引入的特性了，而且接触了好几年了。这让他们转换到 ES2015 比 ES 更容易。并且这个时间点也很好，因为很多现代浏览器和 Node 都支持 ES2015.

所以我们当中的很多人，看法各异，但都在向 ES2015（或更高）迁移。

支持 ES5 浏览器

我们怎样在还不支持 ES2015 的浏览器上运行 ES2015？ 我们可以使用 ES2015， 然后用Babel 之类的工具转换成 ES5。Babel 让书写 ES2015（还有未来的 ES2016 或更高）变得容易，仍然会编译成更旧版本的 JavaScript。非常酷！

TypeScript

什么地方该用 TypeScript ？ 我们到底需不需要它？

首先，我认为它的名字就把人们吓跑了。TypeScript 中的 Type 一词表明我们现在有类型了。这些类型是可选的，因此我们不是必须用它们。不相信？试着粘贴你的 ES5 代码到 TypeScript playground。妈咪快看！不需要类型耶！那么我们是不是可以叫它 Type?Script_ 或者 [Type]Script ？ 玩笑归玩笑，类型只是 TypeScript 的一小部分。或许更好的名字是 ES+。

让我们回头看看我之前提到的很多开发者在写 JavaScript 代码碰到的问题：难以在开发阶段发现错误。

如果我们可以在输入的时候发现作用域问题会怎样？如果我们可以在工具里用红色下划线标出不匹配的参数会怎样？ 如果我们的编辑器和 IDE 可以在我们不正确地使用别人或自己的代码时告诉我们，又会怎样？这就是我们通常依赖工具的地方。

尽早发现问题

不管我们在用 Atom, VS Code, Visual Studio, Web Storm, 或者 Sublime Text，我们享受着工具的自带功能或扩展程序，帮助我们更快地写出更好的代码。这写工具应该（也能够）帮助我们尽早地发现问题。

在写代码的时候立即发现问题，我们就可当即解决它，这样不是更好玩吗？或者因为我们的 app 流量增加触发了隐藏的bug导致产品崩溃，早上5点被打电话通知？我更喜欢在5点的时候在家陪家人 :)

今天这些工具在尽全力帮助我们发现问题，并且它们在这方面做得非常不错。但是如果我们给它们更多点的帮助会怎样？如果我们给它们提供像其他语言比如 C# 和 Java 同样类型的帮助会怎样？那么这些工具确实可以更早、更多地帮助我们发现问题。

这就是 TypeScript 闪光的地方。

TypeScript 的价值不在于写更少的代码。TypeScript 的价值在于写更安全的代码。长远地看，它帮助我们更高效地编码，因为我们利用了工具来发现问题，以及自动填充参数、属性、函数和更多（通常被称为自动完成和智能感知）。

你可以 在这尝试 TypeScript.

ES+

我开玩笑说 TypeScript 应该被叫做 ES+，但当我们更进一步探究它时，还真是这么回事。

那么 TypeScript 比 ES2015 更好的地方在哪？我会集中在我觉得增加了最多价值的三个主要方面：

1. 类型
2. 接口
3. 未来的 ES2016+ 特性 (比如 Annotations/Decorators and async/await)

_TypeScript 是 ES 加上如下的特性：

类型和接口帮助提供它需要的工具，以便在我们输入的时候发现问题。有了这些特性，我们的编辑器就不必要猜测我们是否正确地使用了某个函数。工具有了这个信息，就很容易显示一个红旗，我们就可以马上解决问题。在有些情况下，这些工具也可以给我们推荐，帮我们重构！

TypeScript 承诺了前瞻思维。它把未来 ECMAScript 规范商定的特性在今天带给我们。例如 decorators ( Angular 2 中用到了) 和 async/await (C# 中让异步编程变得更容易的一项流行技术)这样的特性。Decorators 在 TypeScript 中已经有了，而 async/await 很快会出现在 2.0 版本里，据 TypeScript 路线图。

TypeScript 偏离了 JavaScript 了吗？

在 TypeScript 网站的首页的顶部，我们发现了这样的声明：

TypeScript 是类型化的 JavaScript 超集，可以编译成普通的 JavaScript。

这个非常重要。TypeScript 不是快捷方式语言。它并没有偏离 JavaScript。它没有把我们带到另外的方向去。它的目的是允许我们现在使用将来版本的 JavaScript 特性，并提供更好、更安全的体验。

为什么不直接用 ES2015 呢？

那是个不错的选择！学习 ES2015 是 ES5 的巨大飞跃。一旦你掌握了 ES2015，我保证再学 TypeScript就是小菜一碟。所以我再次建议，一旦你学了 ES2015，尝试下 TypeScript 并利用好它的工具。

就业力怎么样？

学习 ES2015 或者 TypeScript 会损害我的就业力吗？ 绝对不会。但这并不意味着你不该理解 ES5。如今 ES5 无处不在。这种情况最终会减缓，但已经存在很多 ES5 代码，而且理解这门语言也有利于做技术支持和理解 ES2015 和 TypeScript 解决了什么问题。另外我们可以利用 ES5 知识帮助我们在浏览器里借助 sourcemap 调试问题。

跟上新兴技术的脚步

很长一段时间我们不需要转换器。Web 使用 JavaScript，很多写 ES3 和 ES5 的人使用 jQuery 处理跨浏览器问题。ES5 出现的时候，并没有多大改观。很多年来，在 Web 开发领域我们有大部分浏览器都理解的一套稳定的 JavaScript 特性。在有问题的地方，我们利用 es5-shim.js 之类的东西和 jQuery 做变通处理。一切都变了。

Web 在快速发展。新的 Web 标准在浮现。Angular 2, Rx.js, React 和 Aurelia 之类的库在推进 Web。更多的开发者通过 web 和 Node.js 转向 JavaScript。

ECMAScript 团队现在采用年份作为标识来命名语言版本。不再叫 ES6，现在我们叫它 ES2015。下个版本会定为 ES2016。这么做的目的是为了更频繁地增加 JavaScript 新特性。桌面和移动设备的所有浏览器采纳标准尚需时日。

这一切意味着什么？ 就是当我们的浏览器支持 ES2015 的时候，ES2016 又出来了。没有帮助的话，如果我们要支持无所不在的浏览器使用新特性，将会变得很糟糕。除非我们有一种方式去使用新特性并支持我们需要的浏览器。

这就是为什么在当今的 Web 转换器的出现变得如此重要的原因。TypeScript 和 Babel (主要的转换器) 都在浏览器之前支持 ES2015。它们都计划支持（在一些案例下已经实现）ES2016 特性。这些工具回答了我们如何在前进的同时不丢下客户的问题。

我们如何转换？

我们可以利用 Gulp、Grunt、WebPack 和带 JSPM 的 SystemJS 使用 Babel 或 TypeScript 来转换。很多编辑器可以直接连接到这些任务，在我们编码的时候转换。现在很多 IDE 支持一键自动转换。我们甚至可以通过命令行使用 TypeScript 监听文件变化，实时转换。

无论我们如何写代码、在哪写代码，都有很多方式转换。

这一切的意义是什么

我们选择的职业的一个事实是：技术在变化。技术在发展。有时候技术的发展速度超过了我们吸收的速度。这就是为什么要利用 TypeScript 和 ES2015（以及更高） 版 Babel之类的工具帮助我们吸收和适应这些变化的原因。这里我们是利用技术赶上技术。看上去像悖论，但本质上只是更有效地利用时间赶上技术的脚步。

本文转载自：众成翻译
译者：kayson
链接：http://www.zcfy.cc/article/1332
原文：https://johnpapa.net/es5-es2015-typescript/