TypeScript 体验

我的问题

几天前，我在 Twitter 上看到一个帖子，作者问那些不使用 TypeScript 的人：“你们为什么不使用 TypeScript？”

通读所有回答，可以看出那些不会使用 TypeScript 的人对 TypeScript 的看法是：

• 这令人望而生畏。
• 这是一项开销。
• 这使得编写代码变得繁琐。
• 这会使代码更难阅读。
• 它会减缓发展速度。
• 它无法防止运行时错误

这些似乎并非对静态类型本身的直接批评，而是TypeScript中特定不健全的静态类型系统所导致的后果。与Flow类似，TypeScript的静态类型系统也基于结构子类型。这意味着TypeScript的类型系统允许某些编译时无法确定的操作是安全的，类型推断可能不正确，并且需要一定程度的手动编写类型注解。

相比之下，Rust、Haskell、OCaml、Elm 和 F# 等其他语言则拥有健全的类型系统，例如Hindley-Milner 类型系统(HMTS )，这些系统不需要类型注解，并且类型总是能够正确推断。这些类型系统确保代码在运行时不会产生类型错误。此外，结合其他设计选择，例如在类型系统中显式地表示错误（例如使用“Maybe”、“Either”等），使用健全类型系统的语言能够在编译时检测到其他类型的运行时错误。

这是一个已经被深入讨论过的话题，但我想知道是否有一些新的视角。

我的问题

• 这些回答反映了重要的现实情况，还是仅仅是少数人的抱怨？
• 如果这种不满比较普遍，它是否与上述TypeScript 的不健全性有关，或者说，这种不健全性根本就不是问题？
• TypeScript 在这方面还有改进空间吗？或者更广泛地说，JavaScript 的超集能否在不变得过于复杂的前提下支持健全的类型系统？
• 或许只有限制 JavaScript 的使用，或者使用一种可以编译成 JavaScript 的其他语言，才能实现健全的类型系统？

请在下方评论区告诉我你的想法❤️

附录 - 推特话题精选概述

• 问题

我想听听那些不使用 TypeScript 的人的意见。为什么不用呢？

• 答案

💬

日常工作中我必须使用 TypeScript。但在我的项目中，我拒绝使用 TypeScript。

• 繁琐的输入类型，99% 的情况下完全没有必要，但 TypeScript 编译器却要求必须输入这些类型。
• 无法捕获漏洞
• 阅读代码变得越来越困难
• 仍需运行时检查

💬

因为这个类型系统不完善，而且它似乎比我想要的类型系统要复杂得多，也神奇得多。

💬

我跟几个人聊过，发现有两种类型：

• 刚刚起步，就被红色浪潮吓到了。
• 经验丰富，足以避免常见的 JavaScript 陷阱，但并没有从 TypeScript 中获得顿悟。

💬

因为 TypeScript 会减慢全新项目的开发速度。它是一种在一定规模下才能发挥优势的工具。

💬

部分原因是 JavaScript 的灵活性是其核心优势之一，因此，取消灵活性就等于取消了它的优势。

💬

TypeScript 非常实用，在我的日常工作中更是不可或缺，但对于一些小型或一次性项目来说，它可能有点过于复杂。对于其他项目，还有其他一些强类型、可编译成 JavaScript 的语言，它们拥有更完善的类型系统，有时可能更合适。

💬

我不确定 TypeScript 的开销是否足以抵消 JavaScript 中的类型问题。或许在大型项目中可以接受。

💬

我试过类型安全，但遇到了很多问题。而且，我的一些函数会根据情况返回不同类型的值。最终，我并没有从中获得足够的益处。类型安全固然好，但我更喜欢 JavaScript 的灵活性。

💬

以前用过好的字体系统，就很难再用不好的字体系统了。

💬

我在目前的项目中使用它，是因为稳定性越来越重要；我也想找个借口学习新东西，免得落伍；而且我以前也对新工具判断失误过，所以想试试看。但总的来说，它浪费的时间比节省的时间还多。

💬

• 代码臃肿（代码可读性或许是最重要的方面）
• 无论之前我获得了什么“保证”，都需要在运行时保护一些东西。
• 离金属更远
• 更多需要了解和维护的工具

💬

如果你不习惯这种方式，它会减慢开发速度。我曾经花好几天时间一边打字一边写代码，而这些工作原本一天就能完成。

💬

来自一位TypeScript的忠实支持者：

• 如果不进行增量构建或静态类型检查，编译时间可能会增加。
• “聪明”的开发者滥用它
• 没有真正的保证，只有空头支票。
• 需要管理的代码量大大增加。
• 有些库的类型定义不够理想。

💬

它很笨重，速度也稍慢，而且对于大多数项目来说都过于复杂。我们花了很多时间研究优秀的库，就是为了避免自己编写过多的代码——既然如此，为什么还要用 TypeScript 来编写那么多（大多不必要的）代码呢？最重要的是——它根本无法捕获所有 bug（差得远呢）！

💬

• 花太多时间取悦字体系统。
• 配置种类太多了。
• 在Node.js上运行JavaScript代码之前，我不需要添加任何步骤，为什么要添加呢？
• 无运行时类型检查

💬

我花在解决第三方库中缺失或损坏的类型定义上的时间，比我愿意承认的要多得多。
正因如此，我以后再也不会选择 TypeScript 了。

💬

对于某些项目而言，成本效益比过高：

益处：

• 了解函数参数的类型很有帮助（尤其对于库而言）。
• 智能感知
• 在运行时之前发现错误

成本：

• 这是另一项需要学习的技能。TypeScript 非常强大。
• 它有多种形式。我见过数组或字符串数​​组。
• TSConfig 也是个麻烦事。
• 类型可能过于复杂，为什么不能只是基本类型之间的混合呢？
• 错误太多了。我用了 eslint，它只发出警告。

💬

我们在职业生涯中编写了足够多的Java代码。

💬

• 语法可能会变得冗长且难以阅读。
• 所有环节（构建、测试、IDE）都变慢了。
• 缺少足够多的库来提供类型信息。
• 有时仅仅为了满足打字系统的要求，就要花上一个小时。

而我本人在所有项目中都使用 TS。

💬

TypeScript 为了保持与 JavaScript 的兼容性而做出了太多牺牲。按照现代标准来看，JavaScript 的开发用户体验并不理想，而 TypeScript 也无法带来质的飞跃。试试 Elm 吧！

更多答案请查看原推特帖子。

标题插图源自rawpixel.com 创建的点赞表情符号矢量图 - www.freepik.com。

🔴 这些答案中是否有任何与你自身经历相符的？❓

🔴 你认为有什么办法可以改善 TypeScript 的使用体验吗？尤其是在与那些使用完善类型系统的语言进行比较时？❓

请在下方评论区留言。