我来说一句反对typescript的话

广告位招租
扫码页面底部二维码联系

世界上刚有typescript的时候,我就开始关注它了。我很明确,它是一门新语言,只是和javascript是近亲。在它的介绍文档中,我看到private关键字,甚是兴奋。但我开始去用它的时候,发现它的private的骗人的。除了private骗人外,它的所谓类型检查系统也有欺骗性。现在很多人已经叫嚣着,不懂typescript就是不会前端。说实话,除了对typescript不满意,我连对ES标准的#符也不满意。不是我挑剔,是有些东西人会天然不喜欢。

读完这个答案之后,我更加确信,原来自己的反感是有根源的,并非我有问题,而是typescript有问题。有什么问题呢?先来说一些旁的不喜欢点:

  • 繁琐的类型定义方式,明明是一门新语言,非要按照js的语法来写,但是又发明一些莫名其妙的新语法
  • 类型声明实在受不了,我知道使用 : 是受了其他语言的启发,但是真正好的类型声明很明显要放在变量前面
  • 对象属性的类型声明?呵呵,太恶心。: 和 as 能让人写作烦躁10倍。
  • any?哎。。。
  • 结构类型检查!WTF
  • 据说类型检查能减少bug,但是,你怎么能确保你编写的类型本身没有bug?
  • 降低效率,用在解决(编写)一个类型问题上的时间,可能够我写完2个需求
  • 使代码可读性降低,你需要在阅读代码过程中,跳到类型定义的部分去阅读,阅读完再跳回来来,一去一来,我是谁,在哪里?
  • 增加运行难度,据说deno支持直接运行ts,但是实际上,还是先翻译为js后执行

我们来看上面那篇回答中的一个经典案例:

interface A {
    x: number;
}

let a: A = { x: 3 }
let b: { x: number | string } = a;

b.x = "unsound";

let x: number = a.x;

a.x.toFixed(0);

恶心死你。你不是静态类型检查吗?给你查,查破了你能告诉我 bug 来自哪里?人生啊,不要相信所谓了“在准确和效率之间找平衡”,忽悠。别的类型系统,之所以成立,是因为别的语言需要先编译,后执行,有健全类型系统,类型声明不用慌,而且类型本身就是运行时的。从我的不成熟的想法来看,不在运行时的类型系统,都是扯虎皮。使用typescript嘛,和语句末尾使用使用;结束一样,技术不到位,有;也避免不了各种错,技术到家,没;照样优雅健壮。

我理想中的js变量类型声明:

int a = 1
bigint b = 299300002390809238n
float c = 2.2
bigfloat d = 4.394085943789534809830543l
string e = 'xxx'
Date date = new Date()
Promise p = new Promise(...)

// 多层结构的对象,可以在内部属性上独立确定类型
object o = {
  string name: 'my name',
  int age: 10,
  // 用<>表达其内部结构
  array<[
    object<{
      string name,
      number price,
    }>
  ]> books: [
    // 纯值,当然,也可以在内部进行类型定义,类型系统自己推演
    {
      name: 'book name',
      price: 6.6,
    },
  ],
}

let x = 1 // 相当于 any
const y = 'ok' // 不可变
var z = null // 带变量提升的 let

如果一个变量想要发生类型转化。。。不可以的。

int a = 10
string b = a + ''

这样操作是唯一的途径吧。

但是实际上,在运行时,你怎么知道后端接口会返回给你什么?大部分情况下,null 值无法避免。

// 用 type 关键字声明和定义类型
type ResponseType = object<{
  int code,
  object data: {
    string name,
    number|null age, // 支持 null
    array<[
      // array 内部可以有多种结构,只要元素满足其中之一,就可以通过类型检查
      object<{
        string name,
        number price,
      }>,
      object<{
        string name,
        int pages,
      }>,
    ]> books,
  },
  ?string error, // ? 开头表示可能不存在,存在的情况下才遵循类型
}>

现在我要使用它:

fetch('/api').then(res => res.json()).then(string (ResponseType data) => {
  // 如果data的类型检查不通过,直接抛出 TypeError
})

看看函数:

function a(int x, int y) int {
  return x + y
}

object o = {
  a(int x, int y) int {
    return x + y
  },
}

class Some {
  string _name = 'my name'

  static get name() string {
    return this._name
  }
}

// 直接使用原生 function 范型(借鉴 python 的 lambda 表达式)
function<int, int: int> sum(a, b) {
  return a + b
}
// 声明一个函数类型(借鉴 python 的 lambda 表达式)
type func = int, int: int

// 遵循将类型放在变量前面的规则,func 是类型名,sum 是函数(变量)名
func sum(a, b) {
  return a + b
}

再搞一个泛型耍耍。我在这篇文章中已经说过了,泛型,实际上就是函数

// 用 <> => 定义泛型,其中 book<a, b> 中的 book 是泛型的名字,<a, b> 是替代符,=> 后面是返回的形式化结果
type book<a, b> => object<{
  a name,
  b price,
}>

