【直播预览】eBPF在可观察领域是一个强大的工具还是一个无用的工具？
一个曾经只使用 JavaScript 的开发人员如何从反 TypeScript 变成 TypeScript 粉丝。
Chirag Swadia 自称是 Anti-TypeScript 的 JavaScript 开发人员。 谈及反对的原因，他仍然认为在函数/变量中添加类型来满足 TypeScript 编译器的要求是一种 Over-Engineering 设计。 因为这并没有提供任何有意义的便利，而且增加了开发效率——Chirag 表示，他一开始总会遇到一些难以理解的编译错误，这需要时间来处理。 他也感到沮丧并开始讨厌 TypeScript。
另一个原因是 Chirag 很难理解 TypeScript 中的子类化等中间概念。 他感觉自己身处Java世界，每一行代码都是强类型的，让人应接不暇。 当 Chirag 开始学习 TypeScript 时，他甚至担心下面的简单代码。
▲TypeScript 泛型示例
因此，虽然 Chirag 通过观看教程或阅读书籍来学习 TypeScript只学typescript是否可以，但由于上述原因，他从未参与过任何使用 TypeScript 编写的企业项目。
这一变化是在奇拉格就任新职位后发生的。 此时项目的技术栈是TypeScript，而他负责的应用程序都是用TypeScript编写的（只有遗留代码是JavaScript代码），所以他必须编写TypeScript代码。 正如 Chirag 所预料的那样，一开始这对他来说是一个巨大的挑战，他对 TypeScript 的仇恨与日俱增，但最终几个月后，他发现了 TypeScript 的好处以及其他人如何喜欢它。 对 TypeScript 而不是 JavaScript 的激励。
Chirag 还列出了他成为 TypeScript 粉丝的三个原因。
不可能的状态无法恢复并进行详细检测
Chirag 表示，这是他喜欢 TypeScript 的主要原因。 他引用了使用 TypeScript 来防止 React 应用程序中不可能状态的示例，这个反例描述了交通灯系统处理不可能状态的情况（请参阅此处）。
及早发现错误
Chirag表示，在使用JavaScript时，他遇到过很多在生产环境中发现Bug的情况，因为后端没有进行类型检测。 TypeScript 编译器可以在编译时避免和发现这些错误，从而节省开发和 QA 工作周期。
他认为使用 TypeScript 你可以保留最初定义的所有内容，如果你将一个变量声明为布尔值，那么它将始终是布尔值，而不是数字。 这增加了代码按照其最初预期形式运行的可能性。 简而言之，代码是可预测的。
丰富的IDE支持且易于构建
Chirag 表示，类型相关的信息可以让 IDE 更好地利用其优势，例如访问代码跳转和手动完成等功能，并且 IDE 会提供准确的建议。 另外只学typescript是否可以，您可以在键入代码时获得即时反馈，因为编辑器会在错误发生时对其进行标记，包括与类型相关的错误。 这些功能可帮助开发人员编写可维护的代码，并带来巨大的生产力提升。
至于构造，Chirag 举了一个例子，比如引入一个新的状态或者删除应用程序正在使用的不必要的状态。 如果此时忘记更新某些引用，TypeScript 编译器会发出警告。 他还表示，构建的应用程序将以预构建的形式运行，因此无需担心兼容性问题。
