最近，微软宣布了一项举世瞩目的提案，表示他们将支持 JavaScript 和 TypeScript 的进一步开发，该提案几乎在一夜之间动摇了编程语言的基础。
截止到目前为止，该提案还只是一个处于 Stage 0 阶段的建议，但微软宣布他们会按时将该提案提交给 TC39 委员会。如果这个提案被采纳并付诸实施，那么必将在 JavaScript 和 TypeScript 界引发前所未有的动荡。
JavaScript 的历史回顾
回溯 20 年前，与现在的 Web 开发做比较，你就会发现，虽然 JavaScript 作为一种编程语言已经有了很大的发展，但围绕 JavaScript 的生态系统则取得了更大的进步。
语言本身与生态系统的发展是相辅相成的，一方面在过去的二十年里 JavaScript 社区变得越来越专业，而另一方面互联网本身在现实生活中的重要性也变得越来越突出。作为开发人员，我们无法控制用户使用哪些浏览器。
这意味着用户只有定期更新浏览器才能使用 JavaScript 的现代功能。虽然对于个人用户来说，定期更新并不是难事，因为如今许多浏览器会自动更新而无需用户的指示，但对于企业却并非如此。
各个公司对于软件和软件更新有着严格的规定。许多公司都会使用过时的软件或浏览器上网。这是一个基本问题，甚至会影响到 HTML 和 CSS，此外，由于编程语言必须由各个浏览器解释，因此也会对浏览器产生严重的依赖。
转译与捆绑
作为一名 Web 开发人员，你必须在两种思路之间做出选择：第一，依赖现代 JavaScript、CSS 或 HTML，这种方式不仅可以简化编程，而且也可以提高易用性；第二，不使用这些现代功能，因为并非所有人都使用最新的浏览器，因此采用一些现代功能可能会导致一定数量的用户无法正常使用。
除此之外，几十年来我们还没有一个像样的 JavaScript 模块系统。Node.js 从 CommonJS 借鉴了模块系统，但仅限于服务器。
在最近的很长一段时间里，浏览器都没有出现太大的提升，于是捆绑器与转译器应运而生。尽管我们使用的是 JIT（即时）编译的编程语言，但必须经过一个复杂的构建过程，将源代码转换为实际代码，然后才能在浏览器中执行和解释。
这是大约十年前的情况。
TypeScript 的崛起
微软推出 TypeScript 也正好是在十年前。微软认为，如果在部署代码之前，还需要一个转译器来转换 JavaScript 代码，那么在这个构建过程中再添加一个步骤也没什么大不了。
作为回报，你可以获得一个良好的转译器，将现代 JavaScript 转换成原始的 JavaScript。此外，TypeScript 是一个静态类型系统，它不仅提高了 JavaScript 的可扩展性，而且还提出了一些新概念，并为提高 JavaScript 的开发效率做出了重大贡献。
因此，TypeScript 迅速崛起，并成为当今企业 JavaScript 开发的标准。
在过去的十年里，整个世界也发生了变化。虽然仍有一部分浏览器不会自动更新，而用户使用的浏览器也不是最新版本，但这类用户的比例已经大幅下降了。
这意味着，你只需关注“常青浏览器”（指自动升级到最新版本的浏览器），那么非常有希望摆脱转译器。而且现在我们还可以使用 ESM（ECMAScript 2015 模块），这是一个基于 JavaScript 的原生模块系统，既可用于服务器端，还可用于客户端。
也就是说，我们不再需要捆绑器，至少从技术角度来看是这样。捆绑器只是构建过程中的另一个步骤，为的是优化 HTTP 请求，这样就只需从服务器加载几个大文件，而小文件的数量就大幅缩减了。
TypeScript 将成为一个障碍？
在这种情况下，构建过程将变得越来越简化，甚至根本不需要。微软希望将来只有一个必要的工具会保留下来，那就是 TypeScript 编译器，因为 Web 浏览器和其他 JavaScript 运行时环境无法直接运行 TypeScript。
这也就是说，届时微软的 TypeScript 会从一个非常实用的工具突然变成一个很讨人厌的东西。然而微软表示，他们不想成为障碍，相反，他们希望给予开发人员更多启发。
微软担心的结果是，JavaScript 可能会像 20 年前一样，朝着高速、直接和高效的方向发展，因为如果人们不再使用 TypeScript，那么也就不再需要转译器了。
将 TypeScript 集成到浏览器
最简单的解决方法就是将 TypeScript 集成到 Web 浏览器和其他运行时环境中，成为代替 JavaScript 的编程语言。从理论上讲，这也并非不可能。Deno（https://deno.land/）已经在做这方面的尝试了。
Node.js 中有一个 npm 包，名叫 ts-node，它采用了与 Deno 类似的解决方案。它会在构建/加载应用程序时将其编译到内存中，就好像可以直接运行 TypeScript，但实际上并非如此。
此外，TypeScript 语言本身如今也变得越来越复杂，微软并不希望将 TypeScript 编译器的所有功能直接集成到常见的 Web 浏览器中，因为这将是一项非常复杂的任务，需要苹果、Google、Mozilla 等公司通力合作，整合一个新的大标准。
无论这个发展方向正确与否，微软都希望回避，目前这个问题的走向尚不明朗，但这项声明表明这不是他们想要的结果。
中间方式：JSDoc
根据微软最近发表的建议可以看出，他们想到了另一种不同的方式。除了（a）编写原始的 JavaScript ；(b) 完全切换到 TypeScript，其实还存在第三种介于二者之间的一种中间方式。
TypeScript 允许你在 JavaScript 上分析代码，甚至可以在其中存储类型，即编写适当的 JSDoc 注释即可。对于某些公司来说，这种方式不仅可以通过 TypeScript 编译器获得类型支持，而且无需将项目完全迁移到 TypeScript。
这种方式最大的优势在于，代码仍然是纯粹的 JavaScript，不仅不需要编译，而且只需删除所有 JSDoc 注释，就可以褪去 TypeScript 的外壳。我曾使用过 JSDoc，不得不说感觉更像是 TypeScript 的廉价替代品。
需要编写的代码更多，而且非常繁琐，几乎无法实现更复杂的类型，但总比没有类型好。
建议：将 TypeScript 作为注释
所以微软的建议是，TypeScript 沿用 JSDoc 的套路，这样就不必编译 TypeScript 了。
类型注释和关键字（例如“public”或“private”）将成为注释，在执行 JavaScript 代码时会被忽略。这意味着，你可以编写 TypeScript，而无需将 TypeScript 编译成 JavaScript 代码。
但是，你仍然可以使用 TypeScript 编译器来触发类型检查，只不过不必编译代码来运行。而“d.ts”文件将会被淘汰，因为 JavaScript 代码中也包含这些类型。
这样，TypeScript 编译器就会变成一个可选的插件，就像 ESLint 之类的 linter，所有类型注释都不会包含在执行的代码中。
因此，该提案被称为“将 TypeScript 作为注释”。
将 TypeScript 作为注释的缺点
这个思路听起来不错，但我看到了一些缺点。
我们不要忘记，TypeScript 不仅包含函数参数的原始类型，而且还有接口、联合类型、类型关键字、非常复杂的类型和嵌套类型、“as”关键字、公共/私有/受保护关键字、泛型类型等等。
代码本身就包含一些注释，而且还包含两种类型的注释（单行注释和块注释），如今再加上 TypeScript，那么我们就必须不使用多种类型的注释来表达关键字。
所以，我不得不思考这是不是一个好方法，因为我很喜欢当前的解决方案，即使它并不完美。毕竟，人们选择 TypeScript 而不是使用 Flow 或 JSDoc 等替代方案是有原因的。TypeScript 比这些替代方案更受欢迎也是有其背后的原因的。
此外，我们编写代码时无法使用枚举，因为它们是值和类型的混合体。还有命名空间、TypeScript 的 JSX 支持、参数属性等，这些都无法使用。所以如果你想使用枚举，就必须编译代码；如果不想编译，就不能使用枚举。
这个建议并没有真正分割 JavaScript 与 TypeScript。我非常怀疑这是否应该成为 TypeScript 未来的发展方向。
在我看来，这种方式会导致 TypeScript 开发人员陷入混乱，并形成两个阵营。一些人坚持使用当前版本的 TypeScript，而另一些人将转战“将 TypeScript 作为注释”。
最后的想法
在我看来，TypeScript 的发展有两个方向：要么保持完整性，尽管所有代码都需要编译；要么给 JavaScript 创建一个可选的静态类型系统。
这意味着，TypeScript 会成为新一代的 JavaScript，但微软已经否决了这个思路。因此，我的结论是，TypeScript 不应该通过这种方式从根本上发生改变，尤其是不应该以微软目前提议或支持的方式。
未来几个月或几年内 TypeScript 究竟会如何发展，就让我们拭目以待吧。
原文链接：https://betterprogramming.pub/how-microsoft-wants-to-destroy-typescript-1f1a53b18de6
END
《新程序员001-004》全面上市，对话世界级大师，报道中国IT行业创新创造
— 推荐阅读 — —点这里↓↓↓记得关注标星哦~—
一键三连 「分享」「点赞」「在看」
成就一亿技术人
文章评论