看到有人说"前端对 ts 只用了 10%, 大部分只用了类型检查", 请教下剩下 90%是什么.

[371657110]

引用来自知乎:

不过可能大家误解了 Typescript，不是用了静态类型写几个 class，interface 就叫工程化了，感兴趣的话还是建议多多阅读 spring 或者 .net 平台的代码，面向对象不是类型检查器

前端对于 ts 只用到了 10 ‰，大部分只用到类型检查

不引战

不喜勿喷

[mars0prince]

当然是 java 和 c#那一套，依赖注入，控制反转，注解反射等等，你看 angualr 不是玩的很溜

[changnet]

主要是面向对象和面向过程的区别？这个在大型工程里区别很大

[azh7138m]

@mars0prince 本来 ts 就是为 angualr 而生。。。。

[maichael]

我建议你去问说这句话的那个人，毕竟每个人的定义不一样。

[ChefIsAwesome]

Java 对 JavaScript 的鄙视，后端对前端的鄙视。知道的越多才会越谦卑。

[Chingim]

@azh7138m
@mars0prince 为什么你们能同时拼错 angular

[Torpedo]

@azh7138m ？？？为 angular 而生。。。

[azh7138m]

@Chingim 当然是复制粘贴啊（


@Torpedo angular

[Cbdy]

依赖注入，自动配置之类的。
实际上可以认为是一套 DSL。摸熟了可以提高不少开发效率，把过程式编程转变成声明式编程

[nonoroazoro]

最基本的区别不就是面向对象的区别么。比如最简单的 ES Module 与静态类的区别，然后是继承、派生、重载的区别，然后更复杂一点就是设计上的区别，比如如何实现控制反转（ IoC ）等等。

[wly19960911]

@nonoroazoro 重载不能实现，只能手动判断，我目前也只能靠类型继承传递参数和接口定义。这个是坑，但是也不是坑，因为重载的过程不是编译器执行的

[wly19960911]

没开发过后端还真的不一定可以理解后端的面向对象和类型的区别，但是有个问题存在了，那么真的有项目需要做到这个地步吗，或者前端 angular 已经实现了，而且 IOC 实现的比 spring 好（毕竟考虑到前端组件作用域和后端的框架功能完全不一样），后端的话为什么一定要 ts 去实现各种 IOC，那么我为什么不用 java 这种成熟且好招人的语言。

我公司是用 angular 的，我也非常敬佩 angular 使用 ts 作为语言，非常好用的语言，但是很多人就对 angular 不满了，大且重。很多人喜欢 vue 的简单和 react 的性能好、生态好，我一开始也不理解这个问题，后面想了想，实际上前端并没有那么多大工程去开发和实现，所以并不需要那么多人都去搞熟这个框架。

当然，个人的发展空间非常大，因为这个和面向对象的思想牵扯到一起了，从 OOP 的思想到设计模式，这一套搞下来还真的不是一般人玩得转的，作者是从这个角度看的，而且从这个角度看，符合这个条件后端和 Android 又有多少人？

ts 的 枚举、高级类型（联合类型和 type 关键字定义的字面量类型）是一个非常有用的东西，简单而且好理解，直接抹消魔术字符串和强行定义一些值，实际上联合类型非基础类型还是别用了，如果出现我更倾向代码逻辑有问题，因为大部分的场景可以使用继承解决。这个东西直接解决了我对 options 的一些字段赋值的问题。

另外有人能回答下，Android 的设计思想适合用到 angular 上吗，我想看看 Android 的一些组件设计思想，如果有 demo 的话那就更好了。

[wly19960911]

@nonoroazoro 刚刚想了下，说错了，重载的过程我记得好像是编译器完成的，但是 ts 不会把语言带进编译过程去做处理，最简单就是，因为 js 不存在类型，怎么确定你传参是这个，而执行某个方法？最后 ts 就没有重载，只有覆写，继承，接口。

[yuanfnadi]

后端转前端的表示 ts 用起来真的比 js 顺手。
但是写 react 的话一般也不会用到什么时候 ioc 吧。

[66beta]

大部分场景下，用 angular 起项目就是把简单的问题复杂化

[mcfog]

设计模式最大的问题就是糟粕（或者说应对主流语言糟粕的方案）和精华混在一起，让大口吃下去的人中毒

在我看来，这种（用一门技术就应该以使用全部特性为荣）的前设就是最大的糟粕。如果你的工程就是缺个类型检查器，那么就把 ts 当类型检查器用就最好，不要去试图解决不存在的问题

利益相关： 业余前端，只在 jQuery 时代用过版本号非常小的 ts

[nonoroazoro]

@wly19960911 TS 的重载确实得靠自己判断来实现，但是因为在有 definition 的情况下，调用方能很明确的知道自己调用的方法和签名，在一些情况下还是很有用的。

[nonoroazoro]

@wly19960911 你说的对啊，实际上 TS 重载的只是函数签名，编译后只有一个函数，你可以认为它的重载是“假”的。但同时，这个“假”的重载并不代表它就是不可用的，和“真”重载相比，各有优缺点吧。

[wly19960911]

@nonoroazoro 不够方便，最后传参我直接改为继承于某个基础数据类型的类，然后重载的数据继承于这个数据类型，因为这样可以避开传参数量的问题，不同的 function 传参数量不一样，位置不一样,对于非真的重载不过也就是看起来不舒服，功能大致可以一致，类似下面这种形式，我不保证能跑，这个还是我前两天想下来的形式，暂时没有应用。

class A {

}

class Aa extends A {

}

class Ab extends A {

}

function test(params: A) {
if (params instanceof Aa) {
params = params as Aa;
}
}

[nonoroazoro]

@wly19960911 通过传递 instance 作为参数的话确实可以这么判断。不过你也可以直接用 interface 来定义参数，然后利用 type guard 来简单判断是 A 是 Aa 还是 Ab。

不过总之换汤不换药，好不到哪里去，哈哈，毕竟 TS 的重载是 compile time 而非 runtime 的。