你是否经常看到“你还没用过 TypeScript 吗？都 2020 年了！”之类的标语。 在文章中？ 明天我们将探讨 TypeScript 的异同。
本文适合从未接触过 TypeScript 的人，或者只看过文档但没有实际项目操作的人。 笔者希望这篇文章能给大家提供一个思路，以便以上两类读者能够做出选择。 如果你是 TypeScript 老手，这篇文章可能不适用于你，欢迎一起阅读和讨论。
哪个是 TypeScript？
TypeScript 是由 Google 开发的一种开源、跨平台编程语言。 它是 JavaScript 的超集，最终会被编译成 JavaScript 代码。
TypeScript 添加了可选的静态类型系统和许多尚未发布的 ECMAScript 新功能。
TypeScript 支持任何浏览器、任何环境、任何系统，并且是开源的。
首先列出相同点和不同点：
优势：
易于阅读
减少错误
活跃的社区
缺点：
学习费用
开发效率降低
一些第三方库的兼容性
需要编译
静态类型
我们都知道JavaScript是一种弱类型和动态类型的脚本语言。 作者在大学期间第一次接触JavaScript的时候就被震撼了，所以我很高兴！ 哪些变量可以是var，变量也可以是任意参数，函数的返回值类型？ 我不用再去关心那些乱七八糟的事情了，这才是语言该有的样子！
而且随着做的项目越来越多，这里需要添加类型判断，那里必须进行类型转换。 我渐渐发现这个问题并不像我看到的那么简单。 《幸福的同谋》：“静态打字”。
您是否经常需要编写这样的代码？
const data = typeof params === 'object'
? params.data
: JSON.parse(params).data;
if (typeof unix === 'string') {
unix = parseInt(unix);
}
想象一下：
你花了一个晚上研究出一个你认为完美的函数。
小明一号拿去调用之后，程序就崩溃了。
你查了一下原因：啊，参数类型传错了，赶紧补文档解释一下吧。
之后小明二号拿过来调用，程序就崩溃了。
你查了一下原因：啊，原来是参数的类型传错了，赶紧叫你使用的时候看一下文档。
小明三号拿过来调用之后，程序就崩溃了。
你检查了一下激励：啊，参数类型是对的，而参数对象上的值类型是错误的，你???@#&!!!...只能写一堆判断和转换，让自己了程序更加“健壮”。
里面的例子比较极端，我们也经常遇到，那么如果js是静态类型会是什么样子呢？
你花了一个晚上研究出一个你认为完美的函数。
之后，小明一号接过来，叫了出来。
小明一号发现参数类型传错了，就自己改了，我也不打扰你们了。 你连评论都懒得写，就高高兴兴地去上班了。
易于阅读和维护
类型系统实际上是一个非常实用的文档。 大多数功能可以通过查看类型定义来使用，但是在 vscode 上编译 TypeScript 时（其中使用 vscode 来表示所有代码编辑器），vscode 会根据你当前的上下文，列出你可以使用的所有类、变量、方法和关键字除此之外，TypeScript 的特性还完善了 vscode 的功能，包括代码补全、界面提示和点击跳转等。
如右图，我们通过index.d.ts文件可以清晰的了解到cors函数的参数类型：
代码提示：
那么如果我不使用 TypeScript 只使用 d.ts 不就好了吗？
其实也是可以的，只要你不费心，因为d.ts文件通常是在TypeScript上用tsc手动生成的。
减少错误
在前面的例子中，我们已经听说vscode等IDE也可以进行类型检测，可以直接提示很多类型的错误。 当多人开发和维护小型项目时，这一点尤其重要。 项目复杂，函数和变量复杂的时候，经常会出现一个人改动一点点，导致项目崩溃的情况。 这些情况在TypeScript面前都会大大减少。
但值得注意的是，使用 TypeScript 只能防止一些错误，并不能一劳永逸。 遵循严格的编码标准、配置eslint、代码审查、编译单元测试还是非常重要的！
活跃的社区
继 Angular 之后，React、Vue 相继开始支持 TypeScript。 尤其是在2019年，TypeScript经历了爆发式的下滑。 大多数第三方库开始为 TypeScript 提供类型定义文件。
学习费用
因为TypeScript是在JavaScript的基础上扩展的，所以真正的学习成本并不大，但它实际上是静态类型，需要了解套接字、泛型、类、枚举类型等新概念。 对于习惯了 JavaScript 语言的人来说很难习惯，这导致很多后端工程师在听到 TypeScript 时都会拒绝，尤其是在阅读了用 TypeScript 编译的项目之后。
但如果你想在现有项目中充分体验 TypeScript，你将面临极其昂贵的切换成本。
开发效率降低
虽然类型系统自带了自己的文档，但它可以节省大量编写注释的时间，而且作者亲身经历过，为所有值填写类型确实很痛苦。 当我参加朋友编的h264播放器时，我分分钟想自杀。
你以为你要写的内容：
你实际上必须写什么：
世界上最痛苦的事情莫过于此。 我5分钟就写了一个方法，文档花了1个小时才完成。
虽然TypeScript提供了Any类型，使用它也会失去TypeScript的优点，但建议不要使用它。
一些第三方库的兼容性
随着TypeScript越来越流行，很多依赖包都支持TypeScript，但仍然有一些不支持。 如果你的项目恰好依赖于它们并且你仍然想使用 TypeScript，那么你需要添加一个 d。 ts文件就可以用了，添加过程多麻烦啊，我只想说祝你好运。
需要编译
JavaScript 是标准，可以直接在浏览器中运行，这对于需要编译的 TypeScript 来说是一个很大的优势。
我们对 TypeScript 的使用
目前我们团队使用TypeScript编译的项目： 1. h264播放器 2. 错误日志背景
未来计划使用TypeScript编译的项目： 1. PC官网服务器搭建 2. 内部组件库
考虑到
在开始播放器项目之前，我们主要考虑以下几点：
尝试新技术。 组里的人对新技术非常热衷，希望通过一个项目来练习TypeScript。
玩家是一对多类型的项目。 使用该播放器的人众多且混杂，我们不能保证他们都能按照文档规范使用。 我们希望过滤掉一些低级问题反馈。
多人协作。 播放器工程庞大，音视频信息在各个函数中大多是通过引用类型传递和改变的。 对类型系统的需求很大。 大家可以在编译的时候防止类型错误，但是获取操作的参数类型比较方便。
代码规范化。 它是一个开源项目，因此代码越标准化越好。 TypeScript 很容易理解，并且有详细的文档。
新项目。 从头开始开发typescript静态页面，无需构建旧代码的成本。
项目地址：
PC官网服务器的建设主要基于以下考虑：
socket返回值是固定类型的。好像有一个socket文档，而且在之前的socket交互中，经常会出现PHP端需要进行类型转换，或者JS端需要进行类型转换的情况，也就是很麻烦。 TypeScript可以很好的解决这个问题。
持续维护。 pc官网的服务器部分是需要持续维护的代码。 使用TypeScript可以方便你的阅读以及后续的扩展和重构。
不同系统之间的类型获取。 开发人员不太可能知道每个系统的数据结构，读起来也是浪费时间。 TypeScript可以直接查询所需的数据结构，并在编译时提供代码提示。
很多人会问，JavaScript引入标准后，TypeScript会不会像CoffeeScript一样被逐渐抛弃，那我们还需要学习它吗？
笔者认为，这种情况很有可能发生，而我们无法确定这个等待期到底有多长。 即使稍后它会被 JavaScript 引入标准，您也可以享受我们之前提到的便利。 是不是很好吃？
推理
是否使用TypeScript，笔者认为在做出选择之前，需要仔细判断投入产出比，TypeScript带来的优势是否对当前项目有很大提升，是否值得花费大量时间来构建现有的项目，值得注意的是，无论TypeScript最终是否会应用到项目中typescript静态页面，你都要学会把握，不要跟着别人走。
最后，对于决策问题，笔者的建议是：如果你的项目是小项目、第三方库、或者其他需要持续维护的项目，就去TypeScript； 如果你的项目是一个事件，共享页面，等待一个较短的周期，但是对于不需要持续维护的项目，如果你想使用那个，我在这里想说，动态类型真的很酷。
以上仅代表个人观点，欢迎后台留言讨论~
