前言
TypeScript 是目前前端圈内的明星级"语言"，然而最近一段时间也是争议不断，首先是一些知名库，比如Svelte、Drizzle 和 Turbo都相继放弃了TypeScript，他们认为 TypeScript 在开发库时带来了不必要的复杂性，使得代码变得难以理解和维护；甚至最近关于 jsDoc 是否能替代 TypeScript 这一话题一度冲上热榜，这不禁让人困惑 TypeScript 的未来到底在哪儿？
然而话虽如此，无论你喜欢还是不喜欢，都需要承认TypeScript带来的好处：
静态类型检查：TypeScript允许开发者定义变量、函数参数和返回值的类型，从而在编译时捕获潜在的类型错误。这可以帮助减少在运行时出现的错误，提高代码的可靠性。 更好的代码可维护性：类型信息可以使代码更加自文档化，提供了更清晰的代码结构和更容易理解的代码。这有助于团队协作和维护代码库。 IDE支持：主流的集成开发环境（IDE），如Visual Studio Code，提供了强大的TypeScript支持，包括自动完成、重构、调试等功能，以提高开发效率。 强大的面向对象编程支持：TypeScript提供了类、接口、模块等面向对象编程的特性，使其更适合构建大型应用程序。但如果某一天有人告诉你原生Typing可能会出现在JavaScript中，你会怎么想？
提案
TC39 是负责Javascript规范的组织，他们帮助维护和发展JS的定义。最近他们将类型注释提案推进到了第 1 阶段；
Stage 0 - Strawman (草案阶段) : 这是提案的初始阶段，通常是一些初步的想法或建议。这些提案还没有得到正式的讨论和接受。 Stage 1 - Proposal (提案阶段) : 在这个阶段，提案已经经过了初步的讨论，并且有了详细的说明。它们通常由一个或多个TC39委员会成员提交，并等待进一步的审查和反馈。 Stage 2 - Draft (草案阶段) : 在这个阶段，提案已经经过了初步的审查，包括语法和语义方面的考虑。提案可能会在这个阶段进行一些修改和改进。 Stage 3 - Candidate (候选阶段) : 当提案达到这个阶段时，它们被认为是成熟的，可以被实施到JavaScript引擎中。这通常包括详细的规范文档和实际的参考实现。 Stage 4 - Finished (完成阶段) : 这是提案的最终阶段，表示它们已经被正式接受为ECMAScript标准的一部分，可以在各种JavaScript环境中广泛使用。这就意味着针对这个提案，是时候认真思考其对未来真正的影响和意义了！
如果提案获得通过，原生类型会是什么样子？
它将非常接近我们目前使用的 Typescript，即：
// 方法的两个参数都是数字，并且返回一个数字 function add(a: number, b: number): number { return a + b; }
这些注解不会禁止我们传递字符串或任何其他变量类型作为方法入参，因为它们会在运行时被忽略，功能上只是作为第三方类型检查程序（如集成开发环境）的指南。在我看来，严格类型 在JavaScript话题中仍占有一席之地。在目前的提议中，这些类型只是类型注解，而 JSDoc 已经为我们提供了这种注解。所以问题仍然是：为什么还需要原生Typing？
意义在哪儿
说着也奇怪，Javascript 是唯一一种需要我们用一种语言（如Typescript）编写，然后再转译为另一种语言（Javascript）的语言。这些层级增加了任何项目的复杂性，因此我们在默认工具带上添加的工具越多越好。
对 Typescript 需求的旺盛造成了对当前可用工具的垄断，其中的每一种工具都需要与 TS 共同发展，毕竟落后就要挨揍。2022年Octoverse状态 显示：Typescript 在 2022 年的受欢迎程度令人咋舌，这意味着对于内联程序、捆绑程序等来说，这种进化需求几乎是强制性的。
所以将原生Typing与Javascript捆绑在一起只会使其成为一个更完整的软件包，并帮助我们减缓目前面临的明显的工具臃肿问题。
所以你怎么看待原生Typing这一特性？如果这项功能发布，你会使用它吗？特别是如果你是 Typescript的忠实用户。