怎么用?这样子啊:

book<string, number> book = {
  name: 'xxx',
  price: 12,
}

看看泛型的演化:

// 定义一个泛型,泛型的结果是一个 object 描述,(而非一个类型)
type a<x, y> => {
  x a,
  y b,
}

type b<z> => a<z, z> // 直接运行 a<z, z> 将得到的结果作为 b<> 泛型结果

// b<string> 的结果,作为 object<> 的参数
object<b<string>> o = {
  a: 'xxx',
  b: 'yyy',
}

实际上,我不大推崇这种声明,因为通过这样的声明,我并不能马上看清楚在声明 book 这个变量时,它的结构,我更喜欢:

object<{
  string name,
  number price,
}> book

即使这个时候,我并不给 book 赋值,这样声明 book 这个变量我就知道它的内部结构是啥。虽然这样我可能需要写很多重复代码,但是相对来说,理解成本更低。

当然,在函数上,泛型确实还是有好处:

function a(int|string x, int|string y) int|string {
  return x + y
}

这种声明明显不好,因为你怎么知道 x=1, y='a' 这种情况不会发生。所以,这种情况,要使用泛型:

// 通过泛型,实现函数参数和返回值统一类型
type f<T> => T, T: T
f<int|string> a(x, y) {
  return x + y
}

// 或者通过一个匿名的泛型来简化写作
function<(T => T, T: T)<int|string>> a(x, y) {
  return x + y
}

作为一个特殊结构,<> 内是一个复杂体。因为任何 <> 前面的东西,会被认为是一个范型而被运行,因此 (T => T, T : T) 将会被作为范型,传入 int|string 运行,得到的结果作为 function 范型的参数。

type some = function
type some<T> => T, T: T

上面这段代码表示,我们可以直接使用 some 作为类型,也可以使用 some<xxx> 作为类型,some 既是类型,也是范型。

这一套东西,是在运行时做的,这样的定义,岂不是爽歪歪。当然,我依靠 tyshemo 还是有可能把这套东西给实现的。对了,有兴趣可以看下 C# 的类型系统。

已有5条评论
  1. Nichola 2023-12-22 17:19

    Typescript is a piece of fucking shit.

  2. blah 2021-11-16 18:28

    ts好的原因之一很簡單,弱類型IDE的輔助就是智障,輔助全靠猜,猜又猜不准,垃圾名詞一大串,ts用的多香,直接ts起跳誰還會js ts定義檔來來回回跳,根本就不會去看js了,唯一會坑人的就是ts定義檔寫太爛罷了。沒錯,ts只能保證編譯時期安全,就已經很夠用了,他確實就不保證執行時期類型安全,但是這絕對不是笑話,js寫的定義有的結構全都不清楚,模糊的要死,ts結構定義清晰看一下就明明白白的,定義檔直接寫清楚,還是js code/docs直接玩大家來找碴,二選一,明明白白地,誰比較香呢?

    準確就是效率,先刷掉了一大把靜態檢查會產生錯誤,然後才是執行時期的錯誤再另外排除不就好了?

    ts本來的任務就是輔助ts,所以在類型系統上本來就會有妥協,所以才會出現混合的類型,所以在實務上還是要做好類型把關,針對多類型混合狀態就做好執行時期檢查本來就是工程師的該做的事情,檢查沒做再把鍋甩改ts沒檢查到,幹嘛呢?

    • 否子戈 2021-11-18 12:27

      ts简单?扯淡!就算你有10年java经验,要懂协变、逆变等等一大堆类型推演也是很难的,更别提一个普通程序员。什么?类型推演不重要,在工作中用不到?我只能呵呵了,随便写几个句子,都会得到与想象中不一致的类型判断,因为你根本没理解类型推演的实现逻辑。

      除了复杂的类型系统,ts也不能辅助js开发,而是阉割js开发,说是js的超级,实际上只能用js的子集。在大部分情况下,你不仅要在为业务逻辑撰写代码过程中,浪费大量的时间在非业务之外的代码上(当然,收益也是有的,而且是持续性的),全是噪音,而且有的时候,为了解决一个IDE报错问题,你需要花费小半天的时间去搞明白逆变原理,再来思考我要做怎样的体操才能得到我想要的类型检查,说真的,扯淡!

      当然,不得不承认在前端领域,ts占有一席之地,有好的地方,但是你要说有绝对地位统治地位,我觉得是瞎扯,es标准一升级,你ts可能就要靠边站,比如你private,我来一个#,你怎么办?你得private #?不是瞎扯淡吗?

      我写了一套js的运行时类型检查系统,你可以通过 import { Dict } from ‘tyshemo’ 这样的形式来使用,虽然运行时类型检查消耗性能,但可以在特定情况下再做。可以说,表达类型更直观。

  3. bigsir 2020-04-22 16:11

    whh

  4. rxliuli 2020-04-18 14:11

    不敢苟同,ts 的认知吾辈经历了反复的几次变化之后,只能说:真香!