打字。不管你喜欢它还是讨厌它，它都有很多优点：更好的 DX（通过智能感知自动完成）、更好的代码文档、更少的耗时错误。它的好处大大超过了它的成本，那么为什么有些人仍然避免使用它呢？一个词：打字稿。您必须对其进行设置并确保您的工具正常工作，这会给任何项目增加一层挫败感。
那么，如果我告诉你原生类型可能会出现在 Javascript 中呢？圣诞节快到了，男孩，我有礼物给你🎅
TC39 是负责 Javascript 规范的委员会——他们帮助维护和发展 JS 的定义。
他们最近将类型注释提案移到了第 1 阶段（共 4 个阶段），这意味着是时候广泛推测此功能的影响和含义了！
尽管我喜欢戏剧化，但这不会以任何方式标志着 TS 的消亡，它只会为不打算使用 TS 或希望同时使用两者的项目提供更清晰、更可靠的 JS 代码。
这将非常接近我们目前使用 Typescript 和 Flow 的方式，即：
// both parameters are numbers, and this method returns a number- function add(a: number, b: number): number {
- return a + b;
- }
这些注释不会阻止您将字符串或任何其他变量类型作为参数传递。它们将在运行时被忽略，只是作为指南供第三方类型检查器（例如您的 IDE）使用。
在我看来，严格类型化的争论在这次讨论中占有一席之地。在目前的提议中，这些类型只是类型注释，这要归功于 JSDoc 我们已经有了。所以问题仍然存在：为什么？
我们的处境很奇怪：Javascript 是仅有的几种让我们用一种语言 (Typescript) 编写然后将其转换为另一种语言 (Javascript) 的语言之一。这些层增加了任何项目的复杂性，因此我们添加到默认工具带的工具越多越好。
对 Typescript 的需求创造了一种对当前可用工具的垄断形式，其中每个工具都需要与 TS 一起发展，以免落伍。Octoverse 2022的状态显示了 Typescript 在 2022 年令人印象深刻的流行，这意味着这种发展需求对于您的 linters、bundlers 等几乎是强制性的。
将此功能与我们亲爱的 Javascript 捆绑在一起只会使它成为一个更完整的包，并帮助我们减缓我们目前面临的明显的工具膨胀。
你怎么看？如果它发布，你会看到自己使用这个功能吗？想到什么风险，特别是如果您是 Typescript 的狂热用户？