“TypeScript不值得！”前端框架Svelte作者宣布重构代码，反向迁移到JavaScript引争议
前端框架Svelte作者Rich Harris：“我太老了，不能再胡闹了”。
作为JavaScript的超集，TypeScript自发布以来深受开发者喜爱，从JavaScript迁移到TypeScript也一度成为一种趋势。
前段时间，State of JavaScript对近40000名Web开发人员进行调查，在回答有关JavaS cript编程风格问题的人中，TypeScript的使用率高达98.9%。其中，20.7%的受访者仅使用TypeScript编写代码，而仅使用JavaScript的受访者比例为8.2%。尽管TypeScript可以编译成JavaScript，但对于许多开发人员来说，TypeScript仍是优先选项。有声音甚至认为，“TypeScript正在慢慢吞噬前端开发人员的世界”。
但另一个有趣的趋势是，一些开发者正在“反向操作”——从TypeScript迁移到JavaScript。
Svelte计划重构代码：从TypeScript切换到JavaScript
今年3月，前端框架Svelte作者Rich Harris在接受The New Stack采访时表示，Svelte的第一个主要修订工作正在进行中，目前，团队正在将底层代码从TypeScript切换到JavaScript。Rich Harris认为，这一更新将使团队能够在今年晚些时候为Svelte 5融入“伟大的想法”。
作为一个在2019年才诞生的新兴框架，Svelte发布之初的一大痛点就是不支持TypeScript。2020年7月，Svelte终于加入了TypeScript支持。如今3年不到，就要从Type Script切换到JavaScript？
消息一出，不少网友跑去Twitter求证，Rich Harris当即给出了肯定的回复，并表示“原生支持TypeScript是很棒的选择，直到你有了TypeScript的依赖分布，那时它就变成了一个加载的footgun。我们欢迎其他人去胡闹，但我太老了，不能再胡闹了”。
5月9日，Svelte团队发布了一个名为TS to JSDoc Conversion的PR，根据描述，Svelte团队将会从TypeScript迁移到JSDoc。
该举动迅速引发网友激烈讨论。有用户提问“为什么要这么变？我一直在到处搜相关的问题和讨论，但找不到答案。”
至于背后的原因，其实Rich Harris在上个月接受采访时就已作出回答。Rich Harris认为TypeScript对开发库来说“不值得”，团队正转向JavaScript和JSDoc。Rich Harris在采访中提到：“我们已经决定，在Svelte核心代码库中完成从TypeScript到JavaScript的迁移。原因比较复杂，所以我一直没能做充分解释。”
Rich Harris表示：“我的观点是，类型确实很棒，但TypeScript有点麻烦……一旦用上了.ts文件，就必须同时使用支持它的工具……所以我逐渐觉得，使用TypeScript这样的非标语言并不值得。于是，我们开始将所有类型都放入JSDoc注释，这样既保证了类型安全，又回避了缺点。毕竟这只是JavaScript，所有内容都在注释当中，只要运行代码就行。我们在Sveltekit代码中就是这么做的，效果非常好。所以对于Svelte 4.0，我们也将采取同样的思路、借此加快开发速度。”
Svelte并不是第一个放弃TypeScript的社区。2020年，Deno完成了内部代码从Type Script到JavaScript的迁移，以减少构建时间，生成高性能代码。最近，有消息称Deno也在考虑在内部切换到vanilla JS。
在相关设计文档中，“问题”部分展示了Deno迁移的原因：
在cli/js中更改文件时的增量编译时间需要几分钟，修改起来非常缓慢且痛苦。
我们在cli/js中使用的打字稿组织/结构正在产生运行时性能问题。例如，我们最近意识到我们无法让TS生成一个名为“Header”的类，因为它隐藏了我们d.ts文件中的声明。因此，我们将类命名为“HeaderImpl”并将其分配给“window.Header”。但这会产生“Header.name”具有错误值的问题。所以我们被迫添加不必要的运行时代码
Object.defineProperty(HeaderImpl, "name", { value: "Header" });
修复“Header.name”。谁知道这是否会将Header踢出V8中的某些优化路径。最佳的做法是生成“class Header { … }”，任何不足都表明设计中存在根本缺陷。
TypeScript应该可以帮助我们组织代码，但有人可能会声称它具有相反的效果。例如，我们有两个独立的Body类https://github.com/denoland/deno/issues/4748。由于生成运行时代码涉及的复杂性，因此很难了解这一点。理想情况下，我们会有一个系统，其中两个Body类显然是错误的。
我们的内部代码和运行时TS声明必须已经手动保持同步。TSC没有帮助我们生成d.ts文件——当我们之前尝试时，它的开销和复杂性太大了。
从TypeScript转向JavaScript是一个好选择吗？
虽然Svelte不是最流行的JavaScript框架，但在开发者心目中却有着极高的地位。开发人员之所以选择TypeScript是因为他们发现强类型有助于减少错误，并通过代码补全和弹出帮助等功能改善代码编辑器内的开发体验。
JSDoc则是一种API文档工具，同样可用于类型检查。Visual Studio Code已经内置JSDoc支持，开发者只需添加以下内容：// @ts-check至JavaScript文件开头即可。文档解释道，“当无法推断类型时，可以使用JSDoc注释进行指定。”此功能实际由TypeScript提供支持，所以TypeScript和JSDoc可以说是相互依赖。
但一个容易被忽略的细微差别是，Rich Harris指的主要是库开发场景下的TypeScript。如果大家正在构建应用程序，那么实在没必要转向JSDoc。“这就没必要了，因为在构建应用程序的过程中，大家无论如何都需要构建的步骤。应用开发的重点在于优化代码、控制它的体量，并把一切都捆绑起来。但如果是想构建一个库，那我强烈建议改用JSDoc。”
虽然Rich Harris解释了团队从TypeScript转向JavaScript和JSDoc的理由，但面对强势提升的TypeScript普及度，Rich Harris的决策似乎显得有点“非主流”，在Hacker News上也引发了许多网友讨论。
Rich Harris本人也在Hacker News上回复道“没想到一个内部重构PR能在Hacker News上排名第一”，Rich Harris还进一步介绍了迁移背景，以免大家面对变动胡猜乱想。
Rich Harris表示，“如果你是TypeScript的铁杆批评者，认为我们脱TS入JS的做法证明了你的观点……抱歉要让你失望了。但如果你是TypeScript的狂热拥护者，觉得我们脱离TS就是背叛了精神信仰……你同样会失望”。
Rich Harris补充道，首先，Svelte不会放弃类型安全，只是决定将类型声明从.ts文件转向带有JSDoc注释的.js文件。作为Svelte用户，这不会影响大家在Svelte中使用TypeScript的能力——从Svelte导出的函数，仍拥有大家所熟悉的各种TypeScript优点（类型检查、智能许可、内联文档等）。Svelte对TypeScript的支持承诺，比以往任何时候都更加坚定（具体示例请参阅https://svelte.dev/blog/zero-config-type-safety）。
此外，Svelte用户基本感受不到任何变化。有限的区别就是包体积更小了（不需要传递巨大的sourcemap之类），还可以通过cmd-clicking使用“Svelte”及其子包导入的函数来调试框架（它提供的不是无用的类型声明，而是引向实际源代码，开发者可以直接在「node_modules」中编辑并查看实际变化）。
Rich Harris表示，希望此举能显著降低框架的贡献参与门槛，现在开发者：1）不需要理解如何链入repo；2）不必在监视模式下运行构建流程；3）不需要为了观察source和dist代码间的变更而理解其映射关系。
Rich Harris认为，这次调整将使Svelte的用户和贡献者受益，同时也给项目团队减轻负担。团队经常需要针对沙箱测试对源代码做修改，新的工作流要比以往的build步骤好很多。体验过TypeScript工具那参差不齐质量的朋友肯定都为此头痛过，这次的迁移也帮团队回避了此类问题。相对而言，最大的缺点就是在JSDoc中编写类型确实不像在TypeScript中那么舒服。这个缺点虽然相对可以接受，但团队内仍然存在争议，当前网上的激烈争论也主要来自这个角度。
“总而言之，我们的迁移决定基于实际需求，而绝不是什么立场问题。长期以来，我们一直以求真务实的态度构建SvelteKit（反而是在Svelte那边更多追求理想主义），毕竟在这边提高生产力才是硬道理。”Rich Harris总结道。
参考链接
https://news.ycombinator.com/item?id=35892250
https://gomakethings.com/ditching-typescript-for-javascript/