Deno 将永远支持 TypeScript

2020-06-23

denowillstopusingtypescript.png

背景

昨天看到 5 reasons why Deno will stop using TypeScript 这个标题时被吓了一跳。突然想到会不会是 1.0 发布中提到的 TypeScript 编译瓶颈,但他的解决方案并不是放弃 TypeScript 呀。很害怕 Deno 自己啪啪啪打脸,于是又特意跑到官网上看看 "Supports TypeScript out of the box" 这一特性还在不在。哦,放心了,于是慢慢的一探究竟。

最终发现官方的标题明明是《设计文档:使用 JavaScript 代替 TypeScript 做为 Deno 的内部代码》。

声明

2020-06-19:我看到此设计文档的讨论已经远远超出了他的范围和初心。大多数人并没有通过上下文来真正理解这份技术文档——此文档仅适用于 Deno 内部非常特殊,非常技术性的情况。这根本不能做为对 TypeScript 的评价。这也不是关于 Deno 任何公开可见的讨论。当然,Deno 将永远支持 TypeScript。用 TypeScript 编写的网站或服务器与 Deno 相比是截然不同的程序类型——Deno 只有一小部分使用 TypeScript 进行编写。该文档的目标受众为从事此特定内部系统的 5 至 10 人。请不要异想出其他子虚乌有的结论。

问题

Deno 应该专注于为用户提供高性能和安全的运行时环境。Deno 内部代码的组织永远都不会以其交付的产品做为代价。目前,我们正在尝试“自我托管”,这样就可以让我们组织内部的 TS 代码看起来和 Deno 用户代码一样。 这是一件好事,但这并不是必需的。我们尝试的“自我托管”越来越明显告诉我们,他正在阻碍用户代码的性能和运行时的可维护性。

解决方案

一个根本的解决方案是删除所有内部代码生成时的 TS 类型检查和绑定。我们将所有运行时代码移动到单个的大文件 cli/rt.js 中。该文件在构建时将直接放入 V8 中以创建快照。对应的 cli/rt.d.ts 将包含类型定义和文档。

在这种方案下就可以编写类似于 class Header { } 的代码,并能清晰地了解运行时提供和执行的内容。

具有 1 万行的 JavaScript 文件听上去很愚蠢。但我认为这与当前系统相比,他能使新的贡献者快速了解 Deno 是如何 bootstrap 的。

使用此方案,构建时的复杂性和性能将会更好。当然,我们依旧需要做一个快照,但这样我们就不需要构建一个特殊的 TSIsolate 来进行 tsc 的首次执行。

使用此方案,运行时的复杂性和性能将会更好。我们可以清晰的知道我们是否存在一个类的多个定义。我们可以清晰的看到所有正在执行的代码。我们还能在调试过程中分析和逐步执行代码,而不必担心额外的源码映射所带来的复杂性。

最需要声明的是:Deno 用户仍然可以使用 typescript 进行编码和类型检查。我们将会进行测试,以确保代码可以像 cli/rt.d.ts 一样正常运行。

编译器工作人员将只需要自己单独的 cli/compiler.js 文件,而不需要对应的 d.ts。这种方案的一个缺点就是很难在编译器工作和他自身运行时之间共享代码。

返回总目录

每天 30 秒系列之前端资讯

摘自

Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

  • 30Seconds

    📙 前端知识精选集,包含 HTML、CSS、JavaScript、React、Node、安全等方面,每天仅需 30 秒。

    • 精选常见面试题,帮助您准备下一次面试
    • 精选常见交互,帮助您拥有简洁酷炫的站点
    • 精选有用的 React 片段,帮助你获取最佳实践
    • 精选常见代码集,帮助您提高打码效率
    • 整理前端界的最新资讯,邀您一同探索新世界
    452 引用 • 375 回帖 • 4 关注
  • Deno
    2 引用 • 6 回帖
  • 资讯

    资讯是用户因为及时地获得它并利用它而能够在相对短的时间内给自己带来价值的信息,资讯有时效性和地域性。

    24 引用 • 83 回帖

赞助商 我要投放

1 回帖
请输入回帖内容 ...
  • ferried 1 评论

    有没有给出解决 n 多浏览器的兼容方案。babel 是最难用的库之首

    babel 的配置一开始也是头大。兼容方案就是不要去兼容 👽
    Vanessa