JSvsTS：二分法博弈

大家好，这里是大家的林语冰。“TS 凉凉”的前端都市传说今年在前端娱乐圈收割了一大波流量和热度，一时甚至有些许出圈。虽然但是，在“JS 教”和“TS 教”的圣战中，除了狂热的虔信徒，还有像 up 主这种佛系的“无神论者”（其实老粉都知道，语冰乃地球猫猫教的虔信徒），所以 JS 和 TS 互利共生或许可以成为“二极管思维”的第三个正确的选择。

本期《前端翻译计划》共享的是一种偏向实用主义的前端技术立场，惟愿 JS 和 TS 从此握爪言和，别再搞窝里斗，愿前端生态从此世界核平，赞美女神~

DHH 最近发布的关于 Turbo 8 转身出轨 JS，和 TS “和平分手”的博客，刹那间前端人集体破防，TS 爱好者和“类型体操受害者”开始对线，俺也不例外。夭寿啦，我甚至不知道 Turbo 8 是什么鬼物，但私以为本人也可以自由言论。就在几周前，在下将两个最大的项目之一迁移到了 TS，同时保留了另一个使用 JS 的项目，目前这正是本人的最佳选择，没有之一，成年人全都要，喵星人才选择困难。

图片

免责声明

本文属于是语冰的直男翻译了属于是，略有删改，仅供粉丝参考，英文原味版请传送 JavaScript or TypeScript? How To Benefit From the Dichotomy[1]。

在解释本人的动机之前，让我先免责声明 —— 我既喜欢静态类型的严谨性，也喜欢动态类型的易用性。在花了多年时间编写 PHP、Python、JS、TS、Go 以及一点点 Java 和 Rust 后，我学会了鉴赏这 2 种编程范式。我十分享受至死不渝地追求正确的类型，然后沉醉于它们提供的安全套，同时我完全拥抱动态类型系统的自由，快速地组合东东。于我而言，这只是 2 种一龙一猪的乐趣。

虽然但是，我更享受实用主义。其主要目标旨在项目开发的各个阶段快速迭代，如果说这意味着技术的改变，那就且当做是这样吧。

现在，回到我最近的经历。自去年 12 月以来，我一直致力于 2 个巨型前端项目：

• 一个是经典的带有 API 的“网站”
• 一个是非经典的高度动态的 Kubernetes Explorer SPA（单页应用程序）

我不是专业的前端开发者，我构建 UI 的策略一直是“不断更改代码，直到它一切顺利，并且研发之旅的阻力越少越好。”尽管我尊重和热爱静态类型语言，但在开发的早期阶段，当代码库可以在一周内多次完全重写时，类型可能是障碍之一。这就是我使用 JS 启动这两个项目的原因。

9 个月转瞬即逝，我仍然对在“网站”中使用 JS 心满意足。该项目是 UI（Vue）和 API（Nuxt）组件的结晶。 UI 组件丰富但简单 —— 大多数时候，当我发现 UI 回归时，这是由于 CSS 或 HTML 的更改，而不是因为我搞乱了代码。

API 并不那么简单 —— 传统的 BFF（backend for frontend）逻辑（比如授权/身份验证、数据转换等）与自定义课程管理和车队编排逻辑交织在一起，并分布在数十个 API 处理程序中。这种架构（或缺乏这种架构）可能会显着减慢开发速度，但与 UI 组件不同，API 表面是一个更加稳定的领域。为它编写黑盒测试理所当然。

最初，这些测试旨在成为一个验收套件，用于端到端检查系统，包括远远超出 JS API 的组件（即上游服务）。但时过境迁，它们也成为验证 JS 代码更改的主要手段。我对这个项目的现状心满意足 —— 仅通过一组测试就实现了一大坨目标，并且不需要繁重的 TS 机械，我还能奢求什么呢？

图片

那么，为何我还决定将另一个项目 Kubernetes Explorer SPA 迁移到 TS 呢？

答案在于该项目提出了不同的约束和需求。与 iximiuz Labs 网站的主要复杂性聚焦于 API 层不同，Kubernetes Explorer 最头大的部分是它的 UI 组件。

Explorer 的主要逻辑驻留在浏览器运行的代码中，这事关重大。在没有类型提示的情况下，处理大量属性或构建 Kubernetes 对象的复杂图头皮发麻，并且在没有类型检查或测试的情况下重构这样的代码库已被证明十分容易翻车。

图片

在对资源管理器的 UI 进行另一次大型更改之后（其中回归搜索花费的时间比实际重写的时间更长），我决定是时候优化 DX（开发者体验）了。本质上，我有 2 个选择：

1. 开始为 UI 组件编写测试
2. 引入类型系统

测试自然棒棒哒，而且它们与我的其他项目无缝衔接，但根据以往的经验，对于快速变化的领域，测试弊大于利。维护测试套件可能会成为一种真正的负担，并且开发者往往会越来越依赖经过高度测试的组件，当它们不再适合 UI 时，就很难舍弃它们。

与此同时，到目前为止，我在项目中遇到的大多数回归都是，由于缺少属性或一种形状的对象，意外传递给需要不同形状对象的函数导致的 —— 编译器的辅助通常可以避免此问题。因此，我决定将项目迁移到 TS，并暂时将测试数量保持在最低限度。2 周后重写了 3 次，我对自己的选择心满意足。

我将来会向 Kubernetes Explorer 添加更多 UI 测试吗？大概也许可能吧。我会将网站迁移到 TS 吗？大概也许可能吧。有一天我会恢复使用此 App 的 JS 吗？答案是肯定的，前提是我发现它可以辅助我快速迭代。

当然，您的里程可能会有所不同。项目的性质差异很大，且没有一种通用的语言或解决方案。我的个人建议是，保持务实，选择最佳工具，避免教条主义的条条框框。

网站栏目：JSvsTS：二分法博弈
本文网址：http://www.shufengxianlan.com/qtweb/news37/450087.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联